I'm a Programmer and I'm Stupid(antonz.org)
antonz.org
I'm a Programmer and I'm Stupid
https://antonz.org/stupid/
79 comments
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.
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. 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.
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.
> 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.
Because you haven't met them. Where you've worked is irrelevant. Either a) they exist, and you've not met them because you work somewhere that excluded them, or b) all of the places you've worked hired equally from the pool of all programmers, and didn't happen to find any. without knowing where you've worked, I can state for a fact that where you've worked had hiring standards, explicit or implicit, affected by internal and external factors. Thus, B is less likely than A, despite having no data on where you've worked. It's not possible you've worked at every company in every subfield there is to our industry, and thus you've not encountered every type of programmer there is. Programmers for ransomware groups are gonna be a much different group of individuals than from those programming VR goggle firmware, are different from PhD candidates writing code to never get reused, to programmers for HFT desks, for instance.
There are 4 quadrants:
Because you haven't met them. Where you've worked is irrelevant. Either a) they exist, and you've not met them because you work somewhere that excluded them, or b) all of the places you've worked hired equally from the pool of all programmers, and didn't happen to find any. without knowing where you've worked, I can state for a fact that where you've worked had hiring standards, explicit or implicit, affected by internal and external factors. Thus, B is less likely than A, despite having no data on where you've worked. It's not possible you've worked at every company in every subfield there is to our industry, and thus you've not encountered every type of programmer there is. Programmers for ransomware groups are gonna be a much different group of individuals than from those programming VR goggle firmware, are different from PhD candidates writing code to never get reused, to programmers for HFT desks, for instance.
There are 4 quadrants:
. dumb | smart
messy __1___|___2___
clean 3 | 4
But as my sample size grows as I work for more companies by probability the data becomes more and more inline with the actual population.
Who's to say my sample isn't a good representation of the actual population?
Edit: in response to your edit of quadrants. I never said they don't exist. I stated that there are correlations. And I explicitly stated that despite the correlations I've seen examples of all types of programmers. Even programmers outside of the correlations.
Of course as stated before, these correlations are anecdotal. Just my experience. I don't think it's necessarily invalid despite that.
Who's to say my sample isn't a good representation of the actual population?
Edit: in response to your edit of quadrants. I never said they don't exist. I stated that there are correlations. And I explicitly stated that despite the correlations I've seen examples of all types of programmers. Even programmers outside of the correlations.
Of course as stated before, these correlations are anecdotal. Just my experience. I don't think it's necessarily invalid despite that.
> I stated that there are correlations
The funny part, the reason it's called a paradox, is that the correlation can be fake or can even be reversed. We cannot know either way just from our personal experiences, the selection effects are too strong.
And the anecdote you tell, the part about smart programmers being smart enough to get away with being a little messy, and dumb programmers being obsessed with cleanliness to reduce cognitive load, are exactly the sorts of situations that can cause the paradox.
It's like when you are casually dating a bunch of people and find that the good-looking ones tend to have bad personalities because they are attractive enough that they can get away with it. It is a real correlation from your perspective, but on a global scale the correlation is opposite. Good looking people tend to be more charismatic in real life, we just can't tell while we are on the dating market because the ones who are both good looking and charismatic are out of our league, and as for the ugly/mean ones, we are out of their league.
The funny part, the reason it's called a paradox, is that the correlation can be fake or can even be reversed. We cannot know either way just from our personal experiences, the selection effects are too strong.
And the anecdote you tell, the part about smart programmers being smart enough to get away with being a little messy, and dumb programmers being obsessed with cleanliness to reduce cognitive load, are exactly the sorts of situations that can cause the paradox.
It's like when you are casually dating a bunch of people and find that the good-looking ones tend to have bad personalities because they are attractive enough that they can get away with it. It is a real correlation from your perspective, but on a global scale the correlation is opposite. Good looking people tend to be more charismatic in real life, we just can't tell while we are on the dating market because the ones who are both good looking and charismatic are out of our league, and as for the ugly/mean ones, we are out of their league.
True. But how do you know the paradox applies here? What if my sample is accurate?
What I don't get is how someone can out of nowhere say the paradox applies in my case. I mean this paradox can apply to any measurement even the most rigorous experiment. So why suddenly come to my post and bring up this application?
What I don't get is how someone can out of nowhere say the paradox applies in my case. I mean this paradox can apply to any measurement even the most rigorous experiment. So why suddenly come to my post and bring up this application?
Simply on the basis that sampling bias exists, I'll say your sample isn't a good representation of the actual population. Presuming you're human and haven't lived multiple lives simultaneously, it's just not possible you've worked in every subfield of our industry, meeting every possible variation of programmer. You didn't get your current job from first principles. There's bias, just from job-1 on how you got your current job, nevermind your entire whole background as a human being. A coder in India lives in a wholly different culture than someone in Eastern Europe is different from a North Korean is different than a San Francisican programmer, never mind the actual work they're doing; firmware, web crud, kernel, LLM. Different types are going to be more prevalent in different areas, and unless you've got a truly random sampling of workplaces, there's gonna be some bias in action.
>Simply on the basis that sampling bias exists, I'll say your sample isn't a good representation of the actual population.
I would say it's possible. But also every person I've ever met for the most part has 2 eyes. Despite sampling bias my measurement is pretty accurate to the population that most humans have two eyes.
So just because bias exists doesn't render a measurement inaccurate. It could still be accurate.
In fact I doubt even the most rigorous science can be completely unbiased. You can't say just because bias exists the measurement is inaccurate.
It could be accurate. A measurement existing opens the possibility up for the measurement to be accurate and true to the real world scenario.
I would say it's possible. But also every person I've ever met for the most part has 2 eyes. Despite sampling bias my measurement is pretty accurate to the population that most humans have two eyes.
So just because bias exists doesn't render a measurement inaccurate. It could still be accurate.
In fact I doubt even the most rigorous science can be completely unbiased. You can't say just because bias exists the measurement is inaccurate.
It could be accurate. A measurement existing opens the possibility up for the measurement to be accurate and true to the real world scenario.
For something as basic as number of eyes, you make a valid point, but what's more likely? That your career choices have been free from any bias which makes your sample accurate, or that there's many, many biases, from the culture of where you born to the programming language you first learned, to how rich your parent were, that have lead you to have the career that you have, resulting in a skewed sample?
I think what you say is valid. But I also believe that there is a realistic chance that my sample is accurate despite the biases.
It also makes sense logically. A smarter person will be faster at reading sloppy code.
It also makes sense logically. A smarter person will be faster at reading sloppy code.
as a sloppy coder (until I clean it up for review) I appreciate the compliment!
I didn't intend to make a statistically rigorous statement or anything, I just thought your anecdote was a funny application of Berkson's paradox.
The fun part is that I don't need to know how smart or clean you are, or how cool the companies you work for are. As long as you subjectively perceive people to be cleaner/messier than you, or smarter/dumber than you, Berkson's paradox will still hold no matter what your objective, absolute levels of those traits are.
For example, it's perfectly possible that the programmers you consider to be dumb but clean or smart but messy are still both smarter and cleaner than me. Berkson's paradox applies to me too, after all, and we don't hang out together.
The fun part is that I don't need to know how smart or clean you are, or how cool the companies you work for are. As long as you subjectively perceive people to be cleaner/messier than you, or smarter/dumber than you, Berkson's paradox will still hold no matter what your objective, absolute levels of those traits are.
For example, it's perfectly possible that the programmers you consider to be dumb but clean or smart but messy are still both smarter and cleaner than me. Berkson's paradox applies to me too, after all, and we don't hang out together.
What if the sample of the people I hang out with are a completely accurate representation of the entire domain? Would the paradox still apply?
When it comes to smart/clean, maybe you can hang out with enough people to get an accurate sample.
But then you would find other paradoxes, like maybe you'd find that the smart/clean programmers you meet have a worse personality or are less athletic than the dumb/messy ones.
The only way for it to not apply at all, for every possible trait, is if you hang out with the entire planet at the same time.
But then you would find other paradoxes, like maybe you'd find that the smart/clean programmers you meet have a worse personality or are less athletic than the dumb/messy ones.
The only way for it to not apply at all, for every possible trait, is if you hang out with the entire planet at the same time.
Wouldn't personality and athleticism be off topic though?
I'm only referring to two traits here: intelligence and code sloppiness.
Does this paradox still apply in this case? Or is this paradox some kind of broad thing not relegated to a specific correlation?
I'm only referring to two traits here: intelligence and code sloppiness.
Does this paradox still apply in this case? Or is this paradox some kind of broad thing not relegated to a specific correlation?
They're off topic, but the point is you'll find correlation where you want to.
Possible. But also possible that no bias influenced my observation.
And who's to say that the correlation I happen to want isn't real?
And who's to say that the correlation I happen to want isn't real?
I am. I mean, it could be you're right. everyone's entitled to their own opinions though. some people think the moon is made of cheese, for example. but the reality is the inherent bias in your sample set is too large to be ignored.
My claim from a common sense perspective isn't outlandish as saying the moon is made of cheese.
Biased samples don't automatically invalidate every aspect of the sample as a description of the reality. The possibility remains that every most programmers have two eyes just as smarter programmers tend to write sloppier code.
Look the general thing here is that anecdotal information is not automatically invalid. Your type of argument just goes around dismissing all forms of anecdotal data as if it's completely false. It's like you cannot even get up from bed and put your feet on the floor because there's no science saying that the floor exists.
Biased samples don't automatically invalidate every aspect of the sample as a description of the reality. The possibility remains that every most programmers have two eyes just as smarter programmers tend to write sloppier code.
Look the general thing here is that anecdotal information is not automatically invalid. Your type of argument just goes around dismissing all forms of anecdotal data as if it's completely false. It's like you cannot even get up from bed and put your feet on the floor because there's no science saying that the floor exists.
The plural of anecdote is not data! Looking around at the people surrounding you, you could also easily conclude that everyone has the same skin tone. If you've only ever lived in, say, Scotland, you could erroneously conclude that, on top of everyone having two eyes, every one is also white. It's not until you look past the fact that you're in Scotland biases your dataset to being exclusively white people,
that you see there are other kinds of people out there.
Living in Scotland and sampling your data there, concludes that all humans are white, along with having two eyes.
Living in Scotland and sampling your data there, concludes that all humans are white, along with having two eyes.
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.
Makes sense.
I think some people enjoy the aesthetics of good code, much like math. That’s a smart person thing
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.
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.
Nobody is too stupid to use an auto formatter. I'm not even talking about that. CI can automate on commit or enforce it.
I mean literally it's just one command. I'm referring to style and neatness beyond the linter.
I mean literally it's just one command. I'm referring to style and neatness beyond the linter.
I have no idea what you're talking about I'm sorry. If you're talking about style and neatness in the same sense as style and neatness in literature it's just as important in code. If not then style and neatness is just an aspect of good grammar and simple hygiene, should be mostly done on autopilot. Maybe you have some other experience of pointless pedantry but I don't know what it is.
>I have no idea what you're talking about I'm sorry.
It's ok no need to apologize here. You've done nothing wrong.
Style and neatness extends beyond linters. For example naming. I can choose bad names. The linter won't catch it. I can choose inconsistent names and the linter won't catch it.
Also style can refer to programming style. One programmer may prefer recursion the other for loops. Another programmer may prefer dependency injection while a golang programmer is more against that style.
None of these things are pedantic imo.
I would also kindly request that you don't say stuff like this: "Maybe you have some other experience of pointless pedantry but I don't know what it is.". It comes off as bit rude to me. Though I assume that was not your intention it did come off that way and I would just like this conversation to continue amicably.
It's ok no need to apologize here. You've done nothing wrong.
Style and neatness extends beyond linters. For example naming. I can choose bad names. The linter won't catch it. I can choose inconsistent names and the linter won't catch it.
Also style can refer to programming style. One programmer may prefer recursion the other for loops. Another programmer may prefer dependency injection while a golang programmer is more against that style.
None of these things are pedantic imo.
I would also kindly request that you don't say stuff like this: "Maybe you have some other experience of pointless pedantry but I don't know what it is.". It comes off as bit rude to me. Though I assume that was not your intention it did come off that way and I would just like this conversation to continue amicably.
Programming is the only profession I know of where people do these ritual put downs of themselves and their work.
“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?
“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?
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.
My comment(s): “I don’t like this here is why”
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?
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]
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.
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.
> leetcode correlate with IQ and general intelligence
Links? Kind of sounds like something you just have a gut feeling on.
Links? Kind of sounds like something you just have a gut feeling on.
Supposedly IQ test have a slight positive correlation with workplace performance. I could see leetcode skills(or, put more broadly, algorithms knowledge) having a slight positive correlation with job performance, but as everyone knows it doesn't guarantee someone is a good or productive developer.
The flaw with the metaphor is that you can study for leetcode, whereas supposedly(can't find a good source on this) you can't really study for an IQ test. I had a weak comp sci background when I started doing leetcode interviews and would struggle with questions. I spent several months studying CLRS, cracking the coding interview, etc., and now I would say I am fine at most problems up to medium complexity.
The flaw with the metaphor is that you can study for leetcode, whereas supposedly(can't find a good source on this) you can't really study for an IQ test. I had a weak comp sci background when I started doing leetcode interviews and would struggle with questions. I spent several months studying CLRS, cracking the coding interview, etc., and now I would say I am fine at most problems up to medium complexity.
Studying leetcode and IQ both correlate with better performance in leetcode.
There's no raw data to back either statement up, but both are very likely to be true via common sense.
There's no raw data to back either statement up, but both are very likely to be true via common sense.
Yeah, apparently I have a very high IQ but I still suck at programming. I often wonder if they tested me wrong, but I was tested twice. IDK
Anyone else like this? Maybe I have a learning disability or something.
Anyone else like this? Maybe I have a learning disability or something.
I have an above-average IQ, but there are certain things that I find very hard that are easy for other people.
IQ isn't a universal "you're good at everything" score, even if it was an objectively good measure of intellience.
IQ isn't a universal "you're good at everything" score, even if it was an objectively good measure of intellience.
101 is above average 110 is where there should be notable advantage in more things as it's 1 std above the norm. The higher your IQ the more and more universal it tends to become.
So at say 150 you would notice that you would find most tasks easier then most people then say 110 where you would find less tasks more easier.
So at say 150 you would notice that you would find most tasks easier then most people then say 110 where you would find less tasks more easier.
I've heard of this. Dyslexia maybe?
It's a gut feeling but it's a very valid one. Its been measured and validated among so many metrics that it's pretty solid that performance any intellectual task will highly, highly be inline with IQ. In psychology it's one of the few quantitative metrics that so solidly predicts a lot of things.
What seems seems disingenuous to me is sometimes people can't hold and opinion without hard data. Do you really need raw data to know you shouldn't hire a person with an IQ of 45 to drive a bus?
No most people don't need data. I think what's going on here specifically is that a lot of people don't do well on leetcode and they know it and they don't like to think that it correlates with their general intelligence.
I'm truly sorry for making some people face that reality. I would say I'm not the best performer on leetcode myself. I can't deny that even without raw data it's pretty solid that IQ will correlate with leetcode performance. There are other correlative factors too like studying for leetcode specifically. And I don't need raw data to make either of those statements.
What seems seems disingenuous to me is sometimes people can't hold and opinion without hard data. Do you really need raw data to know you shouldn't hire a person with an IQ of 45 to drive a bus?
No most people don't need data. I think what's going on here specifically is that a lot of people don't do well on leetcode and they know it and they don't like to think that it correlates with their general intelligence.
I'm truly sorry for making some people face that reality. I would say I'm not the best performer on leetcode myself. I can't deny that even without raw data it's pretty solid that IQ will correlate with leetcode performance. There are other correlative factors too like studying for leetcode specifically. And I don't need raw data to make either of those statements.
Leetcode correlating with IQ tests makes sense they are very similar. Correlating either with general intelligence is less obvious.
I never said anything like that in the post. And I never said that writing simple code is stupid.
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.
Thank you for writing it.
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.
What am I supposed to take away from this then?
> 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.
> 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.
I think and I don't speak for him, but he's saying he writes simple code because he's stupid, which is different from saying simple code is stupid, because smart people can also choose to write simple code.
Op may be too harsh on himself but it's an open possibility that he may also be honest and accurate in his own self assessment.
Op may be too harsh on himself but it's an open possibility that he may also be honest and accurate in his own self assessment.
If that’s what he is saying this is probably the worst possible way he could have done it
Definitely not "simple code is stupid".
Ok well you should work on your writing then because it sucks and doesn’t communicate your points well.
If I said “The sky is blue today. So, I went outside.” You would probably be surprised to learn that I hate clear weather and prefer the rain. Because, that would violate the most implicit, obvious assumption in my statement…
Likewise you saying “I’m mentally deficient. So I have to use Go” makes it seem pretty fucking obvious to me what you think about Go programmers and programming in general
If I said “The sky is blue today. So, I went outside.” You would probably be surprised to learn that I hate clear weather and prefer the rain. Because, that would violate the most implicit, obvious assumption in my statement…
Likewise you saying “I’m mentally deficient. So I have to use Go” makes it seem pretty fucking obvious to me what you think about Go programmers and programming in general
It's good to know I'm not the only one who has trouble with basic logical reasoning!
Shit, maybe I should have taken your post literally, you do seem like an idiot.
You've totally failed to understand what the essay is about, and you are angrily trying to argue your incorrect understanding with the author when it is not what he said.
> 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.
https://bluehackers.org/
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/
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.
I must be even stupider than you, because C and Perl and Make seem vastly more complicated to me than Python & Docker.
But I suppose fish don't find it hard to breathe in water, either.
But I suppose fish don't find it hard to breathe in water, either.
You are literally living the dream!
Oh come on. C is harder than go and perl harder than python.
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. ;)
> Well, I tried to learn some Python, but I failed.
Brother, unless you tried to start with class metaprogramming or something, there's no way someone proficient with C to have struggles with basic python.
Probably you didn't find a good resource. There are always resources like "X for Y programmer", this is what a quick Google search finds: https://engineering.purdue.edu/~milind/datascience/2018sprin...
Or you learned the basics, held yourself to high standards, and got bored by all the dynamism / OOP details of python. Then let me tell you - 70% of python programmer don't use anything beyond basic OOP.
Brother, unless you tried to start with class metaprogramming or something, there's no way someone proficient with C to have struggles with basic python.
Probably you didn't find a good resource. There are always resources like "X for Y programmer", this is what a quick Google search finds: https://engineering.purdue.edu/~milind/datascience/2018sprin...
Or you learned the basics, held yourself to high standards, and got bored by all the dynamism / OOP details of python. Then let me tell you - 70% of python programmer don't use anything beyond basic OOP.
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.
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.
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.
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.
> 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
I'm not sure why you hope we don't work together. I assure you I raised this point with this developer multiple times and it's not my goal to belittle or discourage junior developers. I actually really enjoy mentoring junior developers as long as they are willing to consider they may not know everything and have an ounce of humility towards the codebase they are walking into. Heck, when I come onto a team as a senior developer I work hard to not make changes even if I think I know better until I get a good feel for the code. Too often a junior comes in and wants to change everything to suit their style or their "I reckon"'s, that level of ego grates on my nerves (no matter what their skill level is). To think you can walk into an established codebase and start making changes without knowing why something was done a certain way is not ok. See also: Chesterton's fence [0].
I'll try to address your points one by one for what I think is the right path. My path is not necessarily right for everyone in every circumstance but it comes from writing code for over 20 years.
> 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
This is iffy for me. If the old regex is working then I'm not super interested in changing it just to change it. I want to preserve the git history, the commit message, and the linked ticket. Yes, you can step backwards to find this but it's much harder and rarely do I even step back further commits unless I really need the information. Enough times I've annotated a file to see " " => "\t" as the change and now I have to inspect that full diff and annotate the "before" version to see who wrote it and why originally. I understand wanting to change /myString$/ to .endWith('myString') (or similar) but unless you are already changing the logic in the regex I probably wouldn't touch it.
> rename a constant which make zero sense
This I understand and will occasionally do if the meaning has completely changed but changing something "deleted" to "isDeleted" or stylistic renamings are a no-no in my book. It's almost always better to leave a detailed comment on the definition of the constant to help people reading it in the future. Now if it's something like FEATURE_A_ENABLED but now that flag is being used for multiple things that don't really have anything to do with "feature A" then I understand.
> split the same damn check repeated 10x times into it’s own better named constant or helper function
Yes, abstracting out completely duplicated (no changes at all) code does make sense. The only pitfall here is if you have a "helper" function that has to take multiple arguments to handle special cases. The code should be identical, not "if you squint at it it looks similar". I've seen too many "abstractions" that are riddled with if/else if/else if/else if/else to handle the different things the calling code needs. At that point the minor duplication is much prefered. Similarly if I see a function that changes its return type based on a parameter I want to pull my hair out. Junior developer, myself included, fall prey to making things super DRY which actually can make the code more confusing and difficult to follow/reason about.
> as long as it doesn’t touch the business logic, who cares!
Here's the thing about that, even I still make mistakes (and will until I retire) when it comes to "this code is functionally the same". "doesn't touch the business logic" is a much harder thing to be sure of than one might think and unless you are intimately familiar with all the code calling through what you are changing can you really be sure? Literally just last week I made a mistake that got through multiple code reviews as "yep, that's functionally identical" but we missed a weird case further down that none of us had expected from reading the code. Also, see again: git history. I didn't always care as much about git history but I had a boss that instilled into me its value and now I fight to preserve it as it can be incredibly helpful in debugging or attempting to make a change to code (again, Chesterton's fence).
None of this is meant to be come across as attacking you are me telling you that I think you are wrong. Just how I see things, take from it what you will, ignore what you will. My way is not the perfect way, just the way I've learned over many years doing this professionally.
[0] https://en.wikipedia.org/wiki/G._K._Chesterton#Chesterton's_...
I'm not sure why you hope we don't work together. I assure you I raised this point with this developer multiple times and it's not my goal to belittle or discourage junior developers. I actually really enjoy mentoring junior developers as long as they are willing to consider they may not know everything and have an ounce of humility towards the codebase they are walking into. Heck, when I come onto a team as a senior developer I work hard to not make changes even if I think I know better until I get a good feel for the code. Too often a junior comes in and wants to change everything to suit their style or their "I reckon"'s, that level of ego grates on my nerves (no matter what their skill level is). To think you can walk into an established codebase and start making changes without knowing why something was done a certain way is not ok. See also: Chesterton's fence [0].
I'll try to address your points one by one for what I think is the right path. My path is not necessarily right for everyone in every circumstance but it comes from writing code for over 20 years.
> 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
This is iffy for me. If the old regex is working then I'm not super interested in changing it just to change it. I want to preserve the git history, the commit message, and the linked ticket. Yes, you can step backwards to find this but it's much harder and rarely do I even step back further commits unless I really need the information. Enough times I've annotated a file to see " " => "\t" as the change and now I have to inspect that full diff and annotate the "before" version to see who wrote it and why originally. I understand wanting to change /myString$/ to .endWith('myString') (or similar) but unless you are already changing the logic in the regex I probably wouldn't touch it.
> rename a constant which make zero sense
This I understand and will occasionally do if the meaning has completely changed but changing something "deleted" to "isDeleted" or stylistic renamings are a no-no in my book. It's almost always better to leave a detailed comment on the definition of the constant to help people reading it in the future. Now if it's something like FEATURE_A_ENABLED but now that flag is being used for multiple things that don't really have anything to do with "feature A" then I understand.
> split the same damn check repeated 10x times into it’s own better named constant or helper function
Yes, abstracting out completely duplicated (no changes at all) code does make sense. The only pitfall here is if you have a "helper" function that has to take multiple arguments to handle special cases. The code should be identical, not "if you squint at it it looks similar". I've seen too many "abstractions" that are riddled with if/else if/else if/else if/else to handle the different things the calling code needs. At that point the minor duplication is much prefered. Similarly if I see a function that changes its return type based on a parameter I want to pull my hair out. Junior developer, myself included, fall prey to making things super DRY which actually can make the code more confusing and difficult to follow/reason about.
> as long as it doesn’t touch the business logic, who cares!
Here's the thing about that, even I still make mistakes (and will until I retire) when it comes to "this code is functionally the same". "doesn't touch the business logic" is a much harder thing to be sure of than one might think and unless you are intimately familiar with all the code calling through what you are changing can you really be sure? Literally just last week I made a mistake that got through multiple code reviews as "yep, that's functionally identical" but we missed a weird case further down that none of us had expected from reading the code. Also, see again: git history. I didn't always care as much about git history but I had a boss that instilled into me its value and now I fight to preserve it as it can be incredibly helpful in debugging or attempting to make a change to code (again, Chesterton's fence).
None of this is meant to be come across as attacking you are me telling you that I think you are wrong. Just how I see things, take from it what you will, ignore what you will. My way is not the perfect way, just the way I've learned over many years doing this professionally.
[0] https://en.wikipedia.org/wiki/G._K._Chesterton#Chesterton's_...
> 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.
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 couldn't agree more. Put in a ticket if you think there is a real problem that should be addressed but don't burn git history to fix indentation or something similarly minor. I have plenty of "rules" for my own code style but I don't touch code not within the scope of what I'm working on and I fit the style of the code I'm working in. I prefer camelCase but if the function has snake_case then I follow that style. And yes, turning off auto-formatting is a must in a legacy codebase that didn't have style guides/linters being used from the start.
It's way more important that I can see why a line was written, who wrote it, and when than spaces get turned into tabs.
It's way more important that I can see why a line was written, who wrote it, and when than spaces get turned into tabs.
> junior devs write far too complex code
…
> 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 :)
…
> 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 :)
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.
> And I can’t see anything in here as legitimate.
Does “here” refer to the book or the blog post?
Does “here” refer to the book or the blog post?
The author describes the way clever programmers operate.
Simplicity above all.
Simplicity above all.
Exactly!
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.
[deleted]
this is objectively the correct way to write software anyway, everything else is dumb