Hacker News Reader

Comment by yarg | Hacker News Reader

> before we can become better programmers we have to pass through being mediocre programmers

Sure it's true, but it leaves out a fundamental truth about programming (and technically complex disciplines in general): most people that attempt programming will never be a good programmer - indeed most never even cross through the gate of mediocrity.

There seems to me to be a superegalitarian notion that all people given the same opportunities will be capable of achieving, if not the same, then comparable results on a given task (or set of tasks of a given type).

That simply is not true - "fake it 'till you make it" is not universal.

View on HN

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.

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.

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?

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?

> 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.

I gotta ask, What do you consider good?

There's plenty of working software that's good enough. Made by fair programmers who don't care about lisp or FP.

Is your scale of good affected by what you see here on HN? Because I feel like the front page of this site has the same effect as Facebook for skewing views of reality.

I’m not sure how to express it very well, but I interact a bit with people who I’d consider “good” programmers. I don’t think I’d correlate it with experience or effectiveness at a job, a good many of them haven’t even made it out of school yet. But they tend to be able to internalize programming/mathematics concepts that by many are considered difficult or complex. I know some will disagree with this, arguing that things related to experience like domain knowledge, ability to effectively work and lead in a team, understanding business needs, etc. and I don’t want to diminish the importance of these things in a professional context. However, I think there’s a good bit to programming that’s more purely technical and more related to raw intelligence (IQ or whatever you want). These people are able to easily understand things that I can’t seem to put together in my head very well.

I'm not sure how relevant it is today but one litmus test I found years ago was how naturally they grasped the concept of a pointer. If a programmer grokked pointers that was a good indicator that s/he was on the path to being a good programmer. It's probably just a proxy for being able to think at a level of indirection.

This was one reason I thought programming the classic Mac was great training — the nature of the memory manager, where most data structures were double-indirected pointers and the inner pointer could move at will -— you had to understand pointers or you’d never be able to produce a stable program.

Edit to add: and yeah, I’m also not sure it’s relevant outside OS-level programming, which most people never get near at this point.

I wonder, is being able to see a leetcode problem that relies on a generalization of merge sort to solve, never having learned merge sort, and coming up with a merge sorting approach the kind of person who can be a programmer. Does this person even exist(like how many people in the world have that strong of abstract reasoning skills to be able to pull that off).

I generally define things more in terms of "not bad" or "less bad" - to me software development is too rapidly an evolving discipline to allow for a static definition of good.

But things like: - don't copy, paste and tweak a piece of code when additional parameters are a better option, - don't grossly overload a definition with parameters instead of breaking up a function.

There's nuance there, and the question of what amount of technical complexity is reasonable for a given problem - but if I start thinking about that I'll never stop digressing.

I have dealt with an entire office of people who seemed to code purely in bug-filled technical debt: you could tell when they clocked on because the build broke an hour later.

As far as FP is concerned, I think that the memory and performance penalties are often too heavy: there's certainly a place for mathematically provable programming - I just don't know what it is.

> As far as FP is concerned, I think that the memory and performance penalties are often too heavy: there's certainly a place for mathematically provable programming - I just don't know what it is.

FP isn't necessary for mathematically provable programing. Dijkstra and Scholten did a ton of work in this area that conclusively demonstrated that. I can't do them justice in a post here, but to a first approximation the trick is that you reason about imperative programs as transformations on a state space, which is to say you think about functions.

A simple example: We want the predicate x = 3 to hold for all preconditions. The code "x := 3" establishes that predicate everywhere in the state space. That is to say, no matter what x was before the assignment, afterwards the predicate holds. While plenty of bytes have been spent on discussing why this is totally impracticable for real programs, whatever that means, we also have buzzwords like "defensive programming" that follow the same philosophy: we should write code such that when it has executed no matter what the state of the system was initially, afterwards it satisfies some specification.

Cool.

I just had an interview yesterday and took me a long time to solve a problem under pressure (few loops and some dictionaries and list and sorting), later last night at work found some complex issue debugging some packets and code. Is hard to measure what is good. I was thinking that maybe creating a project that is used by hundreds makes you a better one?

It's good enough for a time until a competitor comes in with better software and you go bankrupt due to unable to compete on price and usability.

It's a trade off. But if you spend ages getting to market because your jumping at shadows. Gold-plated software doesn't mean good software. I think we should just try and call good software that which fits time, budget and scope. And works!

My bar for good: willing to read the existing documentation and say "it's terrible".

These statements are perfectly compatible with one another:

“ most people that attempt programming will never be a good programmer”

“ all people given the same opportunities will be capable of achieving, if not the same, then comparable results on a given task”

Persistence is exceedingly rare. Falling short of your capabilities is exceedingly common.

Yea this. "people given the same opportunities will be capable of achieving" leaves out the difference in time spent.

On the one hand, I don't know anyone who has put in thousands of hours and not been a decent programmer. On the other, that mixes cause and effect a bit, since it takes a certain type of person to even want to throw a thousand hours into programming in the first place.

I feel like if you're reading this book, there are good chances you're already better than most and that you're a good programmer or on path to become one. The difference between mediocre and good is often that you're seeking to improve.

