Hacker News new | past | comments | ask | show | jobs | submit login

From my decade writing software professionally and my current job search, I really question the actual demand for clean code.

That’s unfortunate because it’s my specialty and what gives me job satisfaction.

I love fixing things. I actually enjoy working on a crappy codebase that has made the company money but is now too hard to maintain/extend and needs cleaning. Adding tests, refactoring, extracting functionality to discrete functions, figuring out what the black box actually does, etc. This is what I’ve specialized in.

However, it seems to me that companies don’t actually value that. They all say they do of course, while actually being afraid of doing this because it takes more time and money. Even if they’re mature enough that survival isn’t an immediate concern anymore, there is time to clean things up, and the mess is actually slowing them down through downtime, bugs, and not being able to ship relatively trivial features/updates in less than weeks.

I also suspect that not focusing on clean code is a strategy many managers have because they can show velocity to their higher ups and get promoted before it all blows up and they’re held responsible.

So what do you all think? Is clean code really actually valuable in the eyes of organizations or will they always take the quicker and dirtier option given the choice? Will I ever find work selling code cleaning (even to companies that ask for it) or should I “rebrand” on fast and cheap code at the expense of quality?




> They all say they do of course, while actually being afraid of doing this because it takes more time and money.

That is my experience too with most places - they say that they support clean, well tested and maintainable code and then turn around and ask things to be delivered in unreasonable time resulting in quick and dirty code.

> I also suspect that not focusing on clean code is a strategy many managers have because they can show velocity to their higher ups and get promoted before it all blows up and they’re held responsible.

Indeed - furthermore, because the code lacks quality, it requires more effort to manage and (intentionally or not) helps them to demand headcount which requires more managers which results in them building hierarchies, moving up and having their fiefdom. It is a smart approach too in a perverse sense: how will you get to a position managing 100 people if you only delivered with 5 people due to your efficiency? You'll be labeled as "lacks experience managing large orgs".


So… how do you deal with this on a personal level? How do you retain any shred of sanity or enjoyment from your work?

I can’t stand self inflicted toil and the stress from constant firefighting which is invariably the result of these short term policies. It makes me want to quit programming altogether and work in something totally unrelated even though I love programming. Just not the way employers want it.


One option is to work for a company where an important part of the product they make is code itself, e.g. an SDK. Another is to switch to a programming language that tends to attract quality-minded people, e.g Rust, Go, Haskell.


One is very different from the others.

The one whose designer said “ They’re not capable of understanding a brilliant language“


Ha, well I’d agree with you on that, but even so I’ve seen Go mostly adopted by people who are capable and care.


What you described reflects that corporate structure and might be industry wide. They look at code as only valuable in the monetary return it makes. They might even consider it a cost center. That will always be a less than pleasant place to work in an organization.

So find places and maybe start at industries that consider their code an asset or profit center.

It’s ultimately just a valuation perspective, but understand to a business everything has a market context or business case. It’s can be infuriating, but better to know the system than blindly suffer through it.


You switch jobs. Of course, there are managers everywhere and of course generally they have similar motivations. However, every once in a while you get one who was a developer-at-heart once (or still is) and does give some amount of shit even when they are looking for their usual goals. If that person doesn't happen to be evil, you stick with that team until things change (maybe the manager moves on). The good thing is that when good managers move, they tend to take the good and trusted ones with them to the new place. Assuming they saw your efforts and value your skills, you can move with them. Alternatively, if they are not the type to do so/you can't move with them, switch again. Either way, side effect is that your pay goes up too due to the switching - just don't do it too frequently.


You stand up and talk about it publicly.


Who listens, though? Look at seminal work like “the mythical man month”… while most people “in the trenches” agree that nine women can’t make a baby in one month, project managers and executives still very much think it’s possible 40 years later.


You can explain it to them, but you can't understand it for them..


The issue is, managers want these things, like a nice code base, but are unwilling to pay for it. Or more correctly you have to pay most of the cost of that Hodge podge of hacks. So while they can off load that cost to you, why would they make an effort to improve the situation?


So what do we do? Working this way drives me crazy, depressed, and unhappy; I don’t want to do it anymore.

I don’t want to be part of the problem either by becoming one such manager so that others will have to pay the cost of my benefit.

What’s left? Opt out, live on shoestring budget for the rest of your life, and hope it works out?


There are thousands of software engineering jobs out there, how many have you tried? A handful? Increase your sample size.


And you're the first to be let go. The squeaky wheel that irks the bosses.


