Geeky Communication book cover

Yours free: An ebook on effective communication!

Get Geeky Communication absolutely free, and learn about effective communication in a technical environment. Just enter your email address below. No spam ever, guaranteed.

The Horowitz-Buckingham Leadership Argument

There has been a lot of discussion lately about Steve Blank’s article in which he argues that Tim Cook leading Apple is comparable to Steve Ballmer leading Microsoft: Both followed after iconic visionaries - Steve Jobs and Bill Gates, respectively - who embodied the company like no one else. Both were able to increase revenue and profit numbers at an impressive scale. However, both also failed to stimulate and harness the innovative powers within their respective company, and relied mainly on their strong brand for several years.

[Read more]

Recognizing a Training Dead End

Not all training is equally effective

Do you remember Math in school? If you were good at it, did you help others when they were struggling? Did you always succeed? I remember that I did not. There were these recurring situations that left me clueless on how to make my point, and how to get my tutee to understand. For example, I would try to explain to a friend how to solve a simple equation with X as an unknown. This would go something like this

[Read more]

On Being Surpassed Gracefully

When you become an engineering manager, others might surpass you technically

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.

[Read more]

Avoid Shuttle Diplomacy

Don't be a shuttle

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…

[Read more]

Giving Feedback Without Much Context

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.

[Read more]

What is Your Territory?

Your territory is where you build up mastery

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:

[Read more]

A Competition of Goals?

Which goals do employees really pursue?

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.

[Read more]

Organizational Teaching

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.

[Read more]

Refactoring For Non-Coders

Learn how to refactor a house!

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?

[Read more]

On Bricks and Code

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.

[Read more]