Considering that there’s no consistent definition of what is meant by mediocre programmers vs “good”, “really good” etc, I get the feeling that this isn’t a very productive approach to measuring the skill of programming. As the responses to your comment demonstrate, it’s hard to get a common definition and thus I feel this discussion to be fairly pointless.

I will say this though: there is nothing magic about programming, or really any technical skills like it. It’s all about practice and getting better with time. I do sincerely believe that anyone can be a productive programmer that delivers within the constraints that are demanded of them.

If you’re talking about “prodigies” or “polymath” or people that have certain conditions that allow them to be more productive without the same amount of effort, yes, I do agree such people exist. And they exist in every field. I don’t think they should be what most programmers should try to emulate though.

Yeah I’m not sure. I’ve had a good bit of passion for programming through both my hobbyist and professional career (naturally more through the latter) and these days I find the things I get most excepted about or find most interesting I’m not really able to understand fully. I guess we all have our limits, but I’ve tried a few different things in recent years that I’ve effectively had to give up because things wouldn’t “click” no matter how much I read. Unfortunately it’s kinda killed off a good bit of that passion, and I’m not particularly interested in what options it’s leaves me.

Not only this, but very few people even ask the simple question, how do I become a better software engineer.

The four quadrants of competence applies.

Q1. Unconscious Incompetence. Q2. Conscious Incompetence. Q3. Conscious competence. Q4. Unconscious Competence.

Most people never leave Q1 phase, just muddling through their career and stagnate or burn out.

It takes lot of effort to jump from Q1 to Q2 and become aware how difficult things are in reality. Some take effort to become better and these types will usually succeed over time.

Lot of senior level people end up in Q3 and it's comfortable zone to be in. But, it takes more significant effort to jump to Q4, where they can gain additional pull to be able to lead and make significant more money.

It's significant journey and the timescale is not linear, it's logarithmic in some situations and extremely long in other situations.

> but it leaves out a fundamental truth about programming (and technically complex disciplines in general): most people that attempt programming will never be a good programmer - indeed most never even cross through the gate of mediocrity.

Isn’t this true of almost everything?

Most people who attempt [x] will never be at a good at [x].

Technical fields aren’t special in this regard. Replace [x] with running and it’s just as true despite the fact that just about everyone attempts to run at some point. And yet the vast majority of people aren’t proficient runners in any shape or form. But just about any activity could replace running and it’d be just as true.

Attempts aren’t worth much. Intention and dedication are what make most people at least OK at their craft.

OTOH humans are some of the best long distance runners of any species, with the proper daily routine, most humans can endurance run better than most animals in the world. Depends on what yard stick you are using and in what context.

Eh, mediocre is usually defined as something like "middling" or "middle-of-the-road" or "average". It's plausible to me that most reasonably intelligent people who try very hard can become "above average" programmers. "Good", I don't know.

Sure, but I don't think we're working with a single peak distribution here - and good luck coming up with a workable definition for "reasonably intelligent".

It seems like the author addresses that in the contents of the book. In the first chapter, they say that there is no way to close every gap of knowledge, and the only difference between a good and mediocre programmer is contentment.

Simply not true?

Given exactly the same opportunity you think they cannot get comparable result? So you are saying there is genetic (dis)advantage to technical things that cannot be overcome?

Not sure if it's genetic, but if you've read the blub paradox about languages, I think there is something similar about how people think and solve problems. Maybe the higher level abstractions can be learned or maybe not. IQ is a real thing.

IQ is a real thing and the vast majority of people’s IQ is comparable... which weakens the original point not strengthens it.

The bulb paradox isn’t really a thing... just a single opinion from Pg right? I’m not sure I agree with it.

My observations of people is that some forms of abstraction don't click with some people. What if there are 25 or 50 types of abstraction we need to master in order to be really high IQ? That would look a lot like PGs blub, and variations in which types individuals grasp could explain the distribution of IQ.

Makes me wonder what it's like to be both smarter and less smart than I am. What pieces am I missing? What advantages do I have?

I don’t buy the blub analogy. There are lots of languages I don’t know that I know are more powerful than the ones I do... it isn’t even difficult to think about.

I’ve met lots of people smarter than me too and I can easily identify why: oh she really knows more about x than me, or he’s very good at destructuring things...

Ask people with foxp2 mutations whether or not genetics can convey insurmountable obstacles.

I was referring to more subtle gene mutations in terms of the “average healthy human” kind of range. But you knew that.

Don't be disingenuous - you were attempting to overrule a reason based conversation with an emotional call to the notion of universal genetic equality.

(So I dismissed you with a sarcastic quip.)

That's not how evolution works, no matter how unfair you deem it to be. Life does not give a shit about fair - all that matters is what survives long enough to proliferate.

Feelings be damned.

The genes that convey contextually useful characteristics (although generally inclined to spread rapidly) are not at any point evenly distributed.

In some context genes that were useful in ancestoral context loose their use, or even become a burden.

Genes for intelligence may increase the ability to handle novel situations, but they also increase energy utilisation - which makes them a dietary burden.

You’ve attributed a lot more to what I said, than I actually said.

Apologises for the trigger. Not my intent.

All good - I may have been reading between lines that were not there.

Reply on news.ycombinator.com