Live data from Hacker News

The Mediocre Programmer

themediocreprogrammer.com

81–90 of 95 posts

Re: The Mediocre Programmer

#81

Earlier quoted context omitted.

"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 pro…

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

Re: The Mediocre Programmer

#82

I half read, half skimmed the contents, and what I found was significantly divergent from what I was hoping for. I was hoping to find some combination of a breakdown of potential paper cuts that hold programmers back, and an insightful breakdown of seemingly insurmountable problems that keep programmers in their provincial comfort zones, providing a series of bite-sized victories to lead one to greatness. Instead I f…

I agree, this book was free so its on us, but I must say I was fairly disappointed as well. Skimming through it I found it was providing general statement whereas I was expecting specifics. At the beginning this has the self-help flavor that tend to be hyper general. Yet towards the end it got a bit more specific. I feel like everything could've been summarized in max 10 pages or down to a blog post.

Re: The Mediocre Programmer

#83

Earlier quoted context omitted.

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

Re: The Mediocre Programmer

#84

Earlier quoted context omitted.

> 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

Re: The Mediocre Programmer

#85

Earlier quoted context omitted.

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?

Re: The Mediocre Programmer

#86

Earlier quoted context omitted.

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.

Re: The Mediocre Programmer

#87
post #49

Earlier quoted context omitted.

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,…

But who reflects those values at company wide scales?

Re: The Mediocre Programmer

#88
post #24
post #19

Earlier quoted context omitted.

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 wh…

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

Cool.

Re: The Mediocre Programmer

#89
post #2

> 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 t…

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?

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

Re: The Mediocre Programmer

#90

Earlier quoted context omitted.

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 adv…

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

Post reply on HN