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.
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.
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.
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 :)
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.
> 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.
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.
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.
> 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...
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. ;)
> 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.
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 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.
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
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.
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 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.
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.
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.
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.
> 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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
So? I also conclude that most humans have two legs and 10 fingers and a head, and two ears and skin and hair. We gonna dismiss all of that because the data is just anecdotal?
>The plural of anecdote is not data!
The plural of anecdote is anecdotes (with an s) the adjective form of anecdote, is "anecdotal" as in "anecdotal" data.
Anecdotal evidence isn't worthless, but it's not solid proof either. It's prone to bias and lacks the breadth and rigor of systematic data. Pointing out common human traits doesn't strengthen your argument; these are well-documented facts, not mere anecdotes. The leap from "my experience" to "universal truth" requires data, not just stories. Anecdotes spark curiosity; data provides answers.
Anecdotes are more then just curiosity. They are real possibilities.
When you walk you assume the ground is real based off of anecdotal data. Not science.
Data and science is hard and highly limited. The majority of the world is unverified with science. To limit your conclusions to only rigorous data is to say you cannot walk because you aren't sure the ground exists.
My claim here is that smarter people are more likely to write sloppy code. My meta claim is that That claim is both based off of anecdotal data and also likely to be true.
Yeah, anecdotes are good for making observations to base a hypothesis off of, but that's it. You can't really draw conclusions from them as if they're data. Walking on the ground is based on a repeatable experience and is based on physics. We can't say if the conclusion you're drawing is most people have two eyes, or that most people are white. Claiming smarter people are more likely to write sloppy code based on anecdotes overlooks how diverse the field of programming is, and how complex programming is, and how different people are. It's a mix of education, experience, culture, and individual habits. Using anecdotal evidence for such claims is going to overlook counterexamples and is basically gonna be confirmation bias.
Your meta-claim lacks rigor. Again, the plural of anecdote is not data. The truth of a claim in the realm of human behavior and skills requires empirical evidence, which involves a stupid amount of work to make systematic observations to get shittons of data to override sampling bias, far beyond what any one human could experience. Without data, we've got speculation, not reliable conclusions.
Everyone's entitled to their own opinion. You're entitled to believe "smarter people are more likely to write sloppy code." Just like I'm entitled to my opinion that that's based on evidence subject to confirmation and sampling bias rather than any grounding in fact. :) We're going around in circles at this point, so I'll stop, but it's been fun.
No not, "we". You are going in circles. I already stated that you walk therefore you believe the the the ground exists without science. You already assume a truth with zero rigorous scientific data.
Yet you don't counter this claim. You make the same argument again and again stating that anecdotal data isn't truth. But you place each foot one in front of the other whenever you walk assuming the ground exists from purely anecdotal data. Why?
Thus my argument is valid. IF you don't respond to this then it is YOU who is going in circles. I have definitively responded to your point here with a contradiction. You HAVE not addressed the contradiction. The opening is laid out by me, but instead of moving forward you decide to repeat the same point.
Not trying to be offensive here. But I am clearly laying out exactly what's going on here. It is YOU who is travelling in a flat circle. NOT me.
> 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:
. dumb | smart
messy __1___|___2___
clean 3 | 4
Your theory is that only 2 and 3 exist, and that 1 and 4 are impossible. The world is wide, and I've met programmers in 1 and 4, with as much evidence as you do, anecdotal evidence. If you do have data to back up your claim, I'd love to be proven wrong! Because while my habits put me into group 2, I'm definitely more in group 1.
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.
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.
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?
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?
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.
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.
85 comments
[ 4.6 ms ] story [ 180 ms ] thread- https://news.ycombinator.com/item?id=39613326
- https://news.ycombinator.com/item?id=39620507
Simplicity above all.
Does “here” refer to the book or the blog post?
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 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’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.
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.
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.
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'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...
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.
But I suppose fish don't find it hard to breathe in water, either.
“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?
> 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.
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 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
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.
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.
Anyone else like this? Maybe I have a learning disability or something.
IQ isn't a universal "you're good at everything" score, even if it was an objectively good measure of intellience.
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.
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.
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.
There's no raw data to back either statement up, but both are very likely to be true via common sense.
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/
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?
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 mean literally it's just one command. I'm referring to style and neatness beyond the linter.
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.
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.
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.
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.
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?
And who's to say that the correlation I happen to want isn't real?
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.
Living in Scotland and sampling your data there, concludes that all humans are white, along with having two eyes.
So? I also conclude that most humans have two legs and 10 fingers and a head, and two ears and skin and hair. We gonna dismiss all of that because the data is just anecdotal?
>The plural of anecdote is not data!
The plural of anecdote is anecdotes (with an s) the adjective form of anecdote, is "anecdotal" as in "anecdotal" data.
When you walk you assume the ground is real based off of anecdotal data. Not science.
Data and science is hard and highly limited. The majority of the world is unverified with science. To limit your conclusions to only rigorous data is to say you cannot walk because you aren't sure the ground exists.
My claim here is that smarter people are more likely to write sloppy code. My meta claim is that That claim is both based off of anecdotal data and also likely to be true.
Your meta-claim lacks rigor. Again, the plural of anecdote is not data. The truth of a claim in the realm of human behavior and skills requires empirical evidence, which involves a stupid amount of work to make systematic observations to get shittons of data to override sampling bias, far beyond what any one human could experience. Without data, we've got speculation, not reliable conclusions.
Everyone's entitled to their own opinion. You're entitled to believe "smarter people are more likely to write sloppy code." Just like I'm entitled to my opinion that that's based on evidence subject to confirmation and sampling bias rather than any grounding in fact. :) We're going around in circles at this point, so I'll stop, but it's been fun.
Yet you don't counter this claim. You make the same argument again and again stating that anecdotal data isn't truth. But you place each foot one in front of the other whenever you walk assuming the ground exists from purely anecdotal data. Why?
Thus my argument is valid. IF you don't respond to this then it is YOU who is going in circles. I have definitively responded to your point here with a contradiction. You HAVE not addressed the contradiction. The opening is laid out by me, but instead of moving forward you decide to repeat the same point.
Not trying to be offensive here. But I am clearly laying out exactly what's going on here. It is YOU who is travelling in a flat circle. NOT me.
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:
Your theory is that only 2 and 3 exist, and that 1 and 4 are impossible. The world is wide, and I've met programmers in 1 and 4, with as much evidence as you do, anecdotal evidence. If you do have data to back up your claim, I'd love to be proven wrong! Because while my habits put me into group 2, I'm definitely more in group 1.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 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.
It also makes sense logically. A smarter person will be faster at reading sloppy code.
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.
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?
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.