Who do you think will be able to run faster after a year of training, given that both have similar physical abilities: Somebody practising eight hours a day, or somebody practising two hours a day? Most likely, it will be the one practising eight hours a day. A similar logic applies with technical skills, and this logic becomes very real when you transition from an engineering or tech lead position into a management position.

I am a middle child, with an older brother and a younger sister. My brother was pretty jealous of me when we were little, so, in order to avoid triggering his jealousy, I learnt early on to care about his interests, sometimes as if they were my own. When my sister entered the scene, this tendency was even intensified. She was the first girl in the family, and under “special parental protection” - meaning that if she was unhappy, one of her brothers was likely to be identified as the culprit. Better keep her happy, then…

Situation: I noticed that one team had almost no discussions around their code changes before they were merged. Other teams did. They would make suggestions for improvement, point out flaws, and sometimes do several rounds of commenting and re-committing before code was actually merged. This was the point of code reviews, after all.

One of the most interesting things I took away from The War of Art by Steven Pressfield is the distinction between territory and hierarchy. Pressfield introduces the concepts as follows:

Earlier this year, I was told about a discussion among higher-ups at a tech company. There had been a survey among all employees, and the result was that many of them were dissatisfied with the lack of perspective they saw in terms of personal advancement and development. There were no career tracks, nor were there personal development plans of any sort. A higher-up manager reacted to these concerns in a very particular way.

When I was about to finish this post, I discovered Why Startups Should Train Their People by Ben Horowitz, which was written in 2010 and covers most of what I am writing below, plus some additional points. If you have time only for one of the two, I advise you to go and read that.

In a previous post, I tried to provide an analogy to help non-technical people understand why the number of produced lines of code (LOC) is not a good measure of developers’ productivity. While there may be a demand for such an analogy, the demand is probably even higher for an analogy for refactoring. I sometimes view refactoring as the eternal apple of discord between developers and stakeholders (and I am not saying developers are always right to refactor). The need to refactor is not always immediately clear to management or other stakeholders, and, if they have never seen a large codebase from the inside, who could blame them?

It’s 2016. And still, some business managers seem to think that using lines of code (LOC) produced is an appropriate KPI for the productivity of a developer, or a software engineering department. Since history has a tendency to repeat itself, I have a feeling that this will even be the case in, say, ten years. Software engineers themselves know, of course, that measuring productivity in LOC is not the way to go. However, non-technical or even semi-technical people do not know this instinctively.

I recently read Drive by Dan Pink, and the most surprising thing for me was how rewards can lead to decreased performance and intrinsic motivation. This is counterintuitive - usually, you think of rewards as something that should increase people’s motivation. However, Pink recites a couple of fascinating studies and findings.

A lot has been written about the concept of servant leadership, and while I like it and agree with it a lot, I sometimes wonder how to interpret it in certain situations. Does servant leadership mean you do all non-development tasks yourself, to shield your people from distractions? Or are there certain tasks that are fine to delegate?