Date Tags diary

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
  • 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.


comments powered by Disqus