Hacker News Reader

Comment by shoo | Hacker News Reader

On another hand, many commercial programming tasks or programming roles are relatively mundane or lower-skill, and do not require exceptional levels of programming ability. If an exceptional programmer was dropped into one of these roles, they might quit out of boredom, or try to refashion the role into building tooling or systems to automate away some or all of the drudgery, but perhaps at the cost of not delivering enough immediate business value to justify their employment, or spending 100 hours building a beautifully elegant solution for a class of problem of which there will only ever be a single instance, which can be solved with 1 hour of bad scripting & manual data tweaking in a spreadsheet. Mediocre work performed in situations demanding mediocrity can be sufficient while producing economic value & providing for one's income.

View on HN

I agree that an exceptional programmer would not only not be appreciated in a job like this but their work/code will also be misunderstood and create a huge libility for the company. Hence tgh industry dumbed everything down to the lowest denominator (not absolutely lowest but quite low) such that every role is replaceable (hint: it has to look like an ordinary cog in a system)

> I agree that an exceptional programmer would not only not be appreciated in a job like this but their work/code will also be misunderstood and create a huge libility for the company.

Writing complicated and unmaintainable code is not the hallmark of an exceptional programmer.

Rather it is writing simple code to solve simple problems and writing understandable code to solve hard problems.

Code other's cannot wrap their head around is not good code and even the clever author will have a harder time debugging, re-factoring or adapting it. Chances are it would be a liability even on a solo project.

I agree. Never underestimate a bad, but determined programmer.

The worst part is he’ll feel extra smart afterward, because he finally figured out enough of the bugs in his horrible implementation to call it “done”, and he’ll likely be re-visiting this code for a long time to come, as issues pop out that he still doesn’t understand fully.

The energetic stupid programmer is the single most destructive thing you can have on your team and in your codebase. They make messes for everyone else, and a dummy writing bad code can produce more volume than even the best coder writing good code.

Eventually, guardrails and processes get put in place to protect against their damage, and the whole team slows down. Good coders walk, and you're left with the dummies, cranking out a high volume of low quality code. It's absolutely tragic.

When you build a flexible high-performance templatized system, hand it off, and realize a few weeks later that an energetic stupid coder has "written" more than 50 copied and pasted hard-coded classes from that codebase for the different places it was called from, only to have him and the non-coding manager push hard for sticking with that approach because the work is "nearly done", that's when you brush off the resumé and walk.

Teams need workaday coders sometimes, and every coder should know how to just grind out a big refactor or massive change. However, I aim for coders who are lazy enough to find a cleaner way to do it and smart enough to know they can.

The codebase is probably not that good to begin with and quite frankly doesnt need to be

I think programmers have a chip on their shoulder about the importance of the work they do. You are not painting the sistine chapel

Most programming is what you refer to as "workaday"

When you’re trying to scale teams of thousands of programmers, the dynamics of sloppy ones leaving traps and cruft in the codebase become the things you care about. At least, it’s the stuff I care about now.

Much of what we do is mundane, and, if we do it right, more of what we do should feel mundane because the right abstractions and metaphors already worked their way into the tools and systems we use. However, I still contend (and I’m far from the only one to hold to this) that the worst thing you can have on your team is someone with a lot of energy but poor judgement/awareness. Doing it well is hard. Doing it poorly is far easier, to the point that there are folks that will be a team net negative.

> You are not painting the sistine chapel

This is very uninspiring and destructive thinking. Just think of detailed and pristine handworks of everyday tools found at excavations, or the charters of guilds in the middle ages. It's not about what you do. It's about you doing it.

> this is very uninspiring and destructive thinking

Good! The code most people write are not things that will last the ages. the romantic notion of guilds in the middle ages is silly and what I was referring to regarding the chip

It was referring to coding as being the same as any craft. You are being hired to do a job, you don't know how long your code lives and needs to be maintained. "The buyer is a lady, I will not make the effort to make that hammer last long, how often will she use it" is not someone I'd do business with.

