Reads like one of those "what happened to GOOD code" articles, except this time the author plays the victim and pretends like there's a conspiracy among employers against good code.<p>What strikes me with all these articles is that good code is never objectively defined. It's always some arbitrary measure, sprinkled with common wisdom (write tests! Keep functions small!). The author assumes that they write GOOD code and those evil managers and business people actively conspire against them for writing GOOD code.<p>I suspect most people who write these articles aren't as good as they think. Most genuinely good engineers know the value of code, and how to balance their objectives with time. Being difficult to work with by insisting on arbitrary measures (e.g. all functions need to be pure and follow my naming convention!) does not make one a good engineer.<p>There's a reason good communicators advance in their careers while grumpy tech-leads who constantly bring problems stay at their level.
>I get the cold sweats when I see methods longer than a few lines of code<p>This guys code might not be as readable as he thinks. I do not want to read through your hundreds of 10 line functions because a few people said "long functions bad".<p>I liked the portion on naming. My God the amount of AbstractFactorySingletonViewModel garbage I see is astounding.
In my programs there's usually a core insight or mental model that makes the code simple and straightforward to understand.<p>What does someone need to have in their mind to understand this program?<p>Then time happens and then the code is adapted and refactored and more features are added, then the original gem of mental model is hidden by hundreds of files and the algorithm is split into 10s of files for the little bit of wisdom that makes the whole program understandable to be occluded.<p>This is why I like full code listing examples in documentation so much. A small self contained example - with import statements and instructions on how to build it if necessary and dependencies mentioned, I can get started extending the program to do something that I want.<p>Strangely, I find leetcode solutions or algorithms easier to understand than big enterprise systems or codebases where people do things the right way, because the core algorithm is right there and you cannot miss any detail.<p>I've enjoyed using OpenGrok a code indexer and viewer to turn any codebase into a wiki.<p>When I come to a new codebase, I have no clue how people have split up the code into many files.<p>The DWM codebase is fairly straightforward to read because it's all in one file.<p><a href="https://dwm.suckless.org/" rel="nofollow">https://dwm.suckless.org/</a><p>I want to read about your code rather than the code itself if I can help it, I prefer reading documentation or deep dives or tutorials into code than a large github repository with hundreds of files.<p>I really liked the trend for a while in web frameworks where the code was side by side the documentation.
It's easy to find lots of clickbaity stuff this author has written about software development. It's hard to find any software they've actually developed.
What on earth is the point of this article? It doesn't seem to contain anything other than bragging on the part of the author and a number of buzzwords?<p>And some positions seem quite strange. Not all function names will relate to "the problem the user wants us to solve for them." What does the user know or care about a function like atoi() or malloc()? And is it really unnecessary to ever write comments with readable code?
I can give you a "clean" secret: Functional programming thinking.<p>No, i don't talk about the "haskell style FP", i'm talking about FP thinking.<p>It could help you clean your mess in a productive way, and i call it the true craftsmanship.
As a power fantasy, I heavily relate to this. I would love to be that archetype of writing amazing cathedrals of code with absolutely no tradeoffs with testability, readability, or (amazingly) time spent on development. To be a misunderstood genius whose only limit to delivering infinite value is the incompetence of my employer.<p>However, this <i>is</i> a fantasy.<p>>I’m obsessed with making my code readable, even to non-programmers<p>This is a plainly impossible goal, because programmers themselves don't agree what "readable code" is. The problem is that sufficiently useful code always exists in a context where tradeoffs are inevitable.<p>When the universe aligns to help us forget this, the success can be intoxicating. Wouldn't it be nice to live in a world where all projects can be like that? Software Craftsmen then get seduced into Software Masturbators.
There's a core & real-to-some people feeling from some devs that wanting to do a good job & make things <i>tight</i> is a position that gets you persecuted. Many people want <i>slip,</i> want to just take easy ways a lot. There's a real tension to seeing software as a craft, versus regarding it all as low grade industrial output.<p>I don't think the article does a super job of explaining itself or making visible this conflict, but I think this is one of very few pieces out there that talks to one of the realest most core splits in the field, that causes some of the most tension & agony between different people & different parts of orgs trying to work together.<p>This those of us <i>close to the machine,</i> it is a conflict that sometimes feels like it has few wise, knowing, pro-Craft allies in.
This smells funny to me... too much dogma.
Sometimes the best and clearer way to do something is the "wrong" way.<p>Testing adds some cost, so there's a tradeoff. You want a decent ROI on your testing efforts, otherwise you're wasting time and money. Opportunity should not be ignored.<p>Software doesn't have to be zero defect, it has to be low enough to be useful.
Break every rule, sometimes.<p>Have a hundred-line function, when it makes sense. Try it out; it won't kill you, or your team, as long as it is well-documented.
lower your cost of living, take regular long vacations, and craft!<p>the solution space of software useful to humans is barely explored. imaginative, unconstrained, passionate builders are for great good.<p>collaborative software implementation for salary in the typical cost center environment is always going to be a tragedy of the commons. this is actually fine.
Function shortness is not, in and of itself, a value.<p>There are many obvious examples where it makes excellent sense to refactor a complex function into several smaller functions. I get frustrated with the spirit of this post because I honestly have never seen anyone challenge this.<p>However, I frequently see PRs which appear to be breaking a longer but repetitive function into a large number of mostly single line functions, apparently with the single goal of achieving checklist compliance with the folk wisdom. In these cases, we've devolved from a list of (for example) simple name mappings with the occasional downcase() (for the bold!) to having to jump back and forth between multiple points in the file, which has now grown by 80-150% to account for all of the begin/end sigils (language/lint dependent).<p>If you're converting a JSON string to a dictionary and then mapping a large number of attributes, moving from<p>object.foo = json["foo"]<p>to<p>object.foo = extractFoo(json)<p>with a matching three line getter you have to scroll 2-3 pages down to read and does the exact same thing is not a win.<p>TL;DR context matters and general rules only help when you don't treat them like hammers.