Steve Jobs once said, a line of code you don’t have to manage is a line of a code you didn’t write. What he meant was less code that does the same job is better than more code. But how do you make sure, as an engineering or product manager, that your developers are following the advice? Especially when teams and projects inside the company get bigger and more complex.

Andreas Klinger asked the exact same question on Twitter recently:

As you can see the actual question wasn’t about less code specifically but rather how to increase the effectiveness of engineering teams. Effectiveness is not directly related to speed. And some times they run counter to each other. But let’s just assume that Andreas meant overall productivity of the engineering teams. In that regard having less code is the ideal form of productivity tip. The problem, of course, is the inherent complexity in seemingly simple advice.

In many ways coding is like writing. Only you want computers to understand what you are trying to say. The good part is computers are not multi-dimensional thinkers like us. So if you write five lines to make it understand something instead of one it won’t complain. Or get any wrongful contextual messages hidden in those five lines. But that does not mean you should take advantage of the fact. For one this tendency will make your code lengthier and harder to manage. Second, at some point in time, another human will read your code. And …

So just because a piece of code is doing the job does not mean it can’t be better. Like writing, revisions can make it better. Always think of code that did the job as mere the first draft. It’s not wise to publish the first draft. The advice might seem counterintuitive because you are delaying deliberately. But it can go a long way in reducing the complexity and manageability of the code in the future.

The thread ensuing the tweet above is pretty good and I would encourage you to read yourself. Below is a summary of themes more prevalent than others with my unsolicited commentary.

Basecamp’s six-week cycle model over 2-weeks sprints: Here is the original blog post from Jason. The idea is, sprints result in rushed code because well you have to finish something in two weeks. Six weeks is a long enough timeframe to do deep work while short enough to manage.

We believe there’s a great six week version of nearly everything. — Jason Fried

No code reviews: I do get the sentiment but there is nothing inherently wrong with code reviews, IMO.

Provide an environment for deep work. No meetings: 👊

Use PR instead of a ticket: Yup, more Github, please.

Avoid refactoring: Joel Spolsky has more to say about this here.

Fix-it Fridays: 🤔

Quantify engineers’ work: It’s hard to quantify an engineer’s work in terms of revenue. User experience can be a good scale though. Another could be how clean, or less, the actual code is.

No Blame culture: Perhaps the root of all evils. Encourage your team to take responsibility not blame.

Mute Slack: ✔️

Remote work: Writing and coding are both better while you are alone.

Hire a PM or EM who gets people: Bingo.

Small teams: A team you can feed with no more than two pizzas is an ideal team.

Trust the devs: Trust is a two-way street. It’s easy to start giving it first than to expect.

Invest in tooling: Yes, iMacs and MacBooks, please. And if a MacBook is post-2016 than an accompanying keyboard too. 😛

Don’t staff a project with more than one person until the scope is well understood and work can be divided among different people with little to no communication. Mythical Man Month and all that: Couldn’t agree more.

Hire engineers who can write: Killer combination.