Maybe. It is their loss.


I think you can easily roll an analogy with having a plan documented on 5 napkins, bits sprinkled over 127 emails, a few doodles on a white board, 93 photos on your phone, some files in some folder and 20% in your head.

You could start execution right away! Every bit of information is readily available, sure, the numbers in those emails might change in the process but you can just document those changes on additional napkins.

But there is a stage 2 to the plan that needs to happen in 3 to 6 years. By then there will be tens of thousands of relevant emails, hundreds of napkins, you cant find the original photos and you have so much related information in your head that that important thought is buried much like the email... I'm sure I have a folder someplace on this computer.... where is the chat log?

You made promotion so stage 2 is left to the new hire. They had a wonderful resume but for some reason it takes him forever to progress. They wont argue it would have been nice if you wrote down what stage 2 involved years ago. In stead they ask for 20 more people to organize the data.


That makes sense. But how do you retain your sanity and job satisfaction if you’re not an early part of that first phase?


I suppose you could keep your eyes more on what you've done rather than what needs to be done?


I get the exact same joys from work. Taking an old but functional and profitable codebase and cleaning it up, bringing it up to conventions and standards, refactoring. At my current job, feature work is always a thing, but I make refactoring boards and get people on board with bringing in refactor tickets every sprint, etc.

So while not 100% of my job is refactoring, a large portion is. And sometimes I convince them it’s time to rewrite one entire section or another, so a couple of sprints at a time might be dedicated to just that.

I guess I’ve gotten lucky, probably a combination of that and being outspoken about what needs to be fixed.


> So what do you all think? Is clean code really actually valuable in the eyes of organizations or will they always take the quicker and dirtier option given the choice? Will I ever find work selling code cleaning (even to companies that ask for it) or should I “rebrand” on fast and cheap code at the expense of quality?

There's many sides to this.

Even Boeing doesn't value clean code (as shown by the 737 MAX disaster where 9$/h coders were hired in India). So you can imagine how much a local non-tech company values clean code.

There's also that a lot of these companies simply... couldn't recognize clean code even if they saw it! Since they aren't competitive with top players, the caliber of programmers they attract is nowhere near the level of engineers at real tech companies. Unless these companies "luck out" with an extremely high caliber hire, they won't really know there's a better way of doing things [0]. Think places where source control is still seen as too complicated or not needed.

[0] https://www.hanselman.com/blog/dark-matter-developers-the-un...


It would be prudent to include some data to substantiate your insinuation that some non white non European programmers did the Boeing MCAS code. The 9$ per hour wage maybe less than that of a burger flipper in the USA, but the cost of living is vastly different.Being an engineer , if you are ignoring this significant parameter then we definitely know one source of the issue .Maybe you are not an engineer but a fine arts major who “learned” coding by yourself.



https://news.ycombinator.com/item?id=20353342#20355864 . Hope this link works . This discussion was 2 years ago.

Still my word holds good . Boeing management didn’t give crap about engineers opinion be it 30$ per hour or 5$ per hour.


Boeing asserted that no "critical flight software" was outsourced, but it specifically didn't label the MCAS as "critical flight software" when describing it to the FAA.

What we know was outsourced is "flight test software" which sounds a lot like something that should have caught the 737 MAX failure...


I think as professionals many of us like to take pride in our work. A natural way to do that is for code to be "clean". The problem, as I see it, is that this is often a subjective metric and what we take pride in doesn't always align with what delivers tangible value to an organization (a point you alluded to).

Clean code can bring tangible value, but big rewrites taken on for that goal can often not. I personally try to be more pragmatic--what is valuable depends a lot on context and the point in life of a particular project+team+organization.

Sometimes the most valuable thing is to ship a messy code that works to get the ball rolling or prove viability of an approach. Other times it's to make sure what you deploy is bullet proof to avoid liability or expensive downtime. The value of clean code will be reflected by your team and organization's needs at that point in time.


> what is valuable depends a lot on context and the point in life of a particular project+team+organization.

For sure, and I only target companies or teams that are mature, struggle to move forward because code quality grinds things down to a halt, and that express the desire for improvement there.

However, there are very few companies that 1. Even have the awareness to realize this is where they’re at, and 2. Actually mean it. I’ve been passed over many times in favour of someone else who ships code quickly and cheaply by lowering quality. Every place I’ve ever worked at, quality is the least concern in relation to the others.

