The Mediocre Programmer | Hacker News Reader

The Mediocre Programmer

themediocreprogrammer.com

129 pointsceladevra_91 comments

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 found number of already well-tread tropes of self-acceptance, limiting the amount one compares one's self to others, finding friends, and taking breaks. Furthermore, it does this without presenting any kind of new model to achieve this within the programmers existing emotional, executive and motivational budget.

I don't know if I'm staggeringly abnormal but I'm already acutely aware of those requirements. Absent some seemingly miraculous improvement in my executive function, in order to effect change (at least in me), the content needs to provide either compelling anecdotes as to why I should try harder, or a new model that provides a path where the extra smashing of face is not required.

I fully acknowledge I have no claim of liability for the content not meeting my hopes, given the generous lack of cost, but I must say I'm disappointed.

Without any sarcasm, maybe that's the content you need to write.

The point of the book is to help people manage the struggle, not how to become a great programmer. If that isn't what you want then you can go find some other book.

The authors own explanation:

> There are plenty of books on how to become a better programmer out there. Books like this tend to have checklists and other advice that the author deems important enough for you to do in order to become a better programmer. They tend to focus on specific improvements like choosing a better editor, writing better test cases, or drinking lots of water. Those books have lots of useful advice, but they read like a laundry list of things that you must do all at once in order to succeed. This book will try not to saddle you with more work (you likely have enough as it is). Rather, we'll discuss what it feels like to be a programmer. We'll talk about the emotions in being a programmer; the feelings of frustration, guilt, anger, and inadequacy. We'll cover the struggles in learning new things and keeping your skills current. We'll talk about those times when you feel like giving up and walking away from computing and whether those feelings come from a place of love or a worry that you're not keeping up.

So basically the book is teaching people to accept their mediocrity and be happy? Kinda like brainwashing people into being less ambitious, to counteract the brainwashing they experienced that made them too ambitious relative to their potential and abilities?

Those sound more like expectations/goals/perspectives. Brainwashing reads like someone is jamming this stuff down your throat

Yeah, brainwashing carries a negative connotation. I'm not sure what the right verb would be. "Persuading" is too weak, since we're talking about changing the person's fundamental value system away from being too ambitious.

Not everyone wants to go up the ladder all the way to the top, many are happy to deliver whatever makes the customer happy with what is being asked today, without caring about what is going to be the next great thing, most likely already legacy in 5 years timeframe.

The dark matter developers that don't care one second online communities like HN and Reddit do exist, never got paid to attend a conference even on their own town, and have more things to do with their life than hunting for stars on github after work.

It's a very popular topic.

See the biblical book of Job. Countless self-help books. Scientology. Paulo Coelho books.

And so on.

I will admit, I forgot that description as I got deeper into the content.

In terms of managing the struggle, though, at least in my experience, a lot of it comes from having broken models of effectiveness. The net result is having to use a lot of emotional energy attempting to discern what the optimal answers are in a deeply ambiguous sea of grey, with the added difficulty of especially ruthless hindsight. Again, maybe my expectations were grossly miscalibrated, but there wasn't much in terms of orienteering in that environment.

What advice there was: the regular, time-boxed 'containers' of learning, struck me as deeply taxing on someone who struggled with context switching or executive function. Further the exhortation to seek out like-minded peers would be especially painful (non-?) work for someone with social anxiety.

I guess what I wrestle with reconciling is the desire to unconditionally affirm and pastor those in the depths of their struggle, with the advocated actions that would often be inconceivably costly to those most in need of that affirmation and support.

Maybe the impersonal written word is a sub-optimal medium for this mission?

i have been mentoring wanna-be programmers for a while. 15y old and 40y old. Men and Women. In big companies and in tiny companies. For few weeks, and for many months. And... most do make it. Some don't. Not very proportional on abilities/capabilities, AFAI see them. It seems to depend on internal flame.. and some humility. Internal eagerness to do exactly that thing, And be useful. That desire keeps one growing, trying, failing, rising again, finding ways, learning about self by looking from "aside" (controlled shizophrenia IS the state of programmers mind), asking others, helping others, and repeating.. Common advices are difficult, everyone's struggle is different. Hence these taste like usual mumbo-jumbo.. here are some: do not fight your daemons, harness them. Find out weaknesses, and walk around them. Far away if need be. Or straight across them under different angle. Observe and study everything about yourself. Not all weaknesses are equal, are most are not weaknesses per-se, it's the perception that gives them the name. Ah, and same thing about the strenghts - Sometimes it might be better to avoid to ride a strength as it may take you too far, too fast..

There are many many meanings of the word "better", in "better programmer".. i'd prefer the ones closer to "better person" than to "ultimate machine". And.. the ambition.. may not be the best tutor. Persistence.. might be better.

It is important to find yourself a project/s of your own. Nothing too great, can be tiny or insignificant to others. Then don't give up until you do it.

And.. Have Fun. If there's never fun, then this isn't your thing. Abstractly said, programming is the ultimate boredom, and i only manage to do it for 35+ years by searching new ways of finding fun. Nowadays it's mentoring people. What's next.. will see :)

Me too, however, are we just crazy and hurting ourselves to achieve a highly lauded place in our world? Are you filled with the sort of general malaise that only the genius possess and the insane lament?

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.

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

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

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

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

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.

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.

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.

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.

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.

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.

