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.<p>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.<p>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?!
> 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!<p>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.
I'm not so sure about software engineers. We often value <i>working</i> solutions even if the code base is not perfect. I certainly do and I very much agree with Joel Spolsky in his classic:<p>"<i>Things You Should Never Do, Part I</i><p>"They did it by making the <i>single worst strategic mistake</i> that any software company can make:<p>They decided to rewrite the code from scratch."<p>[1] (Emphasis his.)<p>Where I'm 100% sure is that consultants hate code. I've never ever seen one recommending the reuse of existing code - not once.<p>And it's understandable: They have nothing to gain from recommending reuse of existing code.<p>In the best case the code is good <i>and</i> 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.<p>On the other hand, if the old code is bad or anything else goes wrong everyone will blame the consultant for the recommendation.<p>For the consultant it's a risk-return tradeoff that just <i>always</i> favors a rewrite from scratch.<p>[1] <a href="https://www.joelonsoftware.com/2000/04/06/things-you-should-never-do-part-i/" rel="nofollow noreferrer">https://www.joelonsoftware.com/2000/04/06/things-you-should-...</a>
This is like writing “mechanics hate bolts”.<p>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.<p>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.<p>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.<p>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.<p>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.
> 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.<p>While the article resonates with me alot, I would like to, in the best spirit of the article, propose an addendum to that line:<p><i>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><p>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.<p>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.<p>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.
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.<p>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.<p>Then again, I work on infrastructure stuff. The kind of applications I work on <i>have</i> to exist for a long time because of internal contracts and dependencies. Maybe this piece is more aimed at product SWEs.
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.<p>What I hate is inconsistency. Inconsistency is what makes code intolerable to work with, because changing it becomes so much harder.<p>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.<p>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.<p>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.<p>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.
Sometimes, software engineers find abstractions that suit their mental model.<p>Sometimes, they even are able to create codes that match such abstractions.<p>Sometimes, those abstractions are now flawed.<p>Sometimes, those abstractions are properly tooled.<p>Sometimes, the rest of the team also understands those abstractions.<p>The conjonction of all these rarely happen.
I've been a software developer for almost 10 years and during that time I've questioned many times why I keep on going.<p>A while ago I realized that the biggest thing that I like about software development is the simplicity within it's complexity.<p>What I mean by this is; software either works or it doesn't. In many other professions this is not the case.<p>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.<p>So simple, but yet, so ruthless.
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.
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.<p>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.<p>When you look at some code, can you trust what the function name implies is done, without concern?<p>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.<p>When we have something complex in code do we write down information to help the other engineers work through it?<p>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.
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)<p>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.
Writing "unreadable code" is easy, just as too easy to make your room a mess.<p>Writing "readable code" is so damm hard.<p>Readable code leads to maintainable code, which reduces tech debts.<p>Alright, many engineers just knows how to fix the bug and call it a day. It's a disaster thinking.
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!<p>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.
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
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.<p>Of course 99% of everything is crap, and no one like to ingest crap.<p>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.<p>All that said, yes, there are great peaces of code that are a delight to contemplate.
sturgeon’s law applies. most of the time they are right to.<p>put another way, 90% of code is a liability, 10% of code is an asset.<p>i’m not sure any code ever moved from one group to the other, though good ideas may be stolen sans code.<p>greenfield is the only way to grow that 10%. it’s the reason startups exist.<p>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.
>Senior engineers hate extraneous code. They hate seeing time and effort invested in building yet another solution to an already-solved problem. [...]<p>>Don't write new code when you can use, improve or fix what already exists.<p>Caveat: Refusing to write new code often means pulling in and/or writing a whole bunch of extraneous code.<p>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.<p>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.<p>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?
Why is this much more true of programmers than writers[1]? To what extent is it true of "proper" engineering disciplines?<p>[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:<p><a href="https://gigamonkeys.com/code-quarterly/2011/hal-abelson/" rel="nofollow noreferrer">https://gigamonkeys.com/code-quarterly/2011/hal-abelson/</a><p><i>Abelson: Read a lot of good code. That’s the real issue—that people don’t read code.<p>[...]<p>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.<p>Abelson: Not for a long time.</i><p>I can't imagine a professional writer answering like this.
> we deprecate it as legacy and replace it with something new. Rolling green fields forever!<p>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."<p>You really do need someone with a grand plan to keep this in check.
The people who truly hate code work in upper management. Coders are expensive, hard to hire, and tend to say no a lot.<p>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)
It’s because you can only understand why things are structured the way they are, if you go on the journey from scratch yourself.<p>It would probably be easier if there was a video or scrubber/slider to see how the code evolved.<p>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.
> 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<p>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.
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
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.<p>code that is simple, documented and well written is best thing any developer can inherit.
I'm terrible at reading code.<p>I've analyzed myself in process and it's because I get bored and start glossing over details.<p>In some cases, I feel this makes me a weaker engineer than my detail-oriented counterparts.<p>In other cases, I connect concepts and problem solve better than they do because I am quite smart.<p>The division of labor, I guess.
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.
In this thread: Software engineers also love to point out when their counterexample has been glossed over by an intentionally simplistic thesis.<p>(In this comment: Software engineers also love to sass one another)
Software engineers do not hate code.<p>They hate when they're put in front of horrible code and they are disempowered to do anything about it.<p>Or they are forced to agree with people with learned helplessness.
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 <i>looks</i> impressive to an untrained eye. <i>That</i> type of code is guaranteed to turn a code base into a mess—all for the sake of someone's ego.<p>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.
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.
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.