14 ms·

Software engineers hate code

369 points by dfcowell 3y ago

anonzzzies 3y ago
Don’t think it’s a secret though.
nixpulvis 3y ago
This is like writing “mechanics hate bolts”. Yea, mechanics love to complain about metric and imperial sizes and when they don’t thread in correctly, but at the end of the day a good mechanic loves seeing a smooth running car. Similarly, a good software engineer loves it when they have a smooth running service. Updates work without hiccup and the system can be inspected to see how things are running. Having clean and maintainable code is directly proportional to the ease and pleasure of work on this service. I believe in quality over quantity and I also believe that beautiful code exists. My hatred of code comes from lazy or rushed implementations, which can and should be improved over time. LGTM culture is a product of bad management and should not be used as an excuse to ship lazy code or code written by people who hate what they do. A good engineer should take pride in their work, even on the bad days. And even when the product itself isn’t what they would personally want.
- resonious 3y ago
  > LGTM culture What are you referring to specifically here? A culture where nobody is actually doing reviews and just LGTMing everything?
  - formerly_proven 3y ago
    Yep
  - nixpulvis 3y ago
    Yep
- jrochkind1 3y ago
  What percentage of code you have worked with in your career is that beautiful code that you love to work with? To make it more fair, code you wrote yourself doesn't count, because you aren't an objective observer -- and more importantly, have a different relationship to it making it easier to work with since you wrote it, and often to your own preferences. I think I agree with you, it's just that... the actual way software is written doesn't seem to allow for much clean and maintainable and easily extensible code to be written, so I'm not sure how much it matters practically.
  - nixpulvis 3y ago
    A healthy percentage of the open source projects companies I’ve worked for have used and opened PRs against I would call pretty good looking. Ruby on Rails was always nice to read through and well documented. I also find a lot of datasheets and RFCs to be highly elegant and beautiful, if not a bit dense and verbose. It just depends sometimes, what makes something like art beautiful. I disagree strongly that “the actual way software is written …”, though it does feel like trying to write clean code is an uphill battle sometimes. Back to the shop analogy. Cleaning up oil spots and maintaining well polished tools requires time and care.
- dools 3y ago
  "I hate writing. I love having written" https://www.goodreads.com/quotes/57688-i-hate-writing-i-love-having-written https://www.goodreads.com/quotes/57688-i-hate-writing-i-love...
dgbrewer1989 3y ago
Interesting. I'd say that's true for the majority of engineers yeah. For my own career I've been stuck on projects (with the exception of one last month) that was all over 3 years old and needed maintenance. Some projects were learning to read AS400 RPG code then converting that into java code. So I guess that is kinda greenfield? I don't know, I enjoy reading code and understanding what's happening But I absolutely get the distaste for it
lolive 3y ago
Sometimes, software engineers find abstractions that suit their mental model. Sometimes, they even are able to create codes that match such abstractions. Sometimes, those abstractions are now flawed. Sometimes, those abstractions are properly tooled. Sometimes, the rest of the team also understands those abstractions. The conjonction of all these rarely happen.
usrbinbash 3y ago
> Don't write new code when you can use, improve or fix what already exists. If you must write new code, write only what you need to get the job done. While the article resonates with me alot, I would like to, in the best spirit of the article, propose an addendum to that line: When modifying existing code, do a very careful cost-benefit analysis; On the one side is the cost of a rebuild. On the other side is the projected cost of keeping this thing and maintaining it, not just for this change, but for changes in the forseeable future. I realise that this is essentially an impossible requirement. We cannot forsee the future. But: We can make predictions. And when the predictions say, that, forseeably, the company will lose money down the line because we waited to long for a rebuild, it may be time to pitch that to whoever allocates resources. Because, dragging a legacy-system along incurs it's own set of costs. This is especially true when it's not just maintained, but modified and extended. And many of those costs have a nasty tendency to remain hidden until they suddenly don't, and at that point, people often already expended inordinate amounts of resources on them. So yeah, the first instinct should be: Use what already exists. But check the costs of doing so. Premature rebuilds are a waste of resources. And so is holding on to legacy systems past their expiration date.
- PartiallyTyped 3y ago
  Personal example I am living through. By the estimates of another team, it will take 2-3 months to build a wrapper around their codebase (it is that entangled) and throw that in EC2. The whole project will become infested with that codebase and those issues because as we all know, a “temporary fix” is never temporary. The codebase doesn’t cover anywhere near what we have in mind for features and extensibility is … yeah.
- elygre 3y ago
  I notice that on your “one side”, you have the cost of the rebuild — but not the “projected cost of keeping this thing and maintaining it”. That’s a common fallacy of programming: the existing code is convoluted and hard ti maintain, but the new code I would replace it with will be much better and much cheaper to maintain.
  - 3y ago
raincole 3y ago
Developers hate code. Non-developers fear code.
- B1FF_PSUVM 3y ago
  ChatGPT shits code
JohnFen 3y ago
> This is the best-kept secret of the software engineering profession: engineers hate code. Especially code written by other people. It's why they love working on greenfield projects so much. No code, no maintenance, no headaches! Except that I've met lots of engineers who were the opposite. They hate greenfield projects and prefer maintaining existing code. I noticed this broad division of personality early in my career. And it's a great thing -- both sorts of engineers are critical to a successful project.
- jrochkind1 3y ago
  But do they actually want to read the code on the existing project, or just write new code adding to it? Nothing is universal, but I think often the latter.
  - delusional 3y ago
    I always apply Chesterton's fence when working on existing systems. You don't get to add, remove, or change things before you understand what exists. That discovery is inherently exciting to me.
  - bayindirh 3y ago
    Well, I'm currently trying to reverse engineer something done by an open source SaaS offering, to patch a tool written by another person which works with that part I'm trying to reverse. I just wanted to use the tool without any effort, but I have to understand the interface and patch the tool to make it work again. I'm not complaining. Just wanted to add a data point for the former part of your comment.
    - jrochkind1 3y ago
      And you enjoy and prefer this kind of work? OK! I guess occasionally I enjoy this kind of work too, when I'm in an environment with reasonable expectations of how challenging it will be/long it will take, when I have room for it.
  - WJW 3y ago
deleted 3y ago
[deleted]
formerly_proven 3y ago
I always say “one bug per if”.
- Supermancho 3y ago
  I dont like this, but it's hard to find fault in it in the context of an aging (eg 50yrs+), large, corporation. There are always corner cases and workarounds that would require inverting the expected output of an 'if statement', requiring yet-another-one altogether.
- B1FF_PSUVM 3y ago
  That's a good phrase, true or not. Poetic licence.
syntaxing 3y ago
Better yet, engineers in general hates discipline. A lot argue it stifles innovation, makes them work slower, a bunch of red tape. While it’s true to a certain degree, you also can’t scale without discipline. If you can’t scale, it’s not engineering, it’s a science project. It is a balance, too much processes hinders execution, too little means everything will be a mess by the time you deliver.
revskill 3y ago
Writing "unreadable code" is easy, just as too easy to make your room a mess. Writing "readable code" is so damm hard. Readable code leads to maintainable code, which reduces tech debts. Alright, many engineers just knows how to fix the bug and call it a day. It's a disaster thinking.
- zerodensity 3y ago
  I have heard of this magical beast "readable code" but have not yet encountered it in the wild.
  - someweirdperson 3y ago
    Examples have been discussed here [0] before. [0] https://news.ycombinator.com/item?id=4331688 https://news.ycombinator.com/item?id=4331688
000ooo000 3y ago
Doesn't seem right to say that engineers hate code. IMO, in a sense, code is lossy; rarely does it document the full set of assumptions, intentions and context relevant at its inception or over its life. Possibly more appropriate to say that writing new code can sometimes avoid the lack of those things which make modifying code simpler. Do engineers hate being in a position where they have to rely only on intuition and inferences rather than hard evidence? Well, I do, at least. Do I hate code? Nope
miikavonbell 3y ago
I've been a software developer for almost 10 years and during that time I've questioned many times why I keep on going. A while ago I realized that the biggest thing that I like about software development is the simplicity within it's complexity. What I mean by this is; software either works or it doesn't. In many other professions this is not the case. So while there are many things that could be done better and more efficiently, at the end of the day, your code either works or it doesn't. So simple, but yet, so ruthless.
- jowdones 3y ago
  My high school computer science teacher (almost 30 years ago that is) used to say: "A program that 'almost works' is like a plane that 'almost flies'".
  - falcor84 3y ago
    Now I'm just trying to mentally picture what a mode of transportation that almost flies would work like via animal metaphors - would it almost fly like a chicken? or like a flying squirrel?
- turdprincess 3y ago
  I find it to be more nuanced. Your code has to work correctly in a bunch of scenarios. Some are very simple to see, others are nuanced corner scenarios. A good developer will write code that passes many of these scenarios, but even the best will miss some. And an inexperienced developer might write code which passes some basic scenarios. So, “this code works” is really a range, not a binary condition.
  - miikavonbell 3y ago
    "Code either works or it doesn't" is more like a mindset and a pholisophy rather then truth or a fact. In the context of this article and this thread, I was just reminded about this approach. Hating or loving software development, other peoples code, or approach is sort of meaningless. At the end of the day, we all get paid to build software and it is our job to make the software functional. As long as the code works and does what it is supposed to do, thats all that matters.
weinzierl 3y ago
I'm not so sure about software engineers. We often value working solutions even if the code base is not perfect. I certainly do and I very much agree with Joel Spolsky in his classic: "Things You Should Never Do, Part I "They did it by making the single worst strategic mistake that any software company can make: They decided to rewrite the code from scratch." [1] (Emphasis his.) Where I'm 100% sure is that consultants hate code. I've never ever seen one recommending the reuse of existing code - not once. And it's understandable: They have nothing to gain from recommending reuse of existing code. In the best case the code is good and everything else goes well and the client saves some money. If the consultant can not pull this of repeatedly their benefit will still be limited. The praise will be with the programers. On the other hand, if the old code is bad or anything else goes wrong everyone will blame the consultant for the recommendation. For the consultant it's a risk-return tradeoff that just always favors a rewrite from scratch. [1] https://www.joelonsoftware.com/2000/04/06/things-you-should-never-do-part-i/ https://www.joelonsoftware.com/2000/04/06/things-you-should-...
- andix 3y ago
  Im a big advocate of rewriting code from scratch. Because on a rewrite you have a much better starting point. You have a (mostly) working solution, you understand the problem much better than on the first attempt, you have some tests and some data. Most of the time you don't rewrite it 100% from scratch, often you can copy a lot of code from the old solution. To utilize all those benefits you can't rewrite everything at once from scratch. You need to do it incrementally.
  - jvans 3y ago
    The incrementally part is extremely important and often overlooked. I have seen project after project attempt some major big bang rewrite that always takes way longer than expected, delivers less value than promised, and causes problems in areas that used to work fine. We often understand some big picture things better as time goes on but there's a thousand small decisions baked into the existing code that are very easy to overlook On incremental improvements you should be able to stop what you are doing within a week or two and be ok with leaving the code like that for a long time.
deleted 3y ago
[deleted]
goto11 3y ago
Code is only greenfield until the first commit.
- nathants 3y ago
  false. it’s until the concrete hardens. could be quick, could be slow.
nikanj 3y ago
The people who truly hate code work in upper management. Coders are expensive, hard to hire, and tend to say no a lot. You can make so much money selling hoax ”zero code” solutions, as management is very happy to drop money into projects that promise to replace coders with Magic Product(tm)
partomniscient 3y ago
Software Engineers also hate sensationlist headlines/titles.
- CyberDildonics 3y ago
  I think Hacker News shows that they love them.
  - someweirdperson 3y ago
    Most people love to hate something. That and reproduction are the two main factors that govern almost all human behavior.
bulhi 3y ago
There are only a few experiences in life that give me a dopamine rush as intense as when I delete code. I used to think I was weird, but apparently I'm just a senior engineer.
- abalashov 3y ago
  Same, and I'm not a senior engineer. Plot twist!
_madmax_ 3y ago
This is so full of over generalizations it gets boring really fast.
notjoemama 3y ago
I'm an engineer and I don't hate code. But I do hate clickbait.
fsociety 3y ago
Reading and untangling code is the best part of coding in my opinion. It’s like solving a fun puzzle and trying to incrementally evolve a system. What I hate is inconsistency. Inconsistency is what makes code intolerable to work with, because changing it becomes so much harder. Consistency, in the way I mean it, does not mean DRY or over-abstraction. What I mean is, pick a mindset or design philosophy and stick to it. Don’t randomly switch between exceptions and returning errors. Don’t over-abstract some areas early on and then spaghetti code other areas. Have some consistency in how you do this. For example, have a rough standard for when something is X or Y. Either accept spaghetti code for areas and keep things uncoupled as much as possible (my preferred), or have some concept of abstraction you apply to new layers. Just rough examples. If it turns out you did it wrong, which is likely, then it is relatively easy to reason about a change. But as soon as you lose the consistency then it becomes a nightmare. Don’t have special snowflakes in your code. The last thing I’ll write is.. sometimes the over-generalization this article makes is used as a weapon to justify sunk cost fallacy. Sometimes throwing away a part of your codebase and starting from scratch is the best thing to do. But you should work with it for a bit to understand the code before doing so.
ibejoeb 3y ago
> we deprecate it as legacy and replace it with something new. Rolling green fields forever! That's a good way to put it. The nuance is that, most of the time, "deprecated" means "not going anywhere anytime soon, so now we have 2+ subsystems for the same thing." You really do need someone with a grand plan to keep this in check.
theknocker 3y ago
[dead]
deleted 3y ago
[deleted]
ranting-moth 3y ago
Using a house analogy, I don't hate other people's houses. I hate it when other people blow a hole in the side of my house to put in a new window. They blasted a hole through two walls because it was the quickest way. Then just taped some plastic over the second hole. The project manager said it's still summer and we don't really need that wall at the moment. I know who will have to fix the wall when the winter comes and I'm not looking forward to it. There's nothing in it for me and I'll get asked why my wall wasn't OK in the first place?!
- activiation 3y ago
  They got off easy with your analogy.
- zer8k 3y ago
  A follow up analogy is more typical in my experience. The foreman says that we should reinforce the walls. The PMP certified 6 sigma ninja Project Manager insists that the reinforced walls aren't necessary because no one is going to put anything on the wall. We will revisit the wall later when we the city tells us to enforce new wall codes. No more than 6 months later a contractor tried to add a shelf to the unenforced wall. The contractor was never aware of what was in the wall and assumed he could find a stud. What he thought was a stud was actually the stud finder pinging on a water pipe. The construction workers didn't have time to run any tests with stud finders so they just wired everything up at the behest of management and hit the wall a few times with a rubber mallet to see if it held up. The project was behind by a week already due to the plans getting to the job site late. He pounds in the nails, hits the water pipe, collapses the wall and floods the house. The on staff construction crew lose their jobs, the VP gets a promotion for showing they did something about this egregious error, and they are replaced with contractors.
  - gabereiser 3y ago
    “All of this has happened before, and all of this will happen again” - Six, BSG.
    - 3y ago
psychoslave 3y ago
That is non sense. Like any peace of art, code can be a delight to contemplate or an awful experiment that was done as is just because, see, it's possible. Of course 99% of everything is crap, and no one like to ingest crap. Add to that impossible deadlines and usual exponential accumulation of hot fixes to a point where a bright new product will be more effective than paying the technical debt. Crafting software is on far worse road than most form of art. All that said, yes, there are great peaces of code that are a delight to contemplate.
- beebmam 3y ago
  I like contemplating all code and thinking about ways to improve it. I've made a career of being a code janitor.
kodah 3y ago
Reading this article I realize how different I am from, I guess, some of my peers. I do like working on new things, but methodically shaping old software, bringing it up to date, and all the tactical thinking you need to employ to do so is very fun. Microservices are okay, and I use them mainly when I have a particular part of a codebase that's best suited to scale on its own. Outside of that, I'm a big fan of starting with monoliths that are written so they can be decomposed at a later date. There's something really nice about a well put together codebase. Stack overflow is probably another place I differ from other engineers. I'll use it to discover patterns I'm not aware of, but I'm much more inclined to actually Ctrl+click and look at how a thing is implemented and it's sibling methods. Of course, you need well put together local configuration to do all that. I'm always looking for ways to keep my debugger in-tact, even when dealing with things like secret storage on a zero trust network. I use flags a lot for this that let me use mock-local responses. Then again, I work on infrastructure stuff. The kind of applications I work on have to exist for a long time because of internal contracts and dependencies. Maybe this piece is more aimed at product SWEs.
- VirusNewbie 3y ago
  Yeah i’m a swe SRE and i love going into a moderately well architected application and making it even better or more scalable. It’s fun!
- klysm 3y ago
  I hit a turning point at some point where I stopped being afraid to read library code and ctrl click through things. Not sure when exactly it happened but I think it was related to some imposter syndrome and holding the library code as “holy”. Looking through library code instead googling can be incredibly productive and polishes your code reading skills which are very important.
nathants 3y ago
sturgeon’s law applies. most of the time they are right to. put another way, 90% of code is a liability, 10% of code is an asset. i’m not sure any code ever moved from one group to the other, though good ideas may be stolen sans code. greenfield is the only way to grow that 10%. it’s the reason startups exist. it’s like all the failed rewrites. those engineers gained knowledge and fitness through that failure. if their current employer doesn’t retain them, that knowledge and fitness will pay dividends to the next one.
- klysm 3y ago
  Rewrites are a phenomenal way to sprint through an incredible number of Chestersons fences. That is one way to find out why they are there though it’s just a bit more expensive
  - nathants 3y ago
    if you don’t deploy them, their cost goes to zero! assuming the spent engineering hours would have been wasted elsewhere anyway. ymmv.
- avgcorrection 3y ago
  68% of all random-ass percentage laws are crap.
  - nathants 3y ago
    68 < 90. technically correct.
hahamrfunnyguy 3y ago
It's a great day when I've deleted more code than I've written!
thenoblesunfish 3y ago
Yes, hell is other people's code, haha. But you don't need microservices to write modular or encapsulated code.
deleted 3y ago
[deleted]
easeout 3y ago
In this thread: Software engineers also love to point out when their counterexample has been glossed over by an intentionally simplistic thesis. (In this comment: Software engineers also love to sass one another)
- riwsky 3y ago
  Sass is unnecessary in modern stacks; just use tailwind instead
nfw2 3y ago
Literally my primary motivation to be productive at work is maxing the ratio of my code to other people's code that I have to deal with
- birdyrooster 3y ago
  Literally my primary motivation to not be productive at work is people maxing the ratio of their code to my code. They do all the work and management is still fine with paying me more because of seniority. I think this is a fair trade as all freedom comes with responsibility -- I used to be the same way earlier in my career.