Being a mediocre professional is great! Do you complain when the guy cooking your meal at a restaurant is a mediocre restaurant cook? Or when the doctor prescribing your medicine is a mediocre doctor?

Anyone who is mediocre in their profession should still feel pride in what they do. Are you among the best? Maybe not, but you are good enough that people value what you do and that is what matters the most. If you find yourself in a position where nobody values what you do then you have a problem and need to fix it as soon as possible. But in that situation you aren't mediocre, instead your main goal will be to work hard so that you can become mediocre.

Be the best darn USAF cargo pilot there is!

Yeah, it is great to aim at the top but at some point you have to be happy with what you have achieved instead of constantly feeling bad for not achieving more. Getting to the level where you can be considered a mediocre programmer is a huge achievement and hundreds of millions of people in the world would love to be in your shoes.

comparison is the thief of joy.

I'm a mediocre programmer, able to create interesting stuff, and have built tangible value in companies I've worked for, but mid pack in terms of programming chops. The problem is getting work, and hovering over destitution gets incredibly old.

> The Mediocre Programmer is a book about the journey of becoming a better programmer. But before we can become better programmers we have to pass through being mediocre programmers. Mediocre doesn't mean a bad programmer --- far from it. It means lacking skill

Great idea.. We're all mediocre programmers at some aspect of development even after spending a decade in the industry. And conversely many still suffer imposter's syndrome. Seems like a great topic to address.

Mediocre programmer + Domain Expert >> Expert programmer + Mediocre domain knowledge

I'm not sure if the book discusses it, but I think the top number differentiation between being a mediocre to an expert programmer is actually being an expert in the problem domain and less in computer/programming specific.

> Rather, we'll discuss what it feels like to be a programmer. We'll talk about the emotions in being a programmer; the feelings of frustration, guilt, anger, and inadequacy. We'll cover the struggles in learning new things and keeping your skills current.

This is a refreshing change from the productivity-focus that seems prevalent here. Thank you.

A book about minimalism boils down to "It's ok to say no". But that doesn't mean it's wasted breath to talk through it. Sometimes simple, valuable lessons take time to digest.

Likewise; This book may have a simple lesson at its core, but such a valuable lesson is worth unpacking. It's worth taking some time to relax and digest it.

I'm looking forward to reading this. :)

The mediocre caveman:

I have everything I need. I do not need to learn about nature. Caves are very comfortable.

Raw meat is tasty, chewing it with my 3 remaining teeth is great.

I do not need innovation. I can happily live to my 30s... if I am lucky, and do not get killed by a wild animal or a member of my tribe. By the way, what is a justice system? sounds very complex, I do not care about it. I will fix all my grievances through violence.

Oh, by the way, some guys showed up mounting horses and using metal weapons and enslaved us. Perhaps I should have spent more time trying to innovate.

This is exactly what the mediocre programmers and mediocre organizations sound like. People about to get rekt by people that develop an understanding of their world and their craft and innovate.

As long as there aren't enough great programmers in the world to satisfy all programming needs we will need mediocre programmers to cover for them. Programming isn't a competition and hence it doesn't matter if others are much better, all that matters is that there is a need for what you can provide.

If you train a developer, educate them about good practices, reward responsible behavior and engineering rigor, and amplify their impact giving them good infrastructure and tools, it is hard for that engineer to stay mediocre.

If you show developers thay you do not care about how they do things, they will become mediocre. Unless they are ethical and do it anyways.

I don't think it's so much about being a "programmer" as a just a better person.

In my experience the worst programmers usually have some bad personality traits, either lazy, unqualified or whatever else or sarcastic, rude, arrogant and runs across the spectrum of bad to good in terms of ability.

I think one of the keys to being a better programmer/person is having a good ability for self reflection and self awareness. Unfortunately these skills are developed at a very young age and in many cases it is too late to cultivate that mentality except some rare cases.

> Instead of trying to avoid it or wishing for comfort, we can instead relish that we're in uncertain territory and feel those brief twinges of fear and doubt.[1]

Generally true, but it also sounds like you’ve not made big mistakes.

Big mistakes often involve slight twinges of fear and doubt also.

[1]- http://themediocreprogrammer.com/build/html/the_mediocre_pro...

The funny thing is that another definition of mediocre is 'low quality'. And it seems plausible to me that even expert programmers can write low quality programs.

Expert programmers should write 'low quality' programs if that's what the situation calls for. Most of us are solving business problems, and lateral thinking can be worth more than perfect engineering or fancy algorithms.

There should be a fourth fear in the "Giving Up" section: giving up a decent to great salary when being mediocre cuts it just fine in a lot of positions.

Aren't most people mediocre? Its only a handful of achievers that are the best. And that doesn't usually mean its desirable.

Intellectual ability is more or less normally distributed, but even asking this question about programming is a pretty good signal you're nowhere near the mean of said distribution. I don't know, or really care for that matter, whether or not ability among the subset of the population that chooses to learn to write software is also normally distributed, but even if it is the mediocrities are still exceptional compared to the general public.

Quick review: Hope this guy doesn't code like he writes.

Needs an index.

http://themediocreprogrammer.com/build/html/the_mediocre_pro...

Thanks! The PDF didn’t have one.

Reply on news.ycombinator.com