My third week at Red Hat

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):

• Java
• OSGi
• Karaf
• Intelij (or Eclipse)
• Nexus
• Gerrit
• Jenkins
• Maven
• pip, Virtualenv
• Pelican
• Markdown
• Disquis
• IRC, Google Hangout, Webex
• Openflow
• OVS
• OVSDB
• Jackson
• OpenStack, Neutron
• DevStack, PackStack
• Docker
• OpenDayLight (aka ODL)
• SDN
• NFV
• Linux network interfaces
• Yang
• Netconf
• VxLan, Geneva, GRE
• Trello
• ... all the other stuff I do not even know exist ...

Thankfully, I already knew something:

• Git
• Github (or Bitbucket)
• Bugzilla
• KVM
• Python
• JSON
• 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.