Now for a startup that has limited runway and has to find product market fit for example then it’s totally different. Focus rightly is on shipping stuff at the expense of quality because survival is on the line. In a few years, once this company has made it, they’ll look for someone to clean their codebase up.

My broader question though is whether I should keep branding myself as a “code cleaner”. Despite a (minority) of companies advertising positions for that skill, my experience has been that the vast majority simply don’t care. And those that do, don’t actually care all that much. It’s a struggle though because I get no satisfaction from shipping low quality code and eventually end up quitting out of boredom or frustration. I’m now at a point where I’m considering doing something entirely different from programming because I can’t derive any job satisfaction from writing low quality code and the resulting constant firefighting that results from it.


Any organisation with messy code doesn’t care about clean code - sure, they may regret it, they may wish it would magically go away, but if they cared then they wouldn’t have allowed all the dirty code to pile up. The only organisation in which your work will be valued is one in which the code is already clean.


Interesting insight.

I’ve never come across such an organization though. There are a handful that I think are in this spot where quality has mattered since day one but they’re so popular that I don’t stand a chance to even get noticed when applying in a sea of thousands of applicants. They also don’t hire very often.

And they’re very hard to find because what do you even search for? The ones I know, I found empirically through word of mouth, reputation, or just plain randomness by stumbling upon.


Of course the people signing the checks don't care about that directly, but it's something you can do as you add functionality.


That’s my understanding as well, quality for the sake of it isn’t appealing.

But it is known that a quality foundation enables everything in the business, reduces waste, churn, and increases profits.

Yet when it comes down to actually doing it, nobody cares. Fast and cheap always wins over quality.

That’s not necessarily a problem overall, but it is for me because I derive no satisfaction from shipping low quality code and the constant firefighting that results.

This is a struggle because it’s the vast majority of the demand for software, which makes me want to quit the industry altogether even though I love programming and improving “legacy” codebase. But there seem to be no actual demand for this skill despite the appearances.


Think of it this way. Imagine you hire an electrician to do some task. If while he's there he cleans up some stuff around where he was working, that's welcome. If he starts rewiring your whole house for no particular reason, even though everything was working fine, and billing you by the hour, you might not be pleased.


Absolutely but this isn’t the situation I’m talking about here.

To reuse your analogy, I’m talking about a restaurant who has a mess of an installation, several panels and breakers, not all up to code, and the electricity frequently shuts off taking hours to figure what happened and how to restore it. It’s also a mild fire hazard and there have been a few close calls that could have burned the place down.

The son in law, a hobbyist electrician, did the installation and extended it for free while the business was starting up and growing. He didn’t do it right but it works and got the restaurant so far.

Now the restaurant is very popular but the constant blackouts are driving people away and hurting profits. The mild fire hazard and not following code irks the authorities and insurance companies and they’re threatening closure. It needs an extra stove to keep up with customer demand but no one can figure out how to hook one up to the existing rats nest, let alone do it safely.

The owner knows this is a problem and is looking for a proper electrician to fix the mess.

In real life, I’d expect the business owner to agree with the electrician on a plan so that either the retaurant stays open (maybe at a lower capacity) so that the tidying up can happen gradually, or close down for renovations for a while so the whole thing can be overhauled quicker.

But what happens in our industry and in my experience is that instead the restuarant owner asks the electrician to tighten a screw or two here and there so that this power socket isn’t as wobbly anymore but then demands even more additions to the janky system and demands they be done as fast and cheap as possible as this is now the top and only priority.

Nothing really improves but the owner (at least for a while) can hide it from the authorities and insurance company because he has a quote and a specialist working on the system. Then the owner can blame the electrician because “he wasn’t able to balance fixing up the installation while extending it, so we’ll fire him and look for someone actually good this time”. Rinse and repeat ad nauseam.


Well, to put it another way, "clean code" can be the means of achieving an end, but if you tell them you're replacing existing code with clean code that sounds like a waste of time. You should be able to describe some concrete goal you are working towards and they should leave it to you to worry about how you do it.


> I love fixing things. I actually enjoy working on a crappy codebase that has made the company money but is now too hard to maintain/extend and needs cleaning. Adding tests, refactoring, extracting functionality to discrete functions, figuring out what the black box actually does, etc. This is what I’ve specialized in.

I am thankful that people like you exist, but after having taken on that role out of necessity myself, I've mostly been left disliking the experience.

