Hacker News Reader

Comment by qume | Hacker News Reader

FTA: "Programmers are most effective when they avoid writing code."

I'll take an average coder who only codes what is needed over a brilliant one who is constantly going down rabbit holes unnecessarily.

View on HN

That makes sense, but our experience is slightly different.

We have a 20x (not a 10x) programmer. He closes literally 20 times the number of issues that other programmers close for a given time frame. Plus, his issues are almost always fixed or completed properly without needed to be re-opened. So, his actual throughput is greater than 20x that of others.

He is good at what he does, better than almost everyone else put together. I don't care if he goes down rabbit holes, spends 90% of his time walking down the hall mumbling, or if he sits in the break room staring into space. His salary is higher than others in the same role, but not 20x. He wins and we win.

What do you see/what do you think he does differently compared to the rest of the team?

Really, I don't know. He's tried to mentor others but whatever he tells them doesn't "stick". He might be more intelligent than others, and he is intelligent. He could just make better, faster connections constantly. Maybe he just listens to the inner voice and types whatever comes out.

When you ask him, he just shrugs and says he does his job.

If you start solving highly abstract problems (including chess) before you're eight years old, that helps. Deciding you're going to become a concert pianist at eighteen doesn't work if you haven't picked up an instrument before then. You can become a pianist, but not a concert pianist.

> brilliant one who is constantly going down rabbit holes unnecessarily

Ha, sounds like an oxymoron

Maybe - I think the missing component is their level of "laziness" as Bill Gates defined it. A brilliant, but "lazy", coder will find the most efficient way to compose a solution that meets the requirements.

But it's definitely not an oxymoron to say that some brilliant coders can go down rabbit holes at the expense of their own (and company's) time and productivity. They may spend lots of time reading white papers, improving a design/implementation/test-suite beyond what is required, etc. It's just these coders don't place a high value on being as efficient as possible from a PM's perspective, but might be able to solve a problem 10x as difficult as the guy who is closing his tickets within hours of assignment.

This reminds me of the following by General Freiherr von Hammerstein-Equord:

> "I divide my officers into four classes as follows: The clever, the industrious, the lazy, and the stupid. Each officer always possesses two of these qualities.

> Those who are clever and industrious I appoint to the General Staff. Use can under certain circumstances be made of those who are stupid and lazy. The man who is clever and lazy qualifies for the highest leadership posts. He has the requisite nerves and the mental clarity for difficult decisions. But whoever is stupid and industrious must be got rid of, for he is too dangerous."

I'm clever and stupid.

I like to call it strategic laziness. Knowing what to do, and more importantly what not to do is key.

Or you know, writing an entire library instead of filing four PRs against an existing one, with a user base, documentation, stack overflow entries and resume appeal.

Nothing more dangerous than a smart but bored developer.

'efficient as possible' is only measurable in terms of the task at hand. Being smart educated and hardworking does not necessarily make you better at your job if you spend most of your effort tilting at windmills.

At times it really is better for everyone to just move on from a comfortable position and stretch your wings as it where.

I would much rather be refactoring code from that guy... I seem to be refactoring the industrious and stupid code.

I see that, but one type of really good dev is one who is super focused on the small details, and it seems to be human nature that it's hard to do that well and keep the big picture in your head at the same time.

I think these guys are totally capable of thinking big picture, but they are often just not in that 'mode' and hence the tendency to inadvertently find themselves writing code that if they took a breather and sat back and re-evaluated, probably wouldn't write.

I'll second that sentiment.

The largest source of your tech debt may in fact be that brilliant one writing volumes of code destined to become the collective headache of future dev teams.

Only building what is needed is only part of avoiding writing code. I'd say that during the first half of my career, I was completely ignorant of just how powerful shell scripting was for increasing productivity and reducing the amount of code that I would need to write and then later have to maintain.

One of the best pieces of advice you can give to a young developer is to learn about the tools already available on the operating system and how to build solutions by composing them via scripts.

It was really only after being a few years into a job where the primary development environment was OpenVMS with a crusty old manager that knew DCL inside and out that I fully understood - and boy oh boy did people think I was some sort of freak 10x developer when in fact I was just writing a few hundred lines of C to fill in the gaps between what I could get for free.

I really hate developing on Windows, but PowerShell is an amazing tool (I saw an interview with the creator who said that he started trying to do a UNIX-like shell but gave up when he realized that it just doesn't fit in the Windows paradigm. So he modeled it off of VMS. If you want PowerShell to act like bash, you're doing it wrong). The pipeline is passing around full .Net objects and the feature set is amazing. If you program Windows for a living and don't learn PowerShell, you're missing out on a lot of free productivity.

Lately, I've been using Linux more and am all in on shell scripting. I am following some advice I got to explore man pages more frequently and it is paying off. I even found an old System V printed manual and sometimes flip through it, finding random commands that I had no idea existed and thinking about how I could use them.

This is very dangerous advice. Modern Linux with systemd and mature programming languages require very little shell scripting. I saw people building deployment pipelines in shell and how ugly it was. I worked with a team doing batch processing in the shell and how many people where needed to make simple changes.

I absolutely love the Linux philosophy. Piping outputs means programs are functions. So I can combine programs to get what I want. The only gripe I have is that bash is a pretty hard language to read and write.

I'd highly recommend the xonsh shell for scripting if you're familiar with python: http://xon.sh/tutorial.html

Once you do tutorial and learn the rules for going between shell and python, it's super easy to slice and dice.

I have always disliked that moment of "yes, a shell script is probably the best tool for this job" that then leads me to banging my head against bash syntax for an hour. Python libraries like `sh` are great, but still a little high overhead. Now the twice a month I have to shell script I find to be pretty fun, and I'd highly recommend xonsh.

Great PyCon 2016 talk on it here: https://www.youtube.com/watch?v=uaje5I22kgE

I barf out intermediate state to JSON all the time now that jq is a thing.

In my view this highlights an issue, which is identifying the 10x programmers, versus the -10x programmers.

Unless one knows that a certain path will turn out to be a rabbit hole, it is by definition not unnecessary.

Reply on news.ycombinator.com