Flavio's experiences on his 3rd week working at Red Hat.
Software development is nice, but who cares if that is all you are good at? A self evaluation of my professional skills made me realize that I've grown 'unbalanced'. It is not as bad as it sounds, because I'm a pretty curious guy, and having been working at start-ups pushes you to face new things most of the time. But there is no question that my coding skills are light years ahead of my English skills. :P
Enter Red Hat. Now, that is where the rubber meets the road. Not only the group is geographically dispersed, my team boundaries blurry with a big community of folks who do not work for Red Hat. The concept of selling free software makes so much sense to me. I still choose to take my car to the dealer, because I don't have any interest in changing its oil. Paying for that service is something I do, gladly. Pushing it further, Red Hat pays me to contribute to a codebase it does not own. Turns out it is irrelevant to own it; it is much more important to make it high quality and to know it inside out. Brilliant. So, while it is a self serving prophecy, it is also a much less selfish one. I like it.
Back to the 'unbalanced' topic, what I realize now is that while I know how to write good code, I did not invest enough time in learning how to publish my findings as I do the job. Well, if you look at my Delicious links -- which I did manage to keep public -- you can actually see what I've been working on for the past few years. Still, that has big flaws: the links of hobbies and work are all entangled, nevermind the fact that all I did was to take someone's work and time without saying thanks, nor providing useful feedback.
Enter the tools for doing the job. From start, I thought the only skill I was seriously lacking for working with OpenDayLight was Java. Man, was I wrong. Java is actually no big deal for some one who has done lots of object oriented work. Not to be underestimated, tho!
In my opinion, there are 2 fundamental pieces if you are seriously trying to be useful in an open source project: 1) do the work instead of just talking about it; and 2) be good in showing what you did, with no ego. To do that effectively, a bunch of tools are needed, so we can help folks -- and ourselves -- with pointers on the how-to's. As you can see, I'm brand new to Pelican. Putting a page on what I did to get this blog online is next. :)
So, this is the current list (by association order):
- Intelij (or Eclipse)
- pip, Virtualenv
- IRC, Google Hangout, Webex
- OpenStack, Neutron
- DevStack, PackStack
- OpenDayLight (aka ODL)
- Linux network interfaces
- VxLan, Geneva, GRE
- ... all the other stuff I do not even know exist ...
Thankfully, I already knew something:
- Github (or Bitbucket)
- General linux knowledge
- SDN Affinity
Onto my adventures! I feel like a dog let loose in the sausage factory. My biggest chanllenge -- besides having to learn like mad -- is to discipline myself in keeping the context switch penalty to a minumum. I am humbled and excited.