Working withing under-documented and under-tested "legacy" codebases, especially the kind where the developers got clever with design patterns, both putting them in when they make sense as well as when they didn't. Those codebases are hard to navigate and hard to refactor (outside of fully automatic renaming/extracting interfaces etc.) and even harder to change - in many cases because you're not even aware of the design assumptions or aspects of the architecture that were made by someone who is now long gone.

For example, I worked on a system where users could submit corrections to data and those could either be accepted or removed. There was a CorrectionFormService, that also was related to CorrectionEntryService, but both of those were abstract and had corresponding CorrectionFooFormService and CorrectionFooEntryService instances, as well as an additional CorrectionFooService. In the database, there also were foos and foos_corrections tables, the latter of which was related to correction_forms, sometimes with additional related tables. The problem was that the logic didn't actually fit such neat structure, so depending on whether you're working with Foo, Bar or Baz, more and more of the methods had to be overriden, as well as new ones added, none of which was actually documented. In most cases you were supposed to have the original_id column point at the foos (or whatever) table id that had the actual data, except when for some reason original_id was the same as id and instead you had something like object_id store that information. And on top of that, there were database views which were used for querying the data, where there were additional rules for the id, original_id and object_id column values, with about 10 prior Jira/Redmine issues related to how this data should work. Not only that, but there were also requirements for accepting some of the data recursively (since parent_id was needed for some of the data structures), but not in all of the cases, only when some other enum column had a particular value in a related table.

Long story short, the more you looked into it, the more details spilled out, to the point where you could not keep a full mental picture of it in mind. Some of the implementation was okay, some of it was ridden with iteration overhead and accidental complexity. Contrast getting to write new code and getting things done in hours, versus spending days if not weeks (across multiple developers, actually) working to get things done within this pre-existing setup. Maintenance work will typically take longer than developing new features and, in my personal experience, will be more mentally draining.


I find that you can’t always fix everything. But the biggest hurdle is actually getting buy in (even if there is already buy in and that’s what you were specifically hired to do)

Rewriting is tricky. It’s sometimes necessary (outdated and unmaintained language, obscure tech you can’t find people for, or sheer tech bankruptcy) but it can also not solve anything. As you implement the new version, you rediscover all the arcane business rules, edge cases, and sheer craziness that you didn’t know about and the rewrite ends up either lacking these or becomes The Mess v2 because you had to bolt all this weirdness on after the fact making the new codebase suck in a different way but overall as problematic as the one it replaced.

It will also take much longer than estimated for the same reasons.

I’m not super keen on rewrites in most cases.


> As you implement the new version, you rediscover all the arcane business rules, edge cases, and sheer craziness that you didn’t know about and the rewrite ends up either lacking these or becomes The Mess v2 because you had to bolt all this weirdness on after the fact making the new codebase suck in a different way but overall as problematic as the one it replaced.

Sometimes I wish we could just look at an implementation that's meant to serve a business process and go: "Listen, we gave it a shot, but the technology and developers we have available cannot provide a satisfactory implementation for this, without making the entire thing a liability. Can we simplify the domain instead?"

I've actually tried this in the past (in a more mild form) and it has actually worked - sometimes getting a paragraph or two of changes approved in a 50 page spec can save you weeks of work ahead of time, which you'd otherwise spend because someone didn't realize which parts of the spec are technically unfeasible.

Sometimes it's actually easy to reason about, such as when you're doing a rewrite from AngularJS or something else that's deprecated to something more modern, and can suggest a few simplifications to "prioritize quicker iteration, shipping core features quickly and simplified UX for less friction", which might mean simpler components.

Or you might find yourself in an inflexible domain, having to replicate "the old thing" close to 1:1 which will take way more time than either writing or maintaining it would. There, rewrites don't make that much sense. At that point, if you need more modern elements (runtimes, libraries, frameworks), I'm not even sure what you could feasibly do, aside from setting up a new service and rewriting paths for particular new API endpoints to the less rotten codebase, but that has challenges of its own and can get out of hand.


> Can we simplify the domain instead?"

I can see this working in more mature and healthier orgs, but they’re a minority. As cynical as it sounds, most orgs are dysfunctional meat grinders where you’d get attacked for not having the skills to pull it off, in my experience.

Nobody brings this up for that reason and the madness continues unabated, ensuring the project becomes a slog over the medium/long term with the expectation that most will have moved on before it gets there.

This is also how we run our societies, leaving problems for later so that the next guy/president/generation has to deal with it at the point where it’s impossible to ignore anymore. Instead of much earlier when it requires much less effort and is reversible.




Consider applying for YC's Spring batch! Applications are open till Feb 11.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: