The Code Dump

After a few years of working in the field, I’ve come to a conclusion: one of the best ways to evolve as a hacker is to work with other hackers. Not just that, I’d rather work alone than work with non-hackers. Wait, I can almost see you reaching to close this tab, mumbling to yourself this is nonsense. I’m not saying workplaces shouldn’t hire junior developers .I’m saying that working with people that don’t have Hacker Quality™ is frustrating.

In my previous work place, about 90% of developers were ‘home brewed’. That means 90% of developers are kids that performed well enough on analytical exams to be put to a 4-month course and study basic programming concepts, and just enough Java to become certified code monkeys. Some, those with hacker quality, keep learning and become real stars after a couple of years. The majority remain grunts that never grow to consider their work as a craft.

My experience with working with them is that the hackers make working so much more fun. You’ve got people to bounce ideas off, learn new things from, debate about tabs and spaces. The rest make work a nightmare, and made me want to get back to my high-school way of coding (all night long, alone in the dark, with some Iron Maiden).

Being fed up with this, when I started working in a new place recently, I made a decision to try and surround myself with fellow hackers. First of all, you should start with the actual selection of a work place. Given my case (which was that I wasn’t going to start anything up by myself), I interviewed in lots of places, and chose the place that seemed to have the best and most hackers in, judging from the people I’ve interacted with in the interview process, and knowing some people from the company.

Just getting to a good work place isn’t enough, because I’ve yet to hear about a place that is 100% hacker driven (other than start ups with 5 people). You should always try and work with the better guys around. Seems like interesting projects tend to gravitate towards hackers, wherever they are. Even if the better guys aren’t working with you on your current project, grab a coffee with them. Some chatting on whatever is going on with other hackers always makes you see things differently.

Given that you usually can’t get rid of the less-competent guys (legally), your only next chance in increasing Hacker-to-Coder ratio is bringing in more hackers. If you know of any good hackers that might be in search of a job, get them an interview. Usually, that’s all it will take to get them in. Also, try and take an active part in the interviewing process. That will allow you to influence the type of people that you’ll work with, and maybe raise the bar a little bit.

I really think that investing energy in the peopleware of the workplace accounts for 80% of the evolving of coders there. And, given that we coders rarely see daylight and spend most of the time at work, that’s the lion’s share of learning opportunities you’ll have. Maybe it sounds odd to put all this effort in a place that isn’t yours, but does it really matter who’s the founder? You’re there, and better make the best of the experience.

All that leaves in the workplace is making sure your team encourages learning, experimenting and sharing (maybe I’ll cover it in another post sometime).

You should follow me on twitter here.

We’ve been working on creating a scalable and stable building and testing environment for our team.
After some checking, BuildBot was found to be the best (for our needs, at least).

Gathering the different abilities that are needed for testing our products, and the different limitations we’ve got in our testing lab, we came to the conclusion that using some sort of distribution framework is needed. Being the code monkeys that we are, we started designing a whole solution for integrating BuildBot with our distribution framework of choice, when looking at the BuildBot manual I saw it already has support for this concept, the Latent Buildslave !

One small thing is, that adding support for a new one isn’t so clear. The manual simply states that one needs just to implement start_instance and stop_instance methods and be done with it, but, in my opinion, lacks some details, so here is what we figured:

1. The start_instance method should return a deferred that, when called, will return once a new build slave is ready to go.
2. How do you return the new slave’s IP to BuildBot? No need! Once it will be connected, the master will figure it’s the one you just created (via AbstractLatentBuildSlave.attached).
3. The actual value returned from start_instance is pretty insignificant (will be printed to the log, as the manual states).
4. The stop_instance method is pretty much the same, and should take care of making the distribution framework aware that the allocated buildslave is free to be destroyed/reused.

Why don’t my latent slaves die?

As you may have noticed, once start_instance is called and a slave connects to the master, BuildBot is in no hurry to call your stop_instance once the build is completed. Actually, as far as BuildBot is concerned, that slave is there to stay (at least, as far as we figured). In case you’d rather to generate a new slave for each build, you will need to override the buildFinished method of the abstract slave, and in it call the unsubstantiate method. A bit of a headache, but that’s the way it is.

Happy testing!

P.S. If you’re using the latest BuildBot (from the git repository), try out the Console view, it’s really awesome!

You should follow me on twitter here.