Around the clock

The first aspect of the Free Software culture I immediately got into contact with was the timezone mess. As soon as I got accepted it was very clear what had to be done: “i need to meet up with my mentors”.

I’m in Campinas, ~100km from São Paulo, Brazil, so UTC-3:00. Angrez is in Bangalore, India, UTC+5:30. Aaron is in Seattle, USA, UTC-8:00. When Angrez gets to work early in the morning it’s past midnight for me and it catches Aaron right after a full day’s work. And still it’s the best time for us to meet online.

It’s a bit difficult then to say things like “so should we meet at five?” without having to do some annoying math in your head (I find the simplest math to be the toughest). Good thing that in these cases good-ol’ Google Calendar comes in to the rescue! I’ve set up a shared calendar where I enter the meeting times and everyone sees it conveniently in their own timezone. The simple stuff. :-)

This asynchronous nature of things sheds some light on why the free software communities make the most use (and the most development) of communication and collaboration tools based mainly in text: source code control (I’ve heard that deep conversations go on in SVN commit messages), issue tracking, mailing lists, IRC, IMs, blogs, etc.

At my current work, nobody in my team (including myself) has any experience with projects different from single-programmer course assignments, thesis-related mockup programs and the like. And we work on a big project. And although we have available to us lots of those communication/collaboration tools (the whole IBM proprietary suite), we only make very basic use of reserved checkout/checkin features (we’re dead scared of merges!), we do releases by copying code, we check out thirty files, do lots of different things and commit at the end of the day. Heck, we don’t even comment commits.

For now that’s one very immediate benefit I’ve taken from starting to get my feet wet on the free software world. I’ve become quite interested in these version control, issue tracking things and now I’m studying the documentation for that bloody suite, searching around for tips on best practices (stupid stuff like comment the freaking commit – better yet with a single short descriptive line followed by meatier description -, only commit consistent states to the trunk – we don’t actually use branches yet, I’m just practicing the lingo-, one feature per commit, etc.) and, of course, I’ve been nagging the hell out of my colleagues =)

New report says: employees like to do extra, dirty work

Call me a masochist.

But for the past two days I’ve been in ecstasy at work for having gotten the wonderful chance of laboriously cleaning up after someone else’s mess. It’s not even my fault, it’s a lot more work, I have to painstakingly go through dirty and ugly code, but I’m LOVING it! I’m the employers’ dream-worker!!

I’m not real serious about that dramatic opening, though, so I’ll explain.

That huge load of junk was getting in MY way. All those gazillion redundant, ill-commented, ill-defined, sorry excuses for classes were making my absolute LOVE for work drop to a shameful procrastination spree. And now I finally got the chance to make it nice and clean and elegant and pleasant.

So here’s a tip to employers and managers out there. Don’t just give your awesome tech guys something cool to work on. Give them the power to clean up the trash they find along the way. They’ll stay hours after work and they’ll love it! And after cleaning up they’ll work with a lot more passion on whatever it is they had to do.