ZenRobotics R&D blog launched

Go see for yourself at http://techblog.zenrobotics.com/

First real post describes a REPL for an industrial robot, with videos.

Problems with code review are symptoms of problems in your team or engineering

The only process Google forces on teams is code review. Nobody is exempt, though teams may have varying strictness in their review.

We do code review at ZenRobotics too. It mostly works, but maybe not extremely well.

I see code review (in general, not just at ZenRobotics) not working as a symptom: it indicates a problem elsewhere. I've seen at least the following underlying issues getting reflected in code review:

1. Lack of tests: if you don't have good tests, you are very reluctant to make changes in code that you think works. This means you resist the changes that others propose, since you fear you'll break your code.
2. Code that is difficult to understand (including convoluted designs or architecture): if the code is hard to understand, people will either require a lot of comments (which may be seen as counterproductive), extensive rewriting (without specific guidance on how to re-write since they didn't understand what your purpose was), or less-than-useful reviews that just look at the surface.
3. Style guide violations: both reviewers and people who wrote the code under review quickly get annoyed at stylistic comments. At Google the idea was that  you internalize the style guide under the first couple of weeks of using a language and after that you don't need reminding. Code in review with style violations may also mean you lack tool support to make style checks easy. It could also mean that your team-mates don't actually agree on your coding style, which makes it pretty useless.
4. Not knowing the components others are working on / not having time to understand them when reviewing: if you don't have at least one other member on your team who understands the stuff you work on, you have a very low bus factor - could even mean people are starting to create fiefdoms, or that code reuse is very low.

Now fixing issue no 1 (Lack of tests) or 3 (Style guide violations) doesn't make reviews free. However a lot of the cost of reviews is in fixing 2 and 4 - which you want to fix anyway. Especially, code reviews are great for implementing shared ownership and knowledge transfer.

(This doesn't mean I'm certain that code reviews suit every situation. What if you want to quickly iterate on your MVP? What if you want to quickly prototype an idea or a design? Anybody else have an idea?)

ZenRobotics is hiring!

We are hiring AI/Computer Vision/Machine Learning experts, hard-core coders and automation/mechanics/mechatronics engineers. If you think you have what it takes to make a robot sort waste (very fast, very accurately and cheaply enough) come and join us. You are guaranteed to have a chance to change the world.

Farewell to old blog

My old blog's tagline was "Symbian, CS research and angst". I no longer write Symbian code, nor do I work as a CS researcher, and may even have grown out of some of the angst. It's time to move on to a different blog - this one.

As the last piece for the old blog I wrote a (long) post-mortem on the technology that was Symbian.

My take on non-recursive make

There are a few things every programmer has to try their own hand at: a unit-testing framework, a compiler, a DSL, an open-source project ... and a build system.

Here's my version of a non-recursive make: http://github.com/mikaraento/make-modules for a mixed C++/Java/clojure build. No directory stack needed!