My point is do your job well of course but dont pretend the output is something more than it is

At the end of the day, it's a paycheck for something you hopefully enjoy. And no matter how well crafted you think it is. Someone else is going to come along in the future and think its crap

Again going back to the chip on the shoulder

Somewhere there is a line between pragmatic and negligently flippant.

There are reasons to care about code quality beyond a chip on one's shoulder. Scalable, extensible, and readible systems retain optionality and can provide substantial business upsides that were unknown (and often unknowable) at creation.

Conversely, analysis paralysis can prevent progress. It's a balance.

Organizationally, energetic stupid programmers (those who fail to see around corners and fail to carry the lessons of these principles with them in their work but still have high "output"), left unchecked, will drain organizations of talent.

We work hard to avoid this heavy delivery bias on our teams because the metrics-focused race to the bottom is a very tough thing to undo. Quality is much easier to keep than to add.

But who reflects those values at company wide scales?

Building something in 100 hours that satisfies a class of problems but will only see use once is definitely not smart. It's called taking advantage of your employer to satisfy your own curiosity. Do that in your free time of your job is not one where that solution will see millions of uses (meaning you are not working for - depending on decade we are talking - Bell Labs, IBM, Microsoft, Amazon etc.).

If you are that good but work at a regular company, build an awesomely good script that is maintainable by even a mediocre programmer that comes after you and spend the other 55 minutes of that hour doing the next task. Then go home when everyone else goes for lunch without anyone noticing because you did the work of 2 people already anyway. If you have a good boss they won't care and give you awesome life work balance that you definitely would not get at Bell Lab, IBM, Microsoft or Amazon because they know how to exploit your drive and passion for their own good. No you don't make enough money to get that time of your life back.

The fact that many intelligent people are still fat means that they like everyone else don't have perfect self control. So any tips on what people should do if they were in perfect control of their emotions doesn't help, knowing how to think rationally and being capable of acting rationally are two separate things.

"spending 100 hours building a beautifully elegant solution for a class of problem of which there will only ever be a single instance"

That's not an "exceptional" programmer. An exceptional programmer who does mundane stuff has this posted on their cubicle wall: https://xkcd.com/1205/

Problem with that comic is that it doesn't take skill acquisition into account. Automating something increases your skills in automating things and therefore can be worthwhile even if automating this specific task isn't.

Lets say that automating a task saving you 1 hour takes 10 hours. Is it worth it? No, you'd say. But what if you had 100 such tasks, and the time to automate them goes down as you become a better programmer taking a total 50 hours? Then it would be worth it, but you would never achieve that level of expertise and therefore lose that productivity increase if you followed the advice of that comic, since none of the tasks you'd come across would be worth automating when you got to them.

>Problem with that comic is that it doesn't take skill acquisition into account.

I'd argue it can help skill acquisition to avoid getting into one thing too deeply, because the more different items you do, the more the commonalities appear; the more chances you have to see if your approach is optimal.

Knowing what’s important, and having the discipline to focus on it is one of the most important skills to acquire.

I think "having the discipline to focus on what's important" means consistently and periodically interrupting yourself, and asking "am I doing what's most important".

I think there's a tension between this and the deep concentration or "flow state" that people like to talk about on HN. In effect, there are different value systems, and people have a hard time stepping outside of that.

This! This is the reason we don't breed competent programmers often. The system has dumbed down most roles that a programmer is little more than a plumber. When there's that one occasion where it makes sense to write smart code folks aren't trainer for it and it becomes a viacious cycle.

> Problem with that comic is that it doesn't take skill acquisition into account.

This. Moreover, the frequency of a task may depend on its automation. We would not have Continuous Delivery today if someone didn't make the effort to automate deliveries, would we?

> a beautifully elegant solution for a class of problem of which there will only ever be a single instance, which can be solved with 1 hour of bad scripting

This is a stupidly common problem, and one that is hard to fight against. Why would you decline a good / inspiring part of the codebase, coupled with the unsureness that during the lifetime of the software this would come handy.

Reply on news.ycombinator.com