rationalfaith 3y ago
[dead]
zerodensity 3y ago
All code is not created equal. In a project there is normally some divide between shared code and service specific code. This divide can be as simple as a base class and its children or a library and the microservices that use it. I declare that shared code is sacred and should only be touched for a good reason. (Note: sacred does not imply good) So when reviewing my carelevel is highly dependent on if shared code is touched. If the commit only contains changes in the leafs eg subclass / single microservice my gut instinct is to trust the code and go into LGTM mode (if it goes wrong it's at least localized). But if shared code is touched I don't trust it, I deep dive and complain about everything I can think of.
praveen9920 3y ago
It’s not 100% true. It depends on how well the code was written and documented. When we see patterns or complex code which are different from what we are used to, it takes some amount of effort to understand and to make changes. code that is simple, documented and well written is best thing any developer can inherit.
Falkon1313 3y ago
>Senior engineers hate extraneous code. They hate seeing time and effort invested in building yet another solution to an already-solved problem. [...] >Don't write new code when you can use, improve or fix what already exists. Caveat: Refusing to write new code often means pulling in and/or writing a whole bunch of extraneous code. Senior engineers also hate dependency hell, having to patch other people's code because upstream hasn't fixed it yet, knowing that might break on the next update, yoinking in massive complex frameworks and libraries when you could've just used a few simple functions, and having lots of kludgy plumbing code to wire up all those third party dependencies and generic abstractions. All those things that people do just because it's best practice not to "reinvent the wheel". All those things that require extra work, maintenance, and system resources, but aren't directly related to solving the business problems. All that time wasted not even working on the valuable domain logic. And then when you do eventually get around to implementing or modifying a domain case, can you even find where the domain code is in all that mess of extraneous code?
deleted 3y ago
[deleted]
wizofaus 3y ago
> The more code that gets written, the more things there are to break, and more of those precious hours will be taken up by maintenance Can definitely relate - PRs with lots of new code immediately trigger alarm bells for me, and while reading through all that new code ain't necessarily fun, coming up with ways to reduce it is a worthwhile and rewarding challenge - unfortunately you're then stuck with the thankless task of convincing the author why they should throw away all their hard work.
- lolc 3y ago
  It's a good idea to pull in reviewers early while mapping out a solution. Not easy though.
rglover 3y ago
I love code (similar to how an artist might love a type of paint brush), but what I don't love is code that's designed to impress or an attempt to show off hOw SmArT i Am. More often than not, that code isn't the most efficient or the cleanest, it's just a contraption that looks impressive to an untrained eye. That type of code is guaranteed to turn a code base into a mess—all for the sake of someone's ego. My preferred heuristic is: "will I or any other developer be able to understand this—quickly—in six months (preferably without comments)?" If the answer is "no," refactor using a different approach.
exmicrosoldier 3y ago
There is only one more thing I am afraid of more than duplicate code. Shared code that someone changes to make their code work better that breaks yours.
29athrowaway 3y ago
Software engineers do not hate code. They hate when they're put in front of horrible code and they are disempowered to do anything about it. Or they are forced to agree with people with learned helplessness.
mtippett 3y ago
To me, it isn't about the code itself, it's about communication, it's about a relationship with others through code, systems and architecture. Using the relationship analogy, when you can hear something small from your partner and know what they are thinking, understand what they may do next it feels effortless. When you look at some code, can you trust what the function name implies is done, without concern? When something is complex in a relationship we pause to take time to communicate and come to a common understanding, we write notes to each other. When we have something complex in code do we write down information to help the other engineers work through it? In a lot of ways the way we relate to our peers through code is possibly a reflection of how we relate to others in life.
drooby 3y ago
Q
boringuser2 3y ago
I'm terrible at reading code. I've analyzed myself in process and it's because I get bored and start glossing over details. In some cases, I feel this makes me a weaker engineer than my detail-oriented counterparts. In other cases, I connect concepts and problem solve better than they do because I am quite smart. The division of labor, I guess.
paseante 3y ago
ROFFFFFLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLL. OMG this is brilliant
patrec 3y ago
Why is this much more true of programmers than writers[1]? To what extent is it true of "proper" engineering disciplines? [1] A couple of people here doubt it being true. It is though, and I say that as someone who enjoys reading interesting code. A good case in point is this great, probing interview by Peter Seibel of Hal Abelson: https://gigamonkeys.com/code-quarterly/2011/hal-abelson/ https://gigamonkeys.com/code-quarterly/2011/hal-abelson/ Abelson: Read a lot of good code. That’s the real issue—that people don’t read code. [...] Seibel: I want to dig a little deeper on this. You, like many other people, say programmers should read code. Yet when I ask what code have you read for fun or edification, you—also like many other people—answer that you read students’ code, which is your job, and review code at Google, which is also your job. But it doesn’t sound like you sit down of an evening with a nice printout and read it. Abelson: Not for a long time. I can't imagine a professional writer answering like this.
fnordpiglet 3y ago
Only junior software engineers hate other peoples code. The progression of a skilled software engineer starts with writing code, then reading code, then writing code in the context of others code. The more you work the more crucial it is to be able to operate in a zone of non ownership in the code base, your value really unlocks when you can sniff code and improve it without rewriting it. At this stage 30y into my career I can step into a completely foreign code base and make material improvements quickly in situ, and sometimes have to do it several times a day. I don’t mind other peoples code - in fact I learn an awful lot of cool things spelunking! I tend to avoid the “let’s rewrite it” engineers - they’re usually going that route due to lack of practice and skill in developing software. There are times for sure a rewrite is necessary, but IMO it’s sort of like blaming the compiler for build errors. Usually it’s not the compiler, it’s you. But rarely there’s a compiler bug and you’re justified in asserting it as such. Likewise, rarely does code need to be rewritten, you are just unskilled at code surgery - so practice. When you have practiced enough you’ll see that the initial revulsion you felt at their code was mostly your brain reacting to the unknown. The people who wrote that code are often as good or better than you, and understood the domain a lot better if you’re new to the code base. Show a bit of respect for those who came before and learn to learn.
black_13 3y ago
[dead]
deleted 3y ago
[deleted]
vaughan 3y ago
It’s because you can only understand why things are structured the way they are, if you go on the journey from scratch yourself. It would probably be easier if there was a video or scrubber/slider to see how the code evolved. So many times you look at something and go: why is this so complex. Could be simpler. And you miss an edge case that causes the need for the complexity/abstraction. There are times too though that after a refactor someone can’t see some redundancy or is hanging onto an abstraction that looks great but is unnecessary.
gloosx 3y ago
I loved this article! In the end, it is exactly to the point: code adds and adds complexity; complexity we hate. At the same time, complexity comes from our flawed knowledge, and only true knowledge gained in battles shows us simple ways. Simple ways bring us joy.

369 points by dfcowell 3y ago

Don’t think it’s a secret though.

This is like writing “mechanics hate bolts”. Yea, mechanics love to complain about metric and imperial sizes and when they don’t thread in correctly, but at the end of the day a good mechanic loves seeing a smooth running car. Similarly, a good software engineer loves it when they have a smooth running service. Updates work without hiccup and the system can be inspected to see how things are running. Having clean and maintainable code is directly proportional to the ease and pleasure of work on this service. I believe in quality over quantity and I also believe that beautiful code exists. My hatred of code comes from lazy or rushed implementations, which can and should be improved over time. LGTM culture is a product of bad management and should not be used as an excuse to ship lazy code or code written by people who hate what they do. A good engineer should take pride in their work, even on the bad days. And even when the product itself isn’t what they would personally want.

resonious 3y ago
> LGTM culture What are you referring to specifically here? A culture where nobody is actually doing reviews and just LGTMing everything?
- formerly_proven 3y ago
  Yep
- nixpulvis 3y ago
  Yep
jrochkind1 3y ago
What percentage of code you have worked with in your career is that beautiful code that you love to work with? To make it more fair, code you wrote yourself doesn't count, because you aren't an objective observer -- and more importantly, have a different relationship to it making it easier to work with since you wrote it, and often to your own preferences. I think I agree with you, it's just that... the actual way software is written doesn't seem to allow for much clean and maintainable and easily extensible code to be written, so I'm not sure how much it matters practically.
- nixpulvis 3y ago
  A healthy percentage of the open source projects companies I’ve worked for have used and opened PRs against I would call pretty good looking. Ruby on Rails was always nice to read through and well documented. I also find a lot of datasheets and RFCs to be highly elegant and beautiful, if not a bit dense and verbose. It just depends sometimes, what makes something like art beautiful. I disagree strongly that “the actual way software is written …”, though it does feel like trying to write clean code is an uphill battle sometimes. Back to the shop analogy. Cleaning up oil spots and maintaining well polished tools requires time and care.
dools 3y ago
"I hate writing. I love having written" https://www.goodreads.com/quotes/57688-i-hate-writing-i-love-having-written https://www.goodreads.com/quotes/57688-i-hate-writing-i-love...

dgbrewer1989 3y ago

Interesting. I'd say that's true for the majority of engineers yeah. For my own career I've been stuck on projects (with the exception of one last month) that was all over 3 years old and needed maintenance. Some projects were learning to read AS400 RPG code then converting that into java code. So I guess that is kinda greenfield? I don't know, I enjoy reading code and understanding what's happening But I absolutely get the distaste for it

lolive 3y ago

Sometimes, software engineers find abstractions that suit their mental model. Sometimes, they even are able to create codes that match such abstractions. Sometimes, those abstractions are now flawed. Sometimes, those abstractions are properly tooled. Sometimes, the rest of the team also understands those abstractions. The conjonction of all these rarely happen.

usrbinbash 3y ago

> Don't write new code when you can use, improve or fix what already exists. If you must write new code, write only what you need to get the job done. While the article resonates with me alot, I would like to, in the best spirit of the article, propose an addendum to that line: When modifying existing code, do a very careful cost-benefit analysis; On the one side is the cost of a rebuild. On the other side is the projected cost of keeping this thing and maintaining it, not just for this change, but for changes in the forseeable future. I realise that this is essentially an impossible requirement. We cannot forsee the future. But: We can make predictions. And when the predictions say, that, forseeably, the company will lose money down the line because we waited to long for a rebuild, it may be time to pitch that to whoever allocates resources. Because, dragging a legacy-system along incurs it's own set of costs. This is especially true when it's not just maintained, but modified and extended. And many of those costs have a nasty tendency to remain hidden until they suddenly don't, and at that point, people often already expended inordinate amounts of resources on them. So yeah, the first instinct should be: Use what already exists. But check the costs of doing so. Premature rebuilds are a waste of resources. And so is holding on to legacy systems past their expiration date.

PartiallyTyped 3y ago
Personal example I am living through. By the estimates of another team, it will take 2-3 months to build a wrapper around their codebase (it is that entangled) and throw that in EC2. The whole project will become infested with that codebase and those issues because as we all know, a “temporary fix” is never temporary. The codebase doesn’t cover anywhere near what we have in mind for features and extensibility is … yeah.
elygre 3y ago
I notice that on your “one side”, you have the cost of the rebuild — but not the “projected cost of keeping this thing and maintaining it”. That’s a common fallacy of programming: the existing code is convoluted and hard ti maintain, but the new code I would replace it with will be much better and much cheaper to maintain.
- 3y ago

raincole 3y ago

Developers hate code. Non-developers fear code.

B1FF_PSUVM 3y ago
ChatGPT shits code

JohnFen 3y ago

> This is the best-kept secret of the software engineering profession: engineers hate code. Especially code written by other people. It's why they love working on greenfield projects so much. No code, no maintenance, no headaches! Except that I've met lots of engineers who were the opposite. They hate greenfield projects and prefer maintaining existing code. I noticed this broad division of personality early in my career. And it's a great thing -- both sorts of engineers are critical to a successful project.

jrochkind1 3y ago
But do they actually want to read the code on the existing project, or just write new code adding to it? Nothing is universal, but I think often the latter.
- delusional 3y ago
  I always apply Chesterton's fence when working on existing systems. You don't get to add, remove, or change things before you understand what exists. That discovery is inherently exciting to me.
- bayindirh 3y ago
  Well, I'm currently trying to reverse engineer something done by an open source SaaS offering, to patch a tool written by another person which works with that part I'm trying to reverse. I just wanted to use the tool without any effort, but I have to understand the interface and patch the tool to make it work again. I'm not complaining. Just wanted to add a data point for the former part of your comment.
  - jrochkind1 3y ago
    And you enjoy and prefer this kind of work? OK! I guess occasionally I enjoy this kind of work too, when I'm in an environment with reasonable expectations of how challenging it will be/long it will take, when I have room for it.
- WJW 3y ago

deleted 3y ago

[deleted]

formerly_proven 3y ago

I always say “one bug per if”.

Supermancho 3y ago
I dont like this, but it's hard to find fault in it in the context of an aging (eg 50yrs+), large, corporation. There are always corner cases and workarounds that would require inverting the expected output of an 'if statement', requiring yet-another-one altogether.
B1FF_PSUVM 3y ago
That's a good phrase, true or not. Poetic licence.

syntaxing 3y ago

Better yet, engineers in general hates discipline. A lot argue it stifles innovation, makes them work slower, a bunch of red tape. While it’s true to a certain degree, you also can’t scale without discipline. If you can’t scale, it’s not engineering, it’s a science project. It is a balance, too much processes hinders execution, too little means everything will be a mess by the time you deliver.

revskill 3y ago

Writing "unreadable code" is easy, just as too easy to make your room a mess. Writing "readable code" is so damm hard. Readable code leads to maintainable code, which reduces tech debts. Alright, many engineers just knows how to fix the bug and call it a day. It's a disaster thinking.

zerodensity 3y ago
I have heard of this magical beast "readable code" but have not yet encountered it in the wild.
- someweirdperson 3y ago
  Examples have been discussed here [0] before. [0] https://news.ycombinator.com/item?id=4331688 https://news.ycombinator.com/item?id=4331688

000ooo000 3y ago

Doesn't seem right to say that engineers hate code. IMO, in a sense, code is lossy; rarely does it document the full set of assumptions, intentions and context relevant at its inception or over its life. Possibly more appropriate to say that writing new code can sometimes avoid the lack of those things which make modifying code simpler. Do engineers hate being in a position where they have to rely only on intuition and inferences rather than hard evidence? Well, I do, at least. Do I hate code? Nope

miikavonbell 3y ago

I've been a software developer for almost 10 years and during that time I've questioned many times why I keep on going. A while ago I realized that the biggest thing that I like about software development is the simplicity within it's complexity. What I mean by this is; software either works or it doesn't. In many other professions this is not the case. So while there are many things that could be done better and more efficiently, at the end of the day, your code either works or it doesn't. So simple, but yet, so ruthless.

jowdones 3y ago
My high school computer science teacher (almost 30 years ago that is) used to say: "A program that 'almost works' is like a plane that 'almost flies'".
- falcor84 3y ago
  Now I'm just trying to mentally picture what a mode of transportation that almost flies would work like via animal metaphors - would it almost fly like a chicken? or like a flying squirrel?
turdprincess 3y ago
I find it to be more nuanced. Your code has to work correctly in a bunch of scenarios. Some are very simple to see, others are nuanced corner scenarios. A good developer will write code that passes many of these scenarios, but even the best will miss some. And an inexperienced developer might write code which passes some basic scenarios. So, “this code works” is really a range, not a binary condition.
- miikavonbell 3y ago
  "Code either works or it doesn't" is more like a mindset and a pholisophy rather then truth or a fact. In the context of this article and this thread, I was just reminded about this approach. Hating or loving software development, other peoples code, or approach is sort of meaningless. At the end of the day, we all get paid to build software and it is our job to make the software functional. As long as the code works and does what it is supposed to do, thats all that matters.

weinzierl 3y ago

I'm not so sure about software engineers. We often value working solutions even if the code base is not perfect. I certainly do and I very much agree with Joel Spolsky in his classic: "Things You Should Never Do, Part I "They did it by making the single worst strategic mistake that any software company can make: They decided to rewrite the code from scratch." [1] (Emphasis his.) Where I'm 100% sure is that consultants hate code. I've never ever seen one recommending the reuse of existing code - not once. And it's understandable: They have nothing to gain from recommending reuse of existing code. In the best case the code is good and everything else goes well and the client saves some money. If the consultant can not pull this of repeatedly their benefit will still be limited. The praise will be with the programers. On the other hand, if the old code is bad or anything else goes wrong everyone will blame the consultant for the recommendation. For the consultant it's a risk-return tradeoff that just always favors a rewrite from scratch. [1] https://www.joelonsoftware.com/2000/04/06/things-you-should-never-do-part-i/ https://www.joelonsoftware.com/2000/04/06/things-you-should-...

andix 3y ago
Im a big advocate of rewriting code from scratch. Because on a rewrite you have a much better starting point. You have a (mostly) working solution, you understand the problem much better than on the first attempt, you have some tests and some data. Most of the time you don't rewrite it 100% from scratch, often you can copy a lot of code from the old solution. To utilize all those benefits you can't rewrite everything at once from scratch. You need to do it incrementally.
- jvans 3y ago
  The incrementally part is extremely important and often overlooked. I have seen project after project attempt some major big bang rewrite that always takes way longer than expected, delivers less value than promised, and causes problems in areas that used to work fine. We often understand some big picture things better as time goes on but there's a thousand small decisions baked into the existing code that are very easy to overlook On incremental improvements you should be able to stop what you are doing within a week or two and be ok with leaving the code like that for a long time.

deleted 3y ago

[deleted]

goto11 3y ago

Code is only greenfield until the first commit.

nathants 3y ago
false. it’s until the concrete hardens. could be quick, could be slow.

nikanj 3y ago

The people who truly hate code work in upper management. Coders are expensive, hard to hire, and tend to say no a lot. You can make so much money selling hoax ”zero code” solutions, as management is very happy to drop money into projects that promise to replace coders with Magic Product(tm)

partomniscient 3y ago

Software Engineers also hate sensationlist headlines/titles.

CyberDildonics 3y ago
I think Hacker News shows that they love them.
- someweirdperson 3y ago
  Most people love to hate something. That and reproduction are the two main factors that govern almost all human behavior.

bulhi 3y ago

There are only a few experiences in life that give me a dopamine rush as intense as when I delete code. I used to think I was weird, but apparently I'm just a senior engineer.

abalashov 3y ago
Same, and I'm not a senior engineer. Plot twist!

_madmax_ 3y ago

This is so full of over generalizations it gets boring really fast.

notjoemama 3y ago

I'm an engineer and I don't hate code. But I do hate clickbait.

fsociety 3y ago

Reading and untangling code is the best part of coding in my opinion. It’s like solving a fun puzzle and trying to incrementally evolve a system. What I hate is inconsistency. Inconsistency is what makes code intolerable to work with, because changing it becomes so much harder. Consistency, in the way I mean it, does not mean DRY or over-abstraction. What I mean is, pick a mindset or design philosophy and stick to it. Don’t randomly switch between exceptions and returning errors. Don’t over-abstract some areas early on and then spaghetti code other areas. Have some consistency in how you do this. For example, have a rough standard for when something is X or Y. Either accept spaghetti code for areas and keep things uncoupled as much as possible (my preferred), or have some concept of abstraction you apply to new layers. Just rough examples. If it turns out you did it wrong, which is likely, then it is relatively easy to reason about a change. But as soon as you lose the consistency then it becomes a nightmare. Don’t have special snowflakes in your code. The last thing I’ll write is.. sometimes the over-generalization this article makes is used as a weapon to justify sunk cost fallacy. Sometimes throwing away a part of your codebase and starting from scratch is the best thing to do. But you should work with it for a bit to understand the code before doing so.

ibejoeb 3y ago

> we deprecate it as legacy and replace it with something new. Rolling green fields forever! That's a good way to put it. The nuance is that, most of the time, "deprecated" means "not going anywhere anytime soon, so now we have 2+ subsystems for the same thing." You really do need someone with a grand plan to keep this in check.

theknocker 3y ago

[dead]

deleted 3y ago

[deleted]

ranting-moth 3y ago

Using a house analogy, I don't hate other people's houses. I hate it when other people blow a hole in the side of my house to put in a new window. They blasted a hole through two walls because it was the quickest way. Then just taped some plastic over the second hole. The project manager said it's still summer and we don't really need that wall at the moment. I know who will have to fix the wall when the winter comes and I'm not looking forward to it. There's nothing in it for me and I'll get asked why my wall wasn't OK in the first place?!

activiation 3y ago
They got off easy with your analogy.
zer8k 3y ago
A follow up analogy is more typical in my experience. The foreman says that we should reinforce the walls. The PMP certified 6 sigma ninja Project Manager insists that the reinforced walls aren't necessary because no one is going to put anything on the wall. We will revisit the wall later when we the city tells us to enforce new wall codes. No more than 6 months later a contractor tried to add a shelf to the unenforced wall. The contractor was never aware of what was in the wall and assumed he could find a stud. What he thought was a stud was actually the stud finder pinging on a water pipe. The construction workers didn't have time to run any tests with stud finders so they just wired everything up at the behest of management and hit the wall a few times with a rubber mallet to see if it held up. The project was behind by a week already due to the plans getting to the job site late. He pounds in the nails, hits the water pipe, collapses the wall and floods the house. The on staff construction crew lose their jobs, the VP gets a promotion for showing they did something about this egregious error, and they are replaced with contractors.
- gabereiser 3y ago
  “All of this has happened before, and all of this will happen again” - Six, BSG.
  - 3y ago

psychoslave 3y ago

That is non sense. Like any peace of art, code can be a delight to contemplate or an awful experiment that was done as is just because, see, it's possible. Of course 99% of everything is crap, and no one like to ingest crap. Add to that impossible deadlines and usual exponential accumulation of hot fixes to a point where a bright new product will be more effective than paying the technical debt. Crafting software is on far worse road than most form of art. All that said, yes, there are great peaces of code that are a delight to contemplate.

beebmam 3y ago
I like contemplating all code and thinking about ways to improve it. I've made a career of being a code janitor.

kodah 3y ago

Reading this article I realize how different I am from, I guess, some of my peers. I do like working on new things, but methodically shaping old software, bringing it up to date, and all the tactical thinking you need to employ to do so is very fun. Microservices are okay, and I use them mainly when I have a particular part of a codebase that's best suited to scale on its own. Outside of that, I'm a big fan of starting with monoliths that are written so they can be decomposed at a later date. There's something really nice about a well put together codebase. Stack overflow is probably another place I differ from other engineers. I'll use it to discover patterns I'm not aware of, but I'm much more inclined to actually Ctrl+click and look at how a thing is implemented and it's sibling methods. Of course, you need well put together local configuration to do all that. I'm always looking for ways to keep my debugger in-tact, even when dealing with things like secret storage on a zero trust network. I use flags a lot for this that let me use mock-local responses. Then again, I work on infrastructure stuff. The kind of applications I work on have to exist for a long time because of internal contracts and dependencies. Maybe this piece is more aimed at product SWEs.

VirusNewbie 3y ago
Yeah i’m a swe SRE and i love going into a moderately well architected application and making it even better or more scalable. It’s fun!
klysm 3y ago
I hit a turning point at some point where I stopped being afraid to read library code and ctrl click through things. Not sure when exactly it happened but I think it was related to some imposter syndrome and holding the library code as “holy”. Looking through library code instead googling can be incredibly productive and polishes your code reading skills which are very important.

nathants 3y ago

sturgeon’s law applies. most of the time they are right to. put another way, 90% of code is a liability, 10% of code is an asset. i’m not sure any code ever moved from one group to the other, though good ideas may be stolen sans code. greenfield is the only way to grow that 10%. it’s the reason startups exist. it’s like all the failed rewrites. those engineers gained knowledge and fitness through that failure. if their current employer doesn’t retain them, that knowledge and fitness will pay dividends to the next one.

klysm 3y ago
Rewrites are a phenomenal way to sprint through an incredible number of Chestersons fences. That is one way to find out why they are there though it’s just a bit more expensive
- nathants 3y ago
  if you don’t deploy them, their cost goes to zero! assuming the spent engineering hours would have been wasted elsewhere anyway. ymmv.
avgcorrection 3y ago
68% of all random-ass percentage laws are crap.
- nathants 3y ago
  68 < 90. technically correct.

hahamrfunnyguy 3y ago

It's a great day when I've deleted more code than I've written!

thenoblesunfish 3y ago

Yes, hell is other people's code, haha. But you don't need microservices to write modular or encapsulated code.

deleted 3y ago

[deleted]

easeout 3y ago

In this thread: Software engineers also love to point out when their counterexample has been glossed over by an intentionally simplistic thesis. (In this comment: Software engineers also love to sass one another)

riwsky 3y ago
Sass is unnecessary in modern stacks; just use tailwind instead

nfw2 3y ago

Literally my primary motivation to be productive at work is maxing the ratio of my code to other people's code that I have to deal with

birdyrooster 3y ago
Literally my primary motivation to not be productive at work is people maxing the ratio of their code to my code. They do all the work and management is still fine with paying me more because of seniority. I think this is a fair trade as all freedom comes with responsibility -- I used to be the same way earlier in my career.

rationalfaith 3y ago

[dead]

zerodensity 3y ago

All code is not created equal. In a project there is normally some divide between shared code and service specific code. This divide can be as simple as a base class and its children or a library and the microservices that use it. I declare that shared code is sacred and should only be touched for a good reason. (Note: sacred does not imply good) So when reviewing my carelevel is highly dependent on if shared code is touched. If the commit only contains changes in the leafs eg subclass / single microservice my gut instinct is to trust the code and go into LGTM mode (if it goes wrong it's at least localized). But if shared code is touched I don't trust it, I deep dive and complain about everything I can think of.

praveen9920 3y ago

It’s not 100% true. It depends on how well the code was written and documented. When we see patterns or complex code which are different from what we are used to, it takes some amount of effort to understand and to make changes. code that is simple, documented and well written is best thing any developer can inherit.

Falkon1313 3y ago

>Senior engineers hate extraneous code. They hate seeing time and effort invested in building yet another solution to an already-solved problem. [...] >Don't write new code when you can use, improve or fix what already exists. Caveat: Refusing to write new code often means pulling in and/or writing a whole bunch of extraneous code. Senior engineers also hate dependency hell, having to patch other people's code because upstream hasn't fixed it yet, knowing that might break on the next update, yoinking in massive complex frameworks and libraries when you could've just used a few simple functions, and having lots of kludgy plumbing code to wire up all those third party dependencies and generic abstractions. All those things that people do just because it's best practice not to "reinvent the wheel". All those things that require extra work, maintenance, and system resources, but aren't directly related to solving the business problems. All that time wasted not even working on the valuable domain logic. And then when you do eventually get around to implementing or modifying a domain case, can you even find where the domain code is in all that mess of extraneous code?

deleted 3y ago

[deleted]

wizofaus 3y ago

> The more code that gets written, the more things there are to break, and more of those precious hours will be taken up by maintenance Can definitely relate - PRs with lots of new code immediately trigger alarm bells for me, and while reading through all that new code ain't necessarily fun, coming up with ways to reduce it is a worthwhile and rewarding challenge - unfortunately you're then stuck with the thankless task of convincing the author why they should throw away all their hard work.

lolc 3y ago
It's a good idea to pull in reviewers early while mapping out a solution. Not easy though.

rglover 3y ago

I love code (similar to how an artist might love a type of paint brush), but what I don't love is code that's designed to impress or an attempt to show off hOw SmArT i Am. More often than not, that code isn't the most efficient or the cleanest, it's just a contraption that looks impressive to an untrained eye. That type of code is guaranteed to turn a code base into a mess—all for the sake of someone's ego. My preferred heuristic is: "will I or any other developer be able to understand this—quickly—in six months (preferably without comments)?" If the answer is "no," refactor using a different approach.

exmicrosoldier 3y ago

There is only one more thing I am afraid of more than duplicate code. Shared code that someone changes to make their code work better that breaks yours.

29athrowaway 3y ago

Software engineers do not hate code. They hate when they're put in front of horrible code and they are disempowered to do anything about it. Or they are forced to agree with people with learned helplessness.

mtippett 3y ago

To me, it isn't about the code itself, it's about communication, it's about a relationship with others through code, systems and architecture. Using the relationship analogy, when you can hear something small from your partner and know what they are thinking, understand what they may do next it feels effortless. When you look at some code, can you trust what the function name implies is done, without concern? When something is complex in a relationship we pause to take time to communicate and come to a common understanding, we write notes to each other. When we have something complex in code do we write down information to help the other engineers work through it? In a lot of ways the way we relate to our peers through code is possibly a reflection of how we relate to others in life.

drooby 3y ago

boringuser2 3y ago

I'm terrible at reading code. I've analyzed myself in process and it's because I get bored and start glossing over details. In some cases, I feel this makes me a weaker engineer than my detail-oriented counterparts. In other cases, I connect concepts and problem solve better than they do because I am quite smart. The division of labor, I guess.

paseante 3y ago

ROFFFFFLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLL. OMG this is brilliant

patrec 3y ago

Why is this much more true of programmers than writers[1]? To what extent is it true of "proper" engineering disciplines? [1] A couple of people here doubt it being true. It is though, and I say that as someone who enjoys reading interesting code. A good case in point is this great, probing interview by Peter Seibel of Hal Abelson: https://gigamonkeys.com/code-quarterly/2011/hal-abelson/ https://gigamonkeys.com/code-quarterly/2011/hal-abelson/ Abelson: Read a lot of good code. That’s the real issue—that people don’t read code. [...] Seibel: I want to dig a little deeper on this. You, like many other people, say programmers should read code. Yet when I ask what code have you read for fun or edification, you—also like many other people—answer that you read students’ code, which is your job, and review code at Google, which is also your job. But it doesn’t sound like you sit down of an evening with a nice printout and read it. Abelson: Not for a long time. I can't imagine a professional writer answering like this.

fnordpiglet 3y ago

Only junior software engineers hate other peoples code. The progression of a skilled software engineer starts with writing code, then reading code, then writing code in the context of others code. The more you work the more crucial it is to be able to operate in a zone of non ownership in the code base, your value really unlocks when you can sniff code and improve it without rewriting it. At this stage 30y into my career I can step into a completely foreign code base and make material improvements quickly in situ, and sometimes have to do it several times a day. I don’t mind other peoples code - in fact I learn an awful lot of cool things spelunking! I tend to avoid the “let’s rewrite it” engineers - they’re usually going that route due to lack of practice and skill in developing software. There are times for sure a rewrite is necessary, but IMO it’s sort of like blaming the compiler for build errors. Usually it’s not the compiler, it’s you. But rarely there’s a compiler bug and you’re justified in asserting it as such. Likewise, rarely does code need to be rewritten, you are just unskilled at code surgery - so practice. When you have practiced enough you’ll see that the initial revulsion you felt at their code was mostly your brain reacting to the unknown. The people who wrote that code are often as good or better than you, and understood the domain a lot better if you’re new to the code base. Show a bit of respect for those who came before and learn to learn.

black_13 3y ago

[dead]

deleted 3y ago

[deleted]

vaughan 3y ago

It’s because you can only understand why things are structured the way they are, if you go on the journey from scratch yourself. It would probably be easier if there was a video or scrubber/slider to see how the code evolved. So many times you look at something and go: why is this so complex. Could be simpler. And you miss an edge case that causes the need for the complexity/abstraction. There are times too though that after a refactor someone can’t see some redundancy or is hanging onto an abstraction that looks great but is unnecessary.

gloosx 3y ago

I loved this article! In the end, it is exactly to the point: code adds and adds complexity; complexity we hate. At the same time, complexity comes from our flawed knowledge, and only true knowledge gained in battles shows us simple ways. Simple ways bring us joy.