This post resonates a lot with me, but being a good "code writer" is just a small part of being a programmer. I couldn't (and still can't) recall the simplest algorithms without opening a book, but that wouldn't stop me from solving problems because that is the real gist: identifying a problem and the right path to the information you need to solve it. Also being a sort of jack of all trades helps a lot more than excelling in just one task, or at least it worked a lot with me. I was probably a sub par mere "code writer", but I knew how to read a data sheet and use a solder iron, I had basic networking knowledge and a history of writing database software, although not SQL, and knew how to talk with people. I was average at best at any of those skills, but having many of them helped me to become a valuable asset in every company I worked at, because I knew how things were progressing in various groups so that colleagues with a technical problem could ask me who or where to head to find information, help, solutions etc. In the end I had many pay raises, but never left the technical side to become a PM or get a different job because I always wanted to remain a tech guy. So, the author is definitely not stupid; he probably has some other skills he didn't identify yet.
One thing I noticed anecdotally is that coding aesthetics and style matters much more for stupider people and smarter people actually have a correlation with writing sloppy code.
I think the reason comes from something similar to the article. Smarter people don't "need" perfectly pristine aesthetic code because they have the brain power to easily read messier code. It's not universal. Some smart people are obsessed with neatness but because neatness just isn't required you see this correlation with sloppier code and smarter people.
I have found that it is nearly universal that stupider people need to obsess over neat code because they literally have to have it or things get too hard for them.
Also yes, it's not universal but I have also noticed less smart programmers tend to like golang. There is definitely a correlation.
I know this can come off as a bit offensive for people who like golang or really obsess over neat code. I just want to say my statements are general, anecdotal and I have definitely seen examples to the contrary so I may not be referring to you personally! I'm referring to a general tendency I see.
There are smart programmers and dumb programmers, clean programmers and messy programmers. From your perspective, it looks like there is an inverse correlation but that is only because of Berkson's paradox.
The programmers who are both smart and clean don't hang out with you. They have more interesting projects to work on, or higher-paid jobs at other companies/industries. At the same time, you don't hang out with programmers who are both stupid and messy. They don't get hired at the same companies you work for, they don't have the skills needed to work on the same projects you work on, their articles don't get to the front page of Hacker News and so on.
>The programmers who are both smart and clean don't hang out with you.
Not true. I've literally stated in my post I've seen them. Your statement is illogically contradictory to my statement.
>From your perspective, it looks like there is an inverse correlation but that is only because of Berkson's paradox.
Possible. But I'm not sure how you can state this as fact without knowing where I've worked or having data to back it up. Everyone is going off subjective opinions here and no one can be sure who is definitively right or wrong. I feel you're the one who's biased here. Unless you have something more then anecdotal data to back that statement up I feel it's just your own two cents against mine. Which is fine, anecdotally both are valid.
>They don't get hired at the same companies you work for, they don't have the skills needed to work on the same projects you work on, their articles don't get to the front page of Hacker News and so on.
Right. So what companies have I worked for? You can make this statement because you know? Anecdotal evidence or not, you literally have no basis here.
For me it's a bit of both: experimental code or one-off scripts can be a total mess while at the same time I care a lot about readability in other projects. For one it's still helpful when I'm tired, but also while I may be able to read my own sloppy code a few days after writing it that won't be true forever. Another reason is that I have trouble with very abstract code/concepts, the more I can reason about what's actually happening with data and memory the easier and quicker I understand the code. That's why I'm terrible with Haskell etc, it requires a kind of thinking that feels like a mental foreign language.
I'd probably fall more in the spectrum of dumb programmer vs smart one, but I like clean code/consistently enforced patterns because it reduces the amount of mental overhead required to get code state into your brain. I'd rather focus on actually solving the problem at hand vs wrangling with messy, overly clever code.
That's one of the reason I like Go so much. The language is simple and easy to read with common, idiomatic patterns to the point it just gets out of your way and you can actually focus on what you're trying to do instead of spinning your wheels with a million clever ways to write the same code.
Its easier for new team members to understand consistently formatted code. Just one less thing to get in the way. Some people are too stupid to use an autoformatter though :P.
there's nothing like that in the article, he's just outlining the things he does to compensate for his perceived low intelligence. you clearly came in here with an axe to grind based on your other replies but this blog post is not the reason your feelings are hurt.
I think he's being self aware and honest. I seem mean here but I'm more just trying to be honest.
The telling metric is his leet code performance. I'm positive he can be a good programmer in what he does but there are definitely smarter programmers then him in the world.
Faang companies will filter for this and despite that I still think he may be able to train himself to do better on leetcode. But performance on leetcode does correlate with IQ and general intelligence. You would be dishonest with yourself if you can't accept that.
I thought it was a superb and very important essay. I really liked it and I have shared it widely.
I find it very sad that so many people, including the majority of the comments here, did not understand what you were saying, and either totally misinterpret the whole thing, or pick on minor unimportant details and misunderstand them.
> I haven't been diagnosed with any specific medical condition, but my mental capacity is very limited. … So what do I do about it? I use the simplest mainstream language available (Go) and very basic Python.
> This post feels especially jaded and anti-intellectual. Writing simple code isn’t stupid, why be so harsh on yourself?
The reason I think self-critique takes a rather extreme turn is because of anxiety. If we analyse the root cause, there may be more than _just_ anxiety at play but I do feel it plays a significant role(IANAD though; just an observer).
Every programmer first and foremost are humans. And as humans, we are bounded by the highs and lows of the software we develop. Some of the low self-esteem can come because _life_; some might be because they hold their bar too high to achieve dramatically; some because, they might think of engineering software as an easy-peasy task but find that it can _sometime_ come with unseen/unheard baggages; all or partial part of the aforementioned causes could lead further to be in said state of mind.
To some extent, we(as in software people) need to be brave, hold our self beliefs/values, try to elevate our self-esteem and recommend our friends/family/colleagues to do the same. It's this collective esteem that will carry us together in this journey. It's not easy to overcome fear, anxiety, depression or any other state of mind(IANAD though; just an observer). I am cognisant of the fact that it is definitely easier said than done but do note that humans are capable of achieving marvelous things both intellectually and viscerally.
Perhaps, try to be social, go out and about, have hobbies, meditation, hiking, exercise - just to name a few that helped others I have met.
Last but not the least, I cannot let myself buy the argument that someone thinks of themselves as dumb.
It's extremely more likely that one has not had the opportunity to have the __foundational__ understanding and the shift required to think laterally in those terms. To acquire those, perhaps try to read more books and experiment more. These are more valuable use of time IMHO than to be harsh on oneself. But, to re-iterate, we are all humans at the end of the day.
I even more stupid than Anton, I use C instead of Go and Perl instead of Python. I do not use Docker. I distrubute my code with Makefiles. I do not use CMake.
Well, I tried to learn some Python, but I failed. As for Go, perhaps you are right. A good friend of mine, some elder hacker, switched to Go and suggests it to me, but I just have no time for learning one more language to get same job done. I think I'm getting old and concervative. I feel my brain is no longer as sharp and productive as it used to be some 20 or 30 years ago. It takes me much more time to comprehend new ideas and practices. Also, when I code in C, I experience warm nostalgic feeling of my youth, I feel invisible strings of ties with all those great minds like Ritchie, Thompson and Kernigan. ;)
I've noticed quite often very competent junior devs are very often guilty of writing far to complex code. I think there's often a disconnect between the ideal of what software should be and what best solves the problem.
Since taking the mindset of been required to solve a problem as opposed to trying to write the 'best' and 'cleanest' software I've found my productivity jump substantially while ending up with easier to maintain code.
One of the most frustrating things I’ve dealt with is a junior developer (who, based on years in the industry, thought they were a senior) who would write clever/complex code just for the sake of it. That and touching 10+ things in their commits that were outside the scope of the ticket (“cleaning up other code”).
I’ll fully admit I used to be that person but some people never seem to grow out of it. They see what they perceive as “gross” code, repetitive code, or verbose code and make it their mission to DRY it out or rewrite it in a shorter, more clever way. Cleverness in code should be avoided at almost all costs, code golfing might be a fun exercise but has no business in real codebases, and trying to abstract and centralize logic with only 1-2 implementations is foolhardy at best.
I’ll take verbose, understandable code every day over code that I have to stop and think about for any amount of time.
Junior dev here, I’ll bite. I’m not sure of the specifics but I sincerely hope we don’t work together and you actually raised this with them as this fills me with zero confidence in my work, we all have different views on what’s “going too far” regardless of level and as others have said it’s rather difficult to know without being told.
Yes, if it’s in my logic path, I will replace an old regex in favour for a newer in-built function that is much easier to read and I’m certain does the same thing, rename a constant which make zero sense or split the same damn check repeated 10x times into it’s own better named constant or helper function - as long as it doesn’t touch the business logic, who cares! But, I do think it’s important to check the temp with your lead and clear this is an acceptable thing to “tidy up” behind you.
> That and touching 10+ things in their commits that were outside the scope of the ticket (“cleaning up other code”).
The smartest thing I do every day when I touch old code is turn off auto-formatting in my editor, studiously avoid doing minor clean-ups ("why the FUCK is this line 300 characters long"), and touch only what I'm working on.
Instead, I'll make a note to come back and clean up the other stuff later, if I have time, in a whole separate branch/commit/ticket. And then that note probably gets deleted, because this code is 8 years old, and is slated to be rewritten, almost certainly before I would get around to doing the minor chore clean-up.
It's not like the kitchen - there's no reason to quickly wipe up the stove during the 2 minutes that the microwave is doing its thing. It won't rot and stink up the place any more than it is now.
Maybe you were already saying this, but learning how to write just enough of the least complex code is a skill acquired through experience, which naturally junior developers don’t yet have. It’s the pain of maintaining over engineering and needlessly complex code and attacking tech debt that develops the skills to avoid such things in the future. No better teacher for those things :)
I’m going through a Software Engineering textbook right now. A real one used to teach. And I can’t see anything in here as legitimate. It’s the most irrelevant pile of nonsense about bug metrics and project diagramming you could think of. The author isn’t even taking it seriously. It’s like computer psychology: unreplicable ivory tower memorabilia. Not knowing stuff like that is a steering function to me.
When code is as concise as possible, everything still there is there for a clear reason. Repetitive, verbose code is where our ape brains get bored or confused and miss bugs.
I think the reason comes from something similar to the article. Smarter people don't "need" perfectly pristine aesthetic code because they have the brain power to easily read messier code. It's not universal. Some smart people are obsessed with neatness but because neatness just isn't required you see this correlation with sloppier code and smarter people.
I have found that it is nearly universal that stupider people need to obsess over neat code because they literally have to have it or things get too hard for them.
Also yes, it's not universal but I have also noticed less smart programmers tend to like golang. There is definitely a correlation.
I know this can come off as a bit offensive for people who like golang or really obsess over neat code. I just want to say my statements are general, anecdotal and I have definitely seen examples to the contrary so I may not be referring to you personally! I'm referring to a general tendency I see.
The programmers who are both smart and clean don't hang out with you. They have more interesting projects to work on, or higher-paid jobs at other companies/industries. At the same time, you don't hang out with programmers who are both stupid and messy. They don't get hired at the same companies you work for, they don't have the skills needed to work on the same projects you work on, their articles don't get to the front page of Hacker News and so on.
Not true. I've literally stated in my post I've seen them. Your statement is illogically contradictory to my statement.
>From your perspective, it looks like there is an inverse correlation but that is only because of Berkson's paradox.
Possible. But I'm not sure how you can state this as fact without knowing where I've worked or having data to back it up. Everyone is going off subjective opinions here and no one can be sure who is definitively right or wrong. I feel you're the one who's biased here. Unless you have something more then anecdotal data to back that statement up I feel it's just your own two cents against mine. Which is fine, anecdotally both are valid.
>They don't get hired at the same companies you work for, they don't have the skills needed to work on the same projects you work on, their articles don't get to the front page of Hacker News and so on.
Right. So what companies have I worked for? You can make this statement because you know? Anecdotal evidence or not, you literally have no basis here.
That's one of the reason I like Go so much. The language is simple and easy to read with common, idiomatic patterns to the point it just gets out of your way and you can actually focus on what you're trying to do instead of spinning your wheels with a million clever ways to write the same code.
I mean literally it's just one command. I'm referring to style and neatness beyond the linter.
“Programming isn’t hard”
“Anyone can learn to code”
“Programming is modern day plumbing”
“I’m really stupid and a professional programmer, it must be a dumb profession”
This post feels especially jaded and anti-intellectual. Writing simple code isn’t stupid, why be so harsh on yourself?
Your comment: “No you’re wrong because I don’t like your tone”
Next time you comment, can you say something intelligent or at least relevant to the discussion?
Deleted Comment
The telling metric is his leet code performance. I'm positive he can be a good programmer in what he does but there are definitely smarter programmers then him in the world.
Faang companies will filter for this and despite that I still think he may be able to train himself to do better on leetcode. But performance on leetcode does correlate with IQ and general intelligence. You would be dishonest with yourself if you can't accept that.
Links? Kind of sounds like something you just have a gut feeling on.
I find it very sad that so many people, including the majority of the comments here, did not understand what you were saying, and either totally misinterpret the whole thing, or pick on minor unimportant details and misunderstand them.
Thank you for writing it.
> I haven't been diagnosed with any specific medical condition, but my mental capacity is very limited. … So what do I do about it? I use the simplest mainstream language available (Go) and very basic Python.
The reason I think self-critique takes a rather extreme turn is because of anxiety. If we analyse the root cause, there may be more than _just_ anxiety at play but I do feel it plays a significant role(IANAD though; just an observer).
Every programmer first and foremost are humans. And as humans, we are bounded by the highs and lows of the software we develop. Some of the low self-esteem can come because _life_; some might be because they hold their bar too high to achieve dramatically; some because, they might think of engineering software as an easy-peasy task but find that it can _sometime_ come with unseen/unheard baggages; all or partial part of the aforementioned causes could lead further to be in said state of mind.
To some extent, we(as in software people) need to be brave, hold our self beliefs/values, try to elevate our self-esteem and recommend our friends/family/colleagues to do the same. It's this collective esteem that will carry us together in this journey. It's not easy to overcome fear, anxiety, depression or any other state of mind(IANAD though; just an observer). I am cognisant of the fact that it is definitely easier said than done but do note that humans are capable of achieving marvelous things both intellectually and viscerally.
Perhaps, try to be social, go out and about, have hobbies, meditation, hiking, exercise - just to name a few that helped others I have met.
Last but not the least, I cannot let myself buy the argument that someone thinks of themselves as dumb. It's extremely more likely that one has not had the opportunity to have the __foundational__ understanding and the shift required to think laterally in those terms. To acquire those, perhaps try to read more books and experiment more. These are more valuable use of time IMHO than to be harsh on oneself. But, to re-iterate, we are all humans at the end of the day.
https://bluehackers.org/
Dead Comment
But I suppose fish don't find it hard to breathe in water, either.
Since taking the mindset of been required to solve a problem as opposed to trying to write the 'best' and 'cleanest' software I've found my productivity jump substantially while ending up with easier to maintain code.
I’ll fully admit I used to be that person but some people never seem to grow out of it. They see what they perceive as “gross” code, repetitive code, or verbose code and make it their mission to DRY it out or rewrite it in a shorter, more clever way. Cleverness in code should be avoided at almost all costs, code golfing might be a fun exercise but has no business in real codebases, and trying to abstract and centralize logic with only 1-2 implementations is foolhardy at best.
I’ll take verbose, understandable code every day over code that I have to stop and think about for any amount of time.
Yes, if it’s in my logic path, I will replace an old regex in favour for a newer in-built function that is much easier to read and I’m certain does the same thing, rename a constant which make zero sense or split the same damn check repeated 10x times into it’s own better named constant or helper function - as long as it doesn’t touch the business logic, who cares! But, I do think it’s important to check the temp with your lead and clear this is an acceptable thing to “tidy up” behind you.
The smartest thing I do every day when I touch old code is turn off auto-formatting in my editor, studiously avoid doing minor clean-ups ("why the FUCK is this line 300 characters long"), and touch only what I'm working on.
Instead, I'll make a note to come back and clean up the other stuff later, if I have time, in a whole separate branch/commit/ticket. And then that note probably gets deleted, because this code is 8 years old, and is slated to be rewritten, almost certainly before I would get around to doing the minor chore clean-up.
It's not like the kitchen - there's no reason to quickly wipe up the stove during the 2 minutes that the microwave is doing its thing. It won't rot and stink up the place any more than it is now.
…
> I think there's often a disconnect
Maybe you were already saying this, but learning how to write just enough of the least complex code is a skill acquired through experience, which naturally junior developers don’t yet have. It’s the pain of maintaining over engineering and needlessly complex code and attacking tech debt that develops the skills to avoid such things in the future. No better teacher for those things :)
Does “here” refer to the book or the blog post?
Simplicity above all.