11 ms·

Nobody cares about your clean code

180 points by felipe_csl 5y ago

rahulpadalkar 5y ago
This should have been titled "Users don't care about your clean code". But it's 2021, click-bait is necessary. Also this is the difference between a indiehacker and a SDE. Pieter is a indiehacker not a SDE.
tpoacher 5y ago
Corollary: Nobody cares about the materials you used for the spaceship. (Unless it explodes mid-air, that is. Please don't explode mid-air. Please don't explode mid-air. Please don't explode mid-air ...)
dosethree 5y ago
Code has to be clean enough. The penalty for dirty code can be quite steep, or none at all. Never let perfect be the enemy of good.
taylodl 5y ago
> "Often I see developers that seem to care more about writing clean and beautiful code just for the sake of it, completely forgetting the bigger picture, why they are doing it." Here's what I've learned over the past 35 years developing software: I typically don't care much about implementation. There are many ways to skin a cat and it's not very productive to argue amongst them. Whatever. What is important however are interfaces. Function interfaces, class interfaces, subsystem interfaces (mediator design pattern). Factory methods are also extremely important: how do I get an instance of the thing I need? These are the things that are important. How a piece of functionality is actually implemented is far down on the list of things to care about.
mindcrash 5y ago
If "nobody" cares you obviously never talked to someone running ops in your team, ever. Or the CFO when he hears about that little nasty bug hidden away in a gigantic ball of mud (https://en.wikipedia.org/wiki/Big_ball_of_mud https://en.wikipedia.org/wiki/Big_ball_of_mud) halting production over the SLA thresholds causing a massive financial issue. Customers likely don't give a shit about code, but it can and probably will eventually run your org into the ground.
james_smith_007 5y ago
Bullshit
kgilpin 5y ago
What are the odds this is a single developer code base? It’s ok to have a mess, when it’s your mess. It’s other people’s messes that are the problem.
whoomp12342 5y ago
yarp. we dont love clean code for the user, that should be obvious for anyone who has written a medium amount of code. we love clean code for the fact that some day, we are going to have to read our code, trace it for a bug... etc. You can feature bloat something up to a certain point and then.... kaboom goes the rewrite. Hopefully into clean code, but usually not since clean code is a culture and mindset, not a code base.
- aae42 5y ago
  yea, but isn't the obvious logical conclusion that clean code allows you to more easily and more quickly do things that the customers do want? this is like telling a mechanic that people don't want them to maintain their cars, they just want a reliable car that won't leave them stranded also, why does a php and jquery app mean it isn't clean? the better takeaway is that customers don't care about your stack
  - mannykannot 5y ago
    It's not quite that simple: it is not unusual for an overall-clean solution in response to new requirements to require refactoring the existing codebase, even if that is a clean and minimal solution for the requirements up to that point. Even if you had anticipated that these additional requirements were likely, preparing in advance for their possibility would often mean over-engineering for the initial requirements, which would likely delay the initial release. If there wasn't a genuine conflict of interests here, we would not still be wrestling with it.
    - loopz 5y ago
      The problem with over-engineering is also that it makes other refactoring harder at later stages, or just discourages change. Some degree of shittiness actually improves agility, and encourages change.
      - whoomp12342 5y ago
        Amen, I have been guilty of this as well. It is a hard line to walk between over engineering and future proofing something.
volume 5y ago
There's a DevOps Cafe episode, I forget which topic, but the idea was that users just want DNS to work. Nobody cares how clean your config files are for Bind. But indirectly they actually do care because if the config files for Bind are maintained well then there's less room for human error and ... that contributes to overall stability of the service.
p1necone 5y ago
Even if you are just talking about clean code for your own satisfaction whether or not a single PHP file is "clean" or not (to me) depends heavily on the complexity of the application. If your service only needs 50 lines of business logic, a single PHP file probably would be easier to understand and maintain than modularizing it. (I have no idea how many lines of code remoteok needs).
908B64B197 5y ago
It's true that users want software that works and they don't care about the code... ... But, code quality if a pretty good heuristic for "does it work". It's possible to write a working program where the code isn't clean but as the program grows and grows you'll have more and more trouble keeping it working. In the case of remoteok.io, it's not really a surprise. It's a complete website but not a very complicated one. Post data, view posted data. Everything public. Mostly read traffic so trivial to cache.
xyzzy_plugh 5y ago
"throw the first one away" When I'm prototyping or hacking something together, I don't write tests, I don't comment/document much, I use lots of shitty variable/type names, lots of commented out code, debugging printfs, not much organization of files (often one large file). The prototype software is write-once, read-maybe. Maybe I'll want to see what I did down the road, but more likely I'll be shortly rewriting what I did somewhere else, using the fresh state still in my head. That next thing? If it's meaningful in any way and I want other humans (or future me) to expose their sight-orbs to it, then it'll be "clean code" to the best of my ability. While users won't care what your code looks like, they DO care about bugs, new feature turnaround, and downtime, all of which are exasperated by shitty code. You don't want to be staying up late on the weekend unfucking something you fucked up three years ago. Don't write shitty code for other people. That includes future-you.
- bartimus 5y ago
  Then also the core parts (with many dependents) deserve more elegance and readability compared to some less critical side module that can easily be thrown away and replaced.
- StavrosK 5y ago
  When I'm prototyping or hacking something together, it eventually becomes production. I cannot relate to people who make prototypes to throw away, I've never done it, and I don't know why I'd do it. Due to that, I write my first line of code as if it's going to be on production forever, because it will.
  - deepGem 5y ago
    I have done quite a lot of prototypes and while the initial ones were throw away code, I quickly realized that I can re-use a lot of code in future prototypes. Especially code that involves building user management and database access. Also realized it is frustrating to write repeating code. So I quickly started making code slightly more readable and reusable. It's not the holy grail of software development but it ain't shitty code either. Also I tend to use only one web framework - FastAPI, one database - mostly Redis or MySQL and one front end React. Saves a ton of time as I can reuse a most parts of the code. I do think there is a lot of merit in using something like GAE. Saves a boat load of time but comes at a cost and I am willing to bear the cost to save time.
deleted 5y ago
[deleted]
lostdog 5y ago
Nobody cares about what materials you used in your bridge! https://www.courthousenews.com/34m-settlement-reached-for-defective-work-on-bay-bridge/ https://www.courthousenews.com/34m-settlement-reached-for-de... But seriously, they call it "tech debt" for a reason. It's not a problem until suddenly you're no longer able to add needed features to your project, because every little bit of development takes hours and weeks and months. There are so many posts about how "Engineers Need To Learn About The Business," and yeah, it's helpful sometimes, but really there are different types of jobs. Some jobs require the engineers to understand the product and business rules, and other jobs need engineers with deep technical engineering abilities. There's nothing inherently better or worse about either! What's bad is if the job is one type and you are the other type. (Similarly, you think you want to be one type, but really you want to be the other type). So go ahead! Fiddle with an esoteric language or framework, because there are plenty of open positions that need you.
- cratermoon 5y ago
  Except that technical debt is not about writing bad code, and the author of this article gets it completely wrong. "The metaphor of debt is sometimes used to justify neglecting internal quality... Teams who do this end up maxing out all their credit cards, but still delivering later than they would have done had they put the effort into higher internal quality."[1] "the whole debt metaphor, let's say, the ability to pay back debt, and make the debt metaphor work for your advantage depends upon your writing code that is clean enough to be able to refactor as you come to understand your problem"[2] "write the best code possible given a partial understanding of the problem so later when you do understand it better you improve the solution"[3] 1. https://martinfowler.com/bliki/TechnicalDebt.html https://martinfowler.com/bliki/TechnicalDebt.html 2. http://wiki.c2.com/?WardExplainsDebtMetaphor http://wiki.c2.com/?WardExplainsDebtMetaphor 3. https://www.youtube.com/watch?v=pqeJFYwnkjE https://www.youtube.com/watch?v=pqeJFYwnkjE
notacoward 5y ago
John F. Woods (who I actually knew IRL briefly - nicer guy than his online reputation suggests) said it best. "Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live." I'll just add that the psychopath in question might be your own future self.
- Xunjin 5y ago
  Oh boy... I believe I'm this kind of psycho, when I see my name in a git blame after tracing a bug that I didn't foresee... I feel awful, disgusted, then I fix it and think "You sure are dumbass, now try to be a lesser one".
  - paulmd 5y ago
    this is always fun with git-bisect because if you can reliably reproduce the bug it will always leads you exactly to the commit that caused the problem. Nothing worse than tracing for a half hour and... it spits out your name.
    - Xunjin 5y ago
      Holy Molly, learned about git bisect, ty paulmd. HN comments amazes me, I always learn a thing or two.
  - enw 5y ago
    And the relief when you see your name is nowhere near the defect.
    - Xunjin 5y ago
      Yes!
routerl 5y ago
Weird post. The main insight is easily captured by the phrase "technical debt is a resource, not a vice". It also disregards that developers who care about clean code do exist, such that the title becomes merely metaphorical, and is more accurately rendered as "users don't care about clean code". Except that they do, they just don't know it. Time to new features and time to bug fixes (both of which users do care about (though, of course, not unanimously)) is inversely proportional to how easy a codebase is to navigate and understand (read: how clean it is). Finally, all software developers (or all workers?) prefer their work to have a high ratio of accomplishment to drudgery. The primary benefit of clean code is developer quality of life, as indicated by the nascent field of DX (Developer Experience).
- dosethree 5y ago
  Technical debt not only makes it harder to add features, it makes it harder to remove technical debt and make technical improvements. Choosing not to pay down technical debt is fine, but at some point it will be such a mess you won't be able add features or fix the technical debt issues without a total rewrite scale project.
- hinkley 5y ago
  Money is a resource too, but rock stars tend to turn it into a vice.
zelon88 5y ago
I think it's ironic that the author claims that clean code is....... Package your code down into small, atomic and reusable units Follow the single responsibility principle Use frameworks and libraries to avoid reinventing the wheel Whatever language you pick, don’t pick PHP These are best practices. It is possible to follow every one of those rules and still have a pile of broken, insecure, garbage code. Likewise you can have a very elegant one-liner that fits none of those and gets a job done cleaner and easier than any alternative. You can even have a single page app that fits most of those, and I would argue that it would probably stay cleaner without adding a framework. Frameworks in many ways bind you to a certain style. It's all about keeping the scope of what you're doing in mind and using the correct tool for the job. Saying "this tool is better for every job" is going to get you a lot of arguments. Also, with the exception of the third bullet point, you can follow all of those practices and still fit your app into a single file. There is nothing more frustrating than working on a codebase that puts 12 lines of code in each file and then spreads that code into 1,000 files. And the final bullet point in regards to PHP is just false. But I digress.
- tmaly 5y ago
  This gave me a thought just now. When future changes are needed to a piece of software, these are usually driven by the business side. If the original developers have moved on, and the current developers do not have a good handle on the software, there could be some troubles making changes. What if we approach the problem by structuring the code and choosing names to better reflect the business terminology. Make it such that a business person could understand the software at high level. Then years later, it becomes much easier for a new set of developers work with the business side to make enhancements and changes.
- userbinator 5y ago
  That's partly the reason why the term "best practice" has become a bit controversial in some communities --- it's seen as mindless dogmatic cargo-culting. I've heard the saying "best practices are best not practiced" from the opposition. There is nothing more frustrating than working on a codebase that puts 12 lines of code in each file and then spreads that code into 1,000 files. In other words, "Enterprise" code, which is in my experience usually designed more to hit all the "best practices", and often according to the opinion of some idiotic tool (as in computer program, although sometimes a person too...), than do anything sanely.
young_unixer 5y ago
The fatal flaw of this article is assuming that having a single PHP file implies ugly code, or at least uglier than the average codebase. I would, in fact, guess that its code is much cleaner than the average Fullstack Javascript app. If you're capable of writing a full, functional website in one PHP file, you know what every line of code does, you have only what you need and the ways to factor your code become more obvious. Using the "modern" Javascript stack usually means that you had to spend months or years trying to learn this mishmash of Javascript libraries (React, react-redux, Express, an auth library, an ORM, etc.) and you don't know what most of those things do under the hood. The lesson I take away is: Simple (PHP + Jquery) can be better than complex (React, Redux, Express, Passport, etc).
- dosethree 5y ago
  I've spent some time trying to pick up modern JS tooling. I used to code JS back in the early days of JS and stopped around the time Backbone JS stopped being used The learning curve right now in JS is ridiculous. Onboarding developers is hard. We wrote a new project in ember js and threw it away for react. Sometimes new tools, like Ruby on Rails, make it way easier to get started. Not so with JS. But I'm sure you get a lot of dynamic rendering power to make up for it
- PurpleFoxy 5y ago
  If learning a couple of basic tools like an ORM and JS build tools is too much of a barrier, you probably shouldn’t be let anywhere near a database with real users data in it. PHP is too easy to get started with and let’s you do some truely horrific things trivially.
brlewis 5y ago
tl;dr Here's a web site that made a lot of money despite being a single file of code that we presume is ugly. From this we conclude that one must choose between writing clean code and focusing on what the user wants. (In case it isn't obvious, I disagree. Maintainable code lets you adapt to an evolving understanding of what the user wants.)
sidcool 5y ago
Clean code is not meant for end users.
LinusPrime 5y ago
Under capitalism, the conditions and means of how products are produced are made irrelevant. Sad.
joshsyn 5y ago
I do what I think is best for myself. You do what you think is best. Obviously won't employ author though.
ViVr 5y ago
This article seems to focus on clean code not having a significant effect on the software in production for the experience of the end user. One example where I have experienced the benefits of a clean codebase is when onboarding new developers. It takes a few days of handholding but once they've started working with the code there's very little room for gotcha situations where they get stuck or inadvertently introduce bugs due to being misdirected by the code that was already there.
cutler 5y ago
Remoteok.io is a refreshing **ck you to all the over-engineered barely-more-than-static sites rigged-up with the latest version React hook form packaged up in Docker ready to be deployed on Kubernetes. People, we need a movement which embodies this sentiment.
- RandyRanderson 5y ago
  A "eat more blueberries diet" will always be more popular than a "eat less" one b/c with the form you'll have farmers, super markets, etc behind you. With the latter, the message will be don't go to the store and buy something - not 'sale sustaining' (yes that was an awesome pun).
gumby 5y ago
If you can do a single page app with no frameworks you definitely should do so! If you have a large complex system, making it clean up front (i.e. by deployment) means someone a few years from now will appreciate the work. As for the single page app: when (if!) you want to upgrade it, just rewrite it wholesale. Until then it's creating value as it is.
altitudinous 5y ago
This is very true. END USERS in particular do not give a rats about clean code or the number of code reviews that have been done. They only care that it works. Technical debt, refactoring, reuse? Nobody cares except developers. The paying customer is all that matters.
- ewmiller 5y ago
  The paying customer cares when your tech debt becomes so burdensome that you can no longer deliver features (or fix bugs) on the timeline they want.
atum47 5y ago
I really don't get all the hate towards php, I'm about to put my old blog online and it's written in php. It's a cool language.
- PurpleFoxy 5y ago
  It’s because it makes no effort to prevent people doing insanely insecure things. Rails has a lot of safeguards for insecure things like using user input to update a record. PHP won’t even fix bugs due to backwards compatibility. They worked out their sql string escape function didn’t escape properly but instead of fixing it and telling everyone to check their code, they duplicated the function and prefixed the name with “real_”.
  - EugeneOZ 5y ago
    Rails is not a language. PHP maintainers do fix bugs. I don't use PHP right now, it's not my favorite language, but I hate when people are trying to excuse their own laziness and incompetence by saying “it’s all because of tool X”.
    - SilverRed 5y ago
      Rails and ActiveSupport are a huge extension to Ruby and are bigger than the non Rails Ruby usage. If you read the average PHP tutorial, it starts you out connecting to a db, running raw sql and rendering templates in the same file. An absolutely horrible idea. If you start on the default rails tutorial, you gets set up with a decently safe configuration.
      - flukus 5y ago
        > An absolutely horrible idea It's not a horrible idea, it's the simplest and easiest way to solve simple problems. Bringing in rails and all it's abstractions for something you can do in a single php (or ruby BTW) file is insane.
        5y ago
JediPig 5y ago
very true, i know a system written in django 1.x and the site makes billions a year. the code? complete utter crap. Written by a person that read a book on how to write a website. It still makes billion a year.
ZephyrBlu 5y ago
This is a false equivalency. Pieter does not run a hypergrowth startup. His businesses are completely different to AirBnB and Stripe. He does this because he's the only person who works on the codebase and because it generates a lot of attention due to how polarizing this choice is. I'd also argue that messy code is the product of hypergrowth, rather than messy code being required for hypergrowth. Purposefully writing shit code because you're "moving fast and breaking things" seems like a dumb idea.
- felipe_csl 5y ago
  Agreed! Thanks for pointing out my logical fallacies.
asdfsfkwqe 5y ago
But your teammate and the future self will
hinkley 5y ago
Nobody cares about your excuses for writing godawful code either. Call it a draw.
moocow01 5y ago
In the medium to even sometimes short term, clean code IS what allows you to ship features to users quickly and efficiently.
hn_throwaway_99 5y ago
If you are a single developer, sure, knock yourself out, and stick everything in a single file. If you actually ever plan on ever having other developers contribute to and maintain your code, or god forbid multiple teams of developers, you better have things structured in a way that they can understand.
- kevin_thibedeau 5y ago
  I had to dig into a niche TLS library a few months ago and was aghast at the 50000 line source files with massive God functions all over the place. I don't know how it ever was allowed to get that fubared or how they maintain it all.
  - paulmd 5y ago
    SSL/TLS are godawful messes of standards, they are insanely complex to implement which is part of why they have had so many bugs turn up in recent years.
livinginfear 5y ago
Silly premise. There's plenty of open-source products out there that will attest to the fact that the quality of a codebase has no effect on its overall commercial viability. The adage "Move Fast and Break Things" is a cancer on the software industry. I've personally had the displeasure of working in numerous teams, departments and companies that adopted such silly philosophies in the pursuit of being "innovative". I've never seen it work in the long-term in a single instance. The cost of such mistakes are easily quantifiable. I'm sure most people here can think of fitting personal anecdotes where they've seen entire codebases rewritten to make them into scalable, maintainable solutions. Even this article lists several examples which attest to this. I shudder to think of the amount of money that has been invested in migrating codebases away from NodeJS, or MongoDB, for instance. > "...or grow in a steady, sustainable and healthy pace and be eaten up by competition..." Implying that it takes an order of magnitude more time to make responsible technology choices, or to write tests? This is rubbish. A stitch in time saves nine. I've never seen an instance where better management, better planning, and more responsible development couldn't have prevented a project from needing to be rewritten in twelve months.
- galangalalgol 5y ago
  Rewrites aren't the worst thing ever. Sometimes writing it twice takes less time than getting it correct the first time.
presentation 5y ago
Users don’t care about clean code, but I do find that the more I try to write clean code the faster I get at writing clean code.
Olumde 5y ago
Dirty code will work until it becomes an unwieldy mess that is almost impossible to debug or improve. Then the competition will eat your lunch.
axiosgunnar 5y ago
Keep in mind that the website in question seems to be a two-page CRUD website with no moving UI elements (save for opening and closing panels) that probably has not changed much in the last months save for some CSS edits. How that in any way compares to a full blown application-in-browser like eg Figma or an infrastructure product like Stripe or a household brand marketplace like Airbnb that have to cater to various user groups, iterate at breakneck speeds and keep a triple/quadruple 9 uptime is beyond me.
auslegung 5y ago
> eventually you reach a point where maintaining that large (usually monolithic) codebase becomes so unbearable, so hazardous that you have to stop and rethink the entire design This assumes that your app will grow indefinitely. What if we had more apps that were considered finished?
jollybean 5y ago
Yes, definitely iterate and throw away at the start, and understand that clean code has quite a cost, but obviously strive to understand when it's worth it. Hidden value of clean code: Developer's sanity and willingnses to work on it. Code has the 'Broken Windows' problem: if it's a pile of dirt, people will treat it like a pile of dirt, and not want to work on it. If it's clean, their their work will have legacy, they're more likely to value their own time and effort.
deleted 5y ago
[deleted]
tomlagier 5y ago
Obligatory: Not every company is in "that category" (hyperscale startups trying to churn out their MVP). Some places where clean code really matters: - The personal project where, if you can't figure out how you did something, you'll quickly get bored and quit. - The open source project that needs to onboard hundreds or thousands of developers across language barriers in order to successfully solve problems. - The medium-to-large startup or enterprise that needs to maintain velocity on a product line. - The small startup that never quite hit hyper growth and needs to retain developers. - ... many more If you're trying to get rich quick, or quickly iterate through many different, dissimilar ideas, then writing sloppy code is fine. I'd argue that that's _not_ most codebases (though perhaps it is in the entrepreneur community).
nixpulvis 5y ago
Mountains on molehills. Glaciers melting in the harsh sun. All we do is subject to the fate of our ancestors. Brilliant is the one.
simplify 5y ago
I care about my clean code. Nearly every line of code I write is "clean", because it affects the bottom line. Messy codebases and bad architecture quadratically drive up the cost of development time. I've experienced this countless times for over 10 years, and it's endlessly frustrating. The state of web has gotten so tirelessly messy, I had to write my own framework to return to the clean web architecture we once had. And my clients love it, even if they're not directly aware of it, because everything takes less time (and therefore less cost) to build.
- dehrmann 5y ago
  It's a lot easier to swap out contains() for startsWith() at code review time than investigate some obscure bug that only affects a handful of requests 3 years later.
rapfaria 5y ago
"Users couldn't care less about the programming language you used", and yet the author is so protective of his work that I can't copy paste this phrase. Unhappy user right here. We code for ourselves. We deliver value to the costumer. Two different things.
- felipe_csl 5y ago
  The inability to copy/paste was actually an oversight on my part, will fix. Thanks for pointing it out, not even sure why that's the case right now :)
  - felipe_csl 5y ago
    Fixed!
- flukus 5y ago
  > Unhappy user right here. I'm more pissed off that my user agent (firefox) even allows this sort of control by third parties.
typon 5y ago
If you care about having long lasting competitive advantage rather than simply being the first to market, than you care about your code. It just depends on what you want to optimize for.
humblepie 5y ago
The thing now I see in the Go community is cargo culting coming from seasoned veterans who took advantage of Go's minimal set of rules and created their own "standards". Take this project in Github called golang-standards. It even got the attention of Russ Cox who dismissed it in this Github issue: https://github.com/golang-standards/project-layout/issues/117 https://github.com/golang-standards/project-layout/issues/11....
deleted 5y ago
[deleted]
slaymaker1907 5y ago
Developers are stakeholders to, ESPECIALLY the author. Writing clean code gives me aesthetic pleasure so that is reason enough for me to do so.
kuang_eleven 5y ago
I mean, of course users don't care about clean code. I care about clean code, because I care about future-me.
wvenable 5y ago
I think all the wrong lessons were learned here. Users do care about how maintainable your code is. They're often committed to your piece of software. If you code is bad, they will eventually feel it. I've experienced that with my own software over time and software built by other companies. At work, the end users know our financial system is fundamentally unmaintainable and we aren't going to buy the fancy total re-write new version from that vendor. The other lesson is that it's entirely possible that a single file PHP monolith is not a crappy ball of mud. It might even be cleaner and easier to work with than "best practices" over-abstracted over-built monstrosity.
rectang 5y ago
If you don't care about clean code, you don't care about collaboration. Projects that don't care about collaboration don't scale.
- solumos 5y ago
  Projects (and companies) that never ship or ship too late also don't scale. In my experience, it's much easier to overbuild than it is to underbuild. I definitely agree that collaboration is essential though!
  - deleted 5y ago
    [deleted]
  - rectang 5y ago
    What really matters is having somebody to blame when the project fails!
solumos 5y ago
I realized this after going from a floundering late-stage startup with very high code quality to a hyper-growth startup with lower code quality, but much more engaged engineers focused on shipping.
Lorin 5y ago
Why would this blog disable text selection? What an obnoxious UX choice.
- felipe_csl 5y ago
  Just fixed it, text highlight color was set to transparent for some weird reason. Thanks for bringing it up.
- stjohnswarts 5y ago
  Meh just put it in reader mode or turn off JS.
nsonha 5y ago
uhm, except for the fools you employ to maintain them
stevage 5y ago
I don't understand why it's surprising to anyone that not every project needs the same approach to software engineering. Complex tasks need much more careful design than simple ones. The million dollar home page made a million dollars and was probably a single file of PHP.
joshgoldman 5y ago
Author seems like a jealous and insecure person
notyourday 5y ago
The Terrible Code that shipped and makes money is better than Greatest Code Ever that either: 1) never shipped 2) does not make money
yongjik 5y ago
At first I thought "Meh, so what?" but then, after visiting remoteok.io, I'm impressed. That's a pretty polished site with a laser-like focus. Still seems crazy to have the whole site in a single PHP file, though. A dozen files (or even a few dozens) might have been saner. But then again, in that case we wouldn't be talking about the site...
chpmrc 5y ago
Why on earth is text selection disabled on this website?
deleted 5y ago
[deleted]
cube00 5y ago
The users may not care about clean code but they sure care when I can't bring on more developers to deliver features to keep them ahead of the market that are not riddled with bugs.
darepublic 5y ago
Architect comes up with library to make it so even a monkey could handle use case X without fucking it up. Then they go to architect land where they all stay in their ivory tower. Then use case Y comes along but nobody thinks to switch from or extend what the legendary architect gave to the people. Those who try are heretics who have gone full cowpoke. Then when things get bad enough who should come to save the day but the hurdy gurdy architect, probably not the same one as last time.
tippytippytango 5y ago
Clean code shouldn’t be thought of as a principle. It is an engineering decision and every engineering decision has trade offs.
euske 5y ago
Meta observation: OP says nothing new, but I guess that people have to (re)discover this sort of principles by themselves, no matter how many times they're told by the wise and old. We often say that we hate reinventing the wheel. But life is actually full of reinventing-the-wheel experiences. Maybe that's the point of a life.
- IggleSniggle 5y ago
  Do we say we hate reinventing the wheel? I think the reason it’s even an axiom, “don’t reinvent the wheel,” is because it is so very tempting to reinvent the wheel rather than building on established wisdom.
scrubs 5y ago
The OP's post is true iff you limit your timeframe to near term and if you luck out and get all or most of the domain requirements in early and they don't change or one decides the complexity and labor to evolve those requirements doesn't warrant potential income it might garner. My employer started quickly and grew exponentially ... but ... our client requirements didn't stay fixed. What were N pieces eventually had to be integrated because clients didn't wanna hear subsystem N1 works with N3 but not N5. And after around 10 years a lot of that code became debt, and the company has had to fix/remove/evolve it while it works in production for any number of reasons: it's too slow; it doesn't scale; we relied on vertical scaling and that's long dead; can't know or can't well manage capacity concerns; customer A's load breaks customer B's work; the code is so over hacked it's a big ball of mud etc.. And eventually software engineering concerns become cool again. This is a long way to say that true success inevitably brings with it the need to expand and integrate. Here maintainability is a core business strategy. Here's something else worth remembering: the old school idea of TQA (true quality attributes) v. SQA (substitute quality attributes). Nobody (minus experts) rolls into a dealer and starts by asking the steel v. aluminum mix of the block. They don't ask how mm of coating was put on the __widget_here__ Those are SQAs. They ask about TQAs: price, quality, warranty, HP, resell value, whether it has AWS, power steering etc... but if anyone of those things breaks and the dealer has to fix it or the manufacture has to do a recall, the focus goes right back to the SQAs, the opportunity defects which allows those crappy SQAs etc.. etc.. So yes the client doesn't care what's under the hood, until one day you have to because one of the TQAs is violated. SQAs are the producers/suppliers implementation to gain the TQAs. They are separated in time --- time to when the client sees an issue --- but not in cause and effect. Software isn't magic. A lot of the SQAs eventually align with maintainability for the long haul.
deleted 5y ago
[deleted]
stanislavb 5y ago
well, my future self cares...
cheeri0 5y ago
Best analogy is coding is like writing. Lots of people think they are good authors. They will write novel upon novel. L Ron Hubbard wrote more than anyone and it was all garbage. You have new coders (less than the few years it takes to go down enough dead ends and see what works and what doesn't work) who think their code is good but it's just the worst. They are like novelists writing crap stories with a sex scene between a navy seal and a sexy scientist with big boobies. The only good code is code with no ego but not so little ego that's it's dogmatic about not having an ego. These last few years I've seen the barrier to entry be lowered for programmers resulting in even more terrible code written by people who think knowing Angular is the zenith of good code. It's all bad. You can't tell them it's bad. It's actually worse than millions of bad novelists because you have to use third party code which is also bad so even good programmers have to use bad code. There's just no winning. So while you bang your head against the wall for three days getting dependencies to work with your brilliant creation and it stretches your probably strong brain to its limits just remember your boss, who gets paid more than you and gets to think big picture, didn't have to learn ALLLL the stuff you did and doesn't care about how much you know as long as the end result is good enough. Only idiots write software these days.
micimize 5y ago
Few things: 1 file != sloppy code. remoteok.io, like nomadslist, is fundamentally much more about marketing and network effects than the software. While that in and of itself is a lesson, sometimes a worthwhile idea is more complicated than a job board, or even what one can throw together for a hackathon. I feel a major problem in the culture of the programming community is that we feel the need for this kind of click-bait conviction. A bit too many blog posts fit the format "Nobody cares about your _____... Ultimately, there is no right or wrong approach."
xixixao 5y ago
What’s underestimated is attitude. Same situation, 2 ways of looking at it: “Our codebase sucks, we’re constantly running into issues, can’t change things. We’ll have to rewrite it all. I hate this” “This codebase allowed our company to scale to XXX $s/users! It served us well but now’s a time to rewrite it to fit our new needs: reliability, scalability. This is a great challenge and opportunity for those working on it. I love this”
1vuio0pswjnm7 5y ago
"Turns out that the harsh truth is... Users couldn't care less about the programming language you used or how beautiful, clean, modular and maintainable your code is. In fact, they don't give a crap about it." This applies to some users, for sure, but not all. The few people on the planet who read, edit and write source code are also users. As a user, I do care about the choice of language and what the code looks like, for a number of reasons. It tells me about how the program works. It is often the best "documentation" provided. It makes a difference if I want to edit the code. It reveals something about the mind of the author. Does this person have an appreciation for the same qualities in software that I have. Is the person careless or careful. Verbose or succinct. Where possible,^1 I generally avoid program written in languages I myself do not use. All those Go programs posted to HN. I skip them all, no matter how good they sound. Python. NodeJS. Rust. The list goes on. I save quite a bit of disk space this way, avoiding large binaries and library installs. 1. I once commented on HN that I do not use programs written in Java and some JavaCard programmer got offended and said I was wrong because Java is in all sorts of devices, and JavaCard is running on SIM cards. That was not the point. The point was I am a user and if given the choice between a Java program and nothing, I will choose the later. The trick developers in "tech" use today is to remove user choice. (See, e.g., "dark patterns.") When choice is removed, then it does not matter if or what users would choose. Turns out there is at least one user who does care and he does give a crap. :)

180 points by felipe_csl 5y ago

This should have been titled "Users don't care about your clean code". But it's 2021, click-bait is necessary. Also this is the difference between a indiehacker and a SDE. Pieter is a indiehacker not a SDE.

tpoacher 5y ago

Corollary: Nobody cares about the materials you used for the spaceship. (Unless it explodes mid-air, that is. Please don't explode mid-air. Please don't explode mid-air. Please don't explode mid-air ...)

dosethree 5y ago

Code has to be clean enough. The penalty for dirty code can be quite steep, or none at all. Never let perfect be the enemy of good.

taylodl 5y ago

> "Often I see developers that seem to care more about writing clean and beautiful code just for the sake of it, completely forgetting the bigger picture, why they are doing it." Here's what I've learned over the past 35 years developing software: I typically don't care much about implementation. There are many ways to skin a cat and it's not very productive to argue amongst them. Whatever. What is important however are interfaces. Function interfaces, class interfaces, subsystem interfaces (mediator design pattern). Factory methods are also extremely important: how do I get an instance of the thing I need? These are the things that are important. How a piece of functionality is actually implemented is far down on the list of things to care about.

mindcrash 5y ago

If "nobody" cares you obviously never talked to someone running ops in your team, ever. Or the CFO when he hears about that little nasty bug hidden away in a gigantic ball of mud (https://en.wikipedia.org/wiki/Big_ball_of_mud https://en.wikipedia.org/wiki/Big_ball_of_mud) halting production over the SLA thresholds causing a massive financial issue. Customers likely don't give a shit about code, but it can and probably will eventually run your org into the ground.

james_smith_007 5y ago

Bullshit

kgilpin 5y ago

What are the odds this is a single developer code base? It’s ok to have a mess, when it’s your mess. It’s other people’s messes that are the problem.

whoomp12342 5y ago

yarp. we dont love clean code for the user, that should be obvious for anyone who has written a medium amount of code. we love clean code for the fact that some day, we are going to have to read our code, trace it for a bug... etc. You can feature bloat something up to a certain point and then.... kaboom goes the rewrite. Hopefully into clean code, but usually not since clean code is a culture and mindset, not a code base.

aae42 5y ago
yea, but isn't the obvious logical conclusion that clean code allows you to more easily and more quickly do things that the customers do want? this is like telling a mechanic that people don't want them to maintain their cars, they just want a reliable car that won't leave them stranded also, why does a php and jquery app mean it isn't clean? the better takeaway is that customers don't care about your stack
- mannykannot 5y ago
  It's not quite that simple: it is not unusual for an overall-clean solution in response to new requirements to require refactoring the existing codebase, even if that is a clean and minimal solution for the requirements up to that point. Even if you had anticipated that these additional requirements were likely, preparing in advance for their possibility would often mean over-engineering for the initial requirements, which would likely delay the initial release. If there wasn't a genuine conflict of interests here, we would not still be wrestling with it.
  - loopz 5y ago
    The problem with over-engineering is also that it makes other refactoring harder at later stages, or just discourages change. Some degree of shittiness actually improves agility, and encourages change.
    - whoomp12342 5y ago
      Amen, I have been guilty of this as well. It is a hard line to walk between over engineering and future proofing something.

volume 5y ago

There's a DevOps Cafe episode, I forget which topic, but the idea was that users just want DNS to work. Nobody cares how clean your config files are for Bind. But indirectly they actually do care because if the config files for Bind are maintained well then there's less room for human error and ... that contributes to overall stability of the service.

p1necone 5y ago

Even if you are just talking about clean code for your own satisfaction whether or not a single PHP file is "clean" or not (to me) depends heavily on the complexity of the application. If your service only needs 50 lines of business logic, a single PHP file probably would be easier to understand and maintain than modularizing it. (I have no idea how many lines of code remoteok needs).

908B64B197 5y ago

It's true that users want software that works and they don't care about the code... ... But, code quality if a pretty good heuristic for "does it work". It's possible to write a working program where the code isn't clean but as the program grows and grows you'll have more and more trouble keeping it working. In the case of remoteok.io, it's not really a surprise. It's a complete website but not a very complicated one. Post data, view posted data. Everything public. Mostly read traffic so trivial to cache.

xyzzy_plugh 5y ago

"throw the first one away" When I'm prototyping or hacking something together, I don't write tests, I don't comment/document much, I use lots of shitty variable/type names, lots of commented out code, debugging printfs, not much organization of files (often one large file). The prototype software is write-once, read-maybe. Maybe I'll want to see what I did down the road, but more likely I'll be shortly rewriting what I did somewhere else, using the fresh state still in my head. That next thing? If it's meaningful in any way and I want other humans (or future me) to expose their sight-orbs to it, then it'll be "clean code" to the best of my ability. While users won't care what your code looks like, they DO care about bugs, new feature turnaround, and downtime, all of which are exasperated by shitty code. You don't want to be staying up late on the weekend unfucking something you fucked up three years ago. Don't write shitty code for other people. That includes future-you.

bartimus 5y ago
Then also the core parts (with many dependents) deserve more elegance and readability compared to some less critical side module that can easily be thrown away and replaced.
StavrosK 5y ago
When I'm prototyping or hacking something together, it eventually becomes production. I cannot relate to people who make prototypes to throw away, I've never done it, and I don't know why I'd do it. Due to that, I write my first line of code as if it's going to be on production forever, because it will.
- deepGem 5y ago
  I have done quite a lot of prototypes and while the initial ones were throw away code, I quickly realized that I can re-use a lot of code in future prototypes. Especially code that involves building user management and database access. Also realized it is frustrating to write repeating code. So I quickly started making code slightly more readable and reusable. It's not the holy grail of software development but it ain't shitty code either. Also I tend to use only one web framework - FastAPI, one database - mostly Redis or MySQL and one front end React. Saves a ton of time as I can reuse a most parts of the code. I do think there is a lot of merit in using something like GAE. Saves a boat load of time but comes at a cost and I am willing to bear the cost to save time.

deleted 5y ago

[deleted]

lostdog 5y ago

Nobody cares about what materials you used in your bridge! https://www.courthousenews.com/34m-settlement-reached-for-defective-work-on-bay-bridge/ https://www.courthousenews.com/34m-settlement-reached-for-de... But seriously, they call it "tech debt" for a reason. It's not a problem until suddenly you're no longer able to add needed features to your project, because every little bit of development takes hours and weeks and months. There are so many posts about how "Engineers Need To Learn About The Business," and yeah, it's helpful sometimes, but really there are different types of jobs. Some jobs require the engineers to understand the product and business rules, and other jobs need engineers with deep technical engineering abilities. There's nothing inherently better or worse about either! What's bad is if the job is one type and you are the other type. (Similarly, you think you want to be one type, but really you want to be the other type). So go ahead! Fiddle with an esoteric language or framework, because there are plenty of open positions that need you.

cratermoon 5y ago
Except that technical debt is not about writing bad code, and the author of this article gets it completely wrong. "The metaphor of debt is sometimes used to justify neglecting internal quality... Teams who do this end up maxing out all their credit cards, but still delivering later than they would have done had they put the effort into higher internal quality."[1] "the whole debt metaphor, let's say, the ability to pay back debt, and make the debt metaphor work for your advantage depends upon your writing code that is clean enough to be able to refactor as you come to understand your problem"[2] "write the best code possible given a partial understanding of the problem so later when you do understand it better you improve the solution"[3] 1. https://martinfowler.com/bliki/TechnicalDebt.html https://martinfowler.com/bliki/TechnicalDebt.html 2. http://wiki.c2.com/?WardExplainsDebtMetaphor http://wiki.c2.com/?WardExplainsDebtMetaphor 3. https://www.youtube.com/watch?v=pqeJFYwnkjE https://www.youtube.com/watch?v=pqeJFYwnkjE

notacoward 5y ago

John F. Woods (who I actually knew IRL briefly - nicer guy than his online reputation suggests) said it best. "Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live." I'll just add that the psychopath in question might be your own future self.

Xunjin 5y ago
Oh boy... I believe I'm this kind of psycho, when I see my name in a git blame after tracing a bug that I didn't foresee... I feel awful, disgusted, then I fix it and think "You sure are dumbass, now try to be a lesser one".
- paulmd 5y ago
  this is always fun with git-bisect because if you can reliably reproduce the bug it will always leads you exactly to the commit that caused the problem. Nothing worse than tracing for a half hour and... it spits out your name.
  - Xunjin 5y ago
    Holy Molly, learned about git bisect, ty paulmd. HN comments amazes me, I always learn a thing or two.
- enw 5y ago
  And the relief when you see your name is nowhere near the defect.
  - Xunjin 5y ago
    Yes!

routerl 5y ago

Weird post. The main insight is easily captured by the phrase "technical debt is a resource, not a vice". It also disregards that developers who care about clean code do exist, such that the title becomes merely metaphorical, and is more accurately rendered as "users don't care about clean code". Except that they do, they just don't know it. Time to new features and time to bug fixes (both of which users do care about (though, of course, not unanimously)) is inversely proportional to how easy a codebase is to navigate and understand (read: how clean it is). Finally, all software developers (or all workers?) prefer their work to have a high ratio of accomplishment to drudgery. The primary benefit of clean code is developer quality of life, as indicated by the nascent field of DX (Developer Experience).

dosethree 5y ago
Technical debt not only makes it harder to add features, it makes it harder to remove technical debt and make technical improvements. Choosing not to pay down technical debt is fine, but at some point it will be such a mess you won't be able add features or fix the technical debt issues without a total rewrite scale project.
hinkley 5y ago
Money is a resource too, but rock stars tend to turn it into a vice.

zelon88 5y ago

I think it's ironic that the author claims that clean code is....... Package your code down into small, atomic and reusable units Follow the single responsibility principle Use frameworks and libraries to avoid reinventing the wheel Whatever language you pick, don’t pick PHP These are best practices. It is possible to follow every one of those rules and still have a pile of broken, insecure, garbage code. Likewise you can have a very elegant one-liner that fits none of those and gets a job done cleaner and easier than any alternative. You can even have a single page app that fits most of those, and I would argue that it would probably stay cleaner without adding a framework. Frameworks in many ways bind you to a certain style. It's all about keeping the scope of what you're doing in mind and using the correct tool for the job. Saying "this tool is better for every job" is going to get you a lot of arguments. Also, with the exception of the third bullet point, you can follow all of those practices and still fit your app into a single file. There is nothing more frustrating than working on a codebase that puts 12 lines of code in each file and then spreads that code into 1,000 files. And the final bullet point in regards to PHP is just false. But I digress.

tmaly 5y ago
This gave me a thought just now. When future changes are needed to a piece of software, these are usually driven by the business side. If the original developers have moved on, and the current developers do not have a good handle on the software, there could be some troubles making changes. What if we approach the problem by structuring the code and choosing names to better reflect the business terminology. Make it such that a business person could understand the software at high level. Then years later, it becomes much easier for a new set of developers work with the business side to make enhancements and changes.
userbinator 5y ago
That's partly the reason why the term "best practice" has become a bit controversial in some communities --- it's seen as mindless dogmatic cargo-culting. I've heard the saying "best practices are best not practiced" from the opposition. There is nothing more frustrating than working on a codebase that puts 12 lines of code in each file and then spreads that code into 1,000 files. In other words, "Enterprise" code, which is in my experience usually designed more to hit all the "best practices", and often according to the opinion of some idiotic tool (as in computer program, although sometimes a person too...), than do anything sanely.

young_unixer 5y ago

The fatal flaw of this article is assuming that having a single PHP file implies ugly code, or at least uglier than the average codebase. I would, in fact, guess that its code is much cleaner than the average Fullstack Javascript app. If you're capable of writing a full, functional website in one PHP file, you know what every line of code does, you have only what you need and the ways to factor your code become more obvious. Using the "modern" Javascript stack usually means that you had to spend months or years trying to learn this mishmash of Javascript libraries (React, react-redux, Express, an auth library, an ORM, etc.) and you don't know what most of those things do under the hood. The lesson I take away is: Simple (PHP + Jquery) can be better than complex (React, Redux, Express, Passport, etc).

dosethree 5y ago
I've spent some time trying to pick up modern JS tooling. I used to code JS back in the early days of JS and stopped around the time Backbone JS stopped being used The learning curve right now in JS is ridiculous. Onboarding developers is hard. We wrote a new project in ember js and threw it away for react. Sometimes new tools, like Ruby on Rails, make it way easier to get started. Not so with JS. But I'm sure you get a lot of dynamic rendering power to make up for it
PurpleFoxy 5y ago
If learning a couple of basic tools like an ORM and JS build tools is too much of a barrier, you probably shouldn’t be let anywhere near a database with real users data in it. PHP is too easy to get started with and let’s you do some truely horrific things trivially.

brlewis 5y ago

tl;dr Here's a web site that made a lot of money despite being a single file of code that we presume is ugly. From this we conclude that one must choose between writing clean code and focusing on what the user wants. (In case it isn't obvious, I disagree. Maintainable code lets you adapt to an evolving understanding of what the user wants.)

sidcool 5y ago

Clean code is not meant for end users.

LinusPrime 5y ago

Under capitalism, the conditions and means of how products are produced are made irrelevant. Sad.

joshsyn 5y ago

I do what I think is best for myself. You do what you think is best. Obviously won't employ author though.

ViVr 5y ago

This article seems to focus on clean code not having a significant effect on the software in production for the experience of the end user. One example where I have experienced the benefits of a clean codebase is when onboarding new developers. It takes a few days of handholding but once they've started working with the code there's very little room for gotcha situations where they get stuck or inadvertently introduce bugs due to being misdirected by the code that was already there.

cutler 5y ago

Remoteok.io is a refreshing **ck you to all the over-engineered barely-more-than-static sites rigged-up with the latest version React hook form packaged up in Docker ready to be deployed on Kubernetes. People, we need a movement which embodies this sentiment.

RandyRanderson 5y ago
A "eat more blueberries diet" will always be more popular than a "eat less" one b/c with the form you'll have farmers, super markets, etc behind you. With the latter, the message will be don't go to the store and buy something - not 'sale sustaining' (yes that was an awesome pun).

gumby 5y ago

If you can do a single page app with no frameworks you definitely should do so! If you have a large complex system, making it clean up front (i.e. by deployment) means someone a few years from now will appreciate the work. As for the single page app: when (if!) you want to upgrade it, just rewrite it wholesale. Until then it's creating value as it is.

altitudinous 5y ago

This is very true. END USERS in particular do not give a rats about clean code or the number of code reviews that have been done. They only care that it works. Technical debt, refactoring, reuse? Nobody cares except developers. The paying customer is all that matters.

ewmiller 5y ago
The paying customer cares when your tech debt becomes so burdensome that you can no longer deliver features (or fix bugs) on the timeline they want.

atum47 5y ago

I really don't get all the hate towards php, I'm about to put my old blog online and it's written in php. It's a cool language.

PurpleFoxy 5y ago
It’s because it makes no effort to prevent people doing insanely insecure things. Rails has a lot of safeguards for insecure things like using user input to update a record. PHP won’t even fix bugs due to backwards compatibility. They worked out their sql string escape function didn’t escape properly but instead of fixing it and telling everyone to check their code, they duplicated the function and prefixed the name with “real_”.
- EugeneOZ 5y ago
  Rails is not a language. PHP maintainers do fix bugs. I don't use PHP right now, it's not my favorite language, but I hate when people are trying to excuse their own laziness and incompetence by saying “it’s all because of tool X”.
  - SilverRed 5y ago
    Rails and ActiveSupport are a huge extension to Ruby and are bigger than the non Rails Ruby usage. If you read the average PHP tutorial, it starts you out connecting to a db, running raw sql and rendering templates in the same file. An absolutely horrible idea. If you start on the default rails tutorial, you gets set up with a decently safe configuration.
    - flukus 5y ago
      > An absolutely horrible idea It's not a horrible idea, it's the simplest and easiest way to solve simple problems. Bringing in rails and all it's abstractions for something you can do in a single php (or ruby BTW) file is insane.
      - 5y ago

JediPig 5y ago

very true, i know a system written in django 1.x and the site makes billions a year. the code? complete utter crap. Written by a person that read a book on how to write a website. It still makes billion a year.

ZephyrBlu 5y ago

This is a false equivalency. Pieter does not run a hypergrowth startup. His businesses are completely different to AirBnB and Stripe. He does this because he's the only person who works on the codebase and because it generates a lot of attention due to how polarizing this choice is. I'd also argue that messy code is the product of hypergrowth, rather than messy code being required for hypergrowth. Purposefully writing shit code because you're "moving fast and breaking things" seems like a dumb idea.

felipe_csl 5y ago
Agreed! Thanks for pointing out my logical fallacies.

asdfsfkwqe 5y ago

But your teammate and the future self will

hinkley 5y ago

Nobody cares about your excuses for writing godawful code either. Call it a draw.

moocow01 5y ago

In the medium to even sometimes short term, clean code IS what allows you to ship features to users quickly and efficiently.

hn_throwaway_99 5y ago

If you are a single developer, sure, knock yourself out, and stick everything in a single file. If you actually ever plan on ever having other developers contribute to and maintain your code, or god forbid multiple teams of developers, you better have things structured in a way that they can understand.

kevin_thibedeau 5y ago
I had to dig into a niche TLS library a few months ago and was aghast at the 50000 line source files with massive God functions all over the place. I don't know how it ever was allowed to get that fubared or how they maintain it all.
- paulmd 5y ago
  SSL/TLS are godawful messes of standards, they are insanely complex to implement which is part of why they have had so many bugs turn up in recent years.

livinginfear 5y ago

Silly premise. There's plenty of open-source products out there that will attest to the fact that the quality of a codebase has no effect on its overall commercial viability. The adage "Move Fast and Break Things" is a cancer on the software industry. I've personally had the displeasure of working in numerous teams, departments and companies that adopted such silly philosophies in the pursuit of being "innovative". I've never seen it work in the long-term in a single instance. The cost of such mistakes are easily quantifiable. I'm sure most people here can think of fitting personal anecdotes where they've seen entire codebases rewritten to make them into scalable, maintainable solutions. Even this article lists several examples which attest to this. I shudder to think of the amount of money that has been invested in migrating codebases away from NodeJS, or MongoDB, for instance. > "...or grow in a steady, sustainable and healthy pace and be eaten up by competition..." Implying that it takes an order of magnitude more time to make responsible technology choices, or to write tests? This is rubbish. A stitch in time saves nine. I've never seen an instance where better management, better planning, and more responsible development couldn't have prevented a project from needing to be rewritten in twelve months.

galangalalgol 5y ago
Rewrites aren't the worst thing ever. Sometimes writing it twice takes less time than getting it correct the first time.

presentation 5y ago

Users don’t care about clean code, but I do find that the more I try to write clean code the faster I get at writing clean code.

Olumde 5y ago

Dirty code will work until it becomes an unwieldy mess that is almost impossible to debug or improve. Then the competition will eat your lunch.

axiosgunnar 5y ago

Keep in mind that the website in question seems to be a two-page CRUD website with no moving UI elements (save for opening and closing panels) that probably has not changed much in the last months save for some CSS edits. How that in any way compares to a full blown application-in-browser like eg Figma or an infrastructure product like Stripe or a household brand marketplace like Airbnb that have to cater to various user groups, iterate at breakneck speeds and keep a triple/quadruple 9 uptime is beyond me.

auslegung 5y ago

> eventually you reach a point where maintaining that large (usually monolithic) codebase becomes so unbearable, so hazardous that you have to stop and rethink the entire design This assumes that your app will grow indefinitely. What if we had more apps that were considered finished?

jollybean 5y ago

Yes, definitely iterate and throw away at the start, and understand that clean code has quite a cost, but obviously strive to understand when it's worth it. Hidden value of clean code: Developer's sanity and willingnses to work on it. Code has the 'Broken Windows' problem: if it's a pile of dirt, people will treat it like a pile of dirt, and not want to work on it. If it's clean, their their work will have legacy, they're more likely to value their own time and effort.

deleted 5y ago

[deleted]

tomlagier 5y ago

Obligatory: Not every company is in "that category" (hyperscale startups trying to churn out their MVP). Some places where clean code really matters: - The personal project where, if you can't figure out how you did something, you'll quickly get bored and quit. - The open source project that needs to onboard hundreds or thousands of developers across language barriers in order to successfully solve problems. - The medium-to-large startup or enterprise that needs to maintain velocity on a product line. - The small startup that never quite hit hyper growth and needs to retain developers. - ... many more If you're trying to get rich quick, or quickly iterate through many different, dissimilar ideas, then writing sloppy code is fine. I'd argue that that's _not_ most codebases (though perhaps it is in the entrepreneur community).

nixpulvis 5y ago

Mountains on molehills. Glaciers melting in the harsh sun. All we do is subject to the fate of our ancestors. Brilliant is the one.

simplify 5y ago

I care about my clean code. Nearly every line of code I write is "clean", because it affects the bottom line. Messy codebases and bad architecture quadratically drive up the cost of development time. I've experienced this countless times for over 10 years, and it's endlessly frustrating. The state of web has gotten so tirelessly messy, I had to write my own framework to return to the clean web architecture we once had. And my clients love it, even if they're not directly aware of it, because everything takes less time (and therefore less cost) to build.

dehrmann 5y ago
It's a lot easier to swap out contains() for startsWith() at code review time than investigate some obscure bug that only affects a handful of requests 3 years later.

rapfaria 5y ago

"Users couldn't care less about the programming language you used", and yet the author is so protective of his work that I can't copy paste this phrase. Unhappy user right here. We code for ourselves. We deliver value to the costumer. Two different things.

felipe_csl 5y ago
The inability to copy/paste was actually an oversight on my part, will fix. Thanks for pointing it out, not even sure why that's the case right now :)
- felipe_csl 5y ago
  Fixed!
flukus 5y ago
> Unhappy user right here. I'm more pissed off that my user agent (firefox) even allows this sort of control by third parties.

typon 5y ago

If you care about having long lasting competitive advantage rather than simply being the first to market, than you care about your code. It just depends on what you want to optimize for.

humblepie 5y ago

The thing now I see in the Go community is cargo culting coming from seasoned veterans who took advantage of Go's minimal set of rules and created their own "standards". Take this project in Github called golang-standards. It even got the attention of Russ Cox who dismissed it in this Github issue: https://github.com/golang-standards/project-layout/issues/117 https://github.com/golang-standards/project-layout/issues/11....

deleted 5y ago

[deleted]

slaymaker1907 5y ago

Developers are stakeholders to, ESPECIALLY the author. Writing clean code gives me aesthetic pleasure so that is reason enough for me to do so.

kuang_eleven 5y ago

I mean, of course users don't care about clean code. I care about clean code, because I care about future-me.

wvenable 5y ago

I think all the wrong lessons were learned here. Users do care about how maintainable your code is. They're often committed to your piece of software. If you code is bad, they will eventually feel it. I've experienced that with my own software over time and software built by other companies. At work, the end users know our financial system is fundamentally unmaintainable and we aren't going to buy the fancy total re-write new version from that vendor. The other lesson is that it's entirely possible that a single file PHP monolith is not a crappy ball of mud. It might even be cleaner and easier to work with than "best practices" over-abstracted over-built monstrosity.

rectang 5y ago

If you don't care about clean code, you don't care about collaboration. Projects that don't care about collaboration don't scale.

solumos 5y ago
Projects (and companies) that never ship or ship too late also don't scale. In my experience, it's much easier to overbuild than it is to underbuild. I definitely agree that collaboration is essential though!
- deleted 5y ago
  [deleted]
- rectang 5y ago
  What really matters is having somebody to blame when the project fails!

solumos 5y ago

I realized this after going from a floundering late-stage startup with very high code quality to a hyper-growth startup with lower code quality, but much more engaged engineers focused on shipping.

Lorin 5y ago

Why would this blog disable text selection? What an obnoxious UX choice.

felipe_csl 5y ago
Just fixed it, text highlight color was set to transparent for some weird reason. Thanks for bringing it up.
stjohnswarts 5y ago
Meh just put it in reader mode or turn off JS.

nsonha 5y ago

uhm, except for the fools you employ to maintain them

stevage 5y ago

I don't understand why it's surprising to anyone that not every project needs the same approach to software engineering. Complex tasks need much more careful design than simple ones. The million dollar home page made a million dollars and was probably a single file of PHP.

joshgoldman 5y ago

Author seems like a jealous and insecure person

notyourday 5y ago

The Terrible Code that shipped and makes money is better than Greatest Code Ever that either: 1) never shipped 2) does not make money

yongjik 5y ago

At first I thought "Meh, so what?" but then, after visiting remoteok.io, I'm impressed. That's a pretty polished site with a laser-like focus. Still seems crazy to have the whole site in a single PHP file, though. A dozen files (or even a few dozens) might have been saner. But then again, in that case we wouldn't be talking about the site...

chpmrc 5y ago

Why on earth is text selection disabled on this website?

deleted 5y ago

[deleted]

cube00 5y ago

The users may not care about clean code but they sure care when I can't bring on more developers to deliver features to keep them ahead of the market that are not riddled with bugs.

darepublic 5y ago

Architect comes up with library to make it so even a monkey could handle use case X without fucking it up. Then they go to architect land where they all stay in their ivory tower. Then use case Y comes along but nobody thinks to switch from or extend what the legendary architect gave to the people. Those who try are heretics who have gone full cowpoke. Then when things get bad enough who should come to save the day but the hurdy gurdy architect, probably not the same one as last time.

tippytippytango 5y ago

Clean code shouldn’t be thought of as a principle. It is an engineering decision and every engineering decision has trade offs.

euske 5y ago

Meta observation: OP says nothing new, but I guess that people have to (re)discover this sort of principles by themselves, no matter how many times they're told by the wise and old. We often say that we hate reinventing the wheel. But life is actually full of reinventing-the-wheel experiences. Maybe that's the point of a life.

IggleSniggle 5y ago
Do we say we hate reinventing the wheel? I think the reason it’s even an axiom, “don’t reinvent the wheel,” is because it is so very tempting to reinvent the wheel rather than building on established wisdom.

scrubs 5y ago

The OP's post is true iff you limit your timeframe to near term and if you luck out and get all or most of the domain requirements in early and they don't change or one decides the complexity and labor to evolve those requirements doesn't warrant potential income it might garner. My employer started quickly and grew exponentially ... but ... our client requirements didn't stay fixed. What were N pieces eventually had to be integrated because clients didn't wanna hear subsystem N1 works with N3 but not N5. And after around 10 years a lot of that code became debt, and the company has had to fix/remove/evolve it while it works in production for any number of reasons: it's too slow; it doesn't scale; we relied on vertical scaling and that's long dead; can't know or can't well manage capacity concerns; customer A's load breaks customer B's work; the code is so over hacked it's a big ball of mud etc.. And eventually software engineering concerns become cool again. This is a long way to say that true success inevitably brings with it the need to expand and integrate. Here maintainability is a core business strategy. Here's something else worth remembering: the old school idea of TQA (true quality attributes) v. SQA (substitute quality attributes). Nobody (minus experts) rolls into a dealer and starts by asking the steel v. aluminum mix of the block. They don't ask how mm of coating was put on the __widget_here__ Those are SQAs. They ask about TQAs: price, quality, warranty, HP, resell value, whether it has AWS, power steering etc... but if anyone of those things breaks and the dealer has to fix it or the manufacture has to do a recall, the focus goes right back to the SQAs, the opportunity defects which allows those crappy SQAs etc.. etc.. So yes the client doesn't care what's under the hood, until one day you have to because one of the TQAs is violated. SQAs are the producers/suppliers implementation to gain the TQAs. They are separated in time --- time to when the client sees an issue --- but not in cause and effect. Software isn't magic. A lot of the SQAs eventually align with maintainability for the long haul.

deleted 5y ago

[deleted]

stanislavb 5y ago

well, my future self cares...

cheeri0 5y ago

Best analogy is coding is like writing. Lots of people think they are good authors. They will write novel upon novel. L Ron Hubbard wrote more than anyone and it was all garbage. You have new coders (less than the few years it takes to go down enough dead ends and see what works and what doesn't work) who think their code is good but it's just the worst. They are like novelists writing crap stories with a sex scene between a navy seal and a sexy scientist with big boobies. The only good code is code with no ego but not so little ego that's it's dogmatic about not having an ego. These last few years I've seen the barrier to entry be lowered for programmers resulting in even more terrible code written by people who think knowing Angular is the zenith of good code. It's all bad. You can't tell them it's bad. It's actually worse than millions of bad novelists because you have to use third party code which is also bad so even good programmers have to use bad code. There's just no winning. So while you bang your head against the wall for three days getting dependencies to work with your brilliant creation and it stretches your probably strong brain to its limits just remember your boss, who gets paid more than you and gets to think big picture, didn't have to learn ALLLL the stuff you did and doesn't care about how much you know as long as the end result is good enough. Only idiots write software these days.

micimize 5y ago

Few things: 1 file != sloppy code. remoteok.io, like nomadslist, is fundamentally much more about marketing and network effects than the software. While that in and of itself is a lesson, sometimes a worthwhile idea is more complicated than a job board, or even what one can throw together for a hackathon. I feel a major problem in the culture of the programming community is that we feel the need for this kind of click-bait conviction. A bit too many blog posts fit the format "Nobody cares about your _____... Ultimately, there is no right or wrong approach."

xixixao 5y ago

What’s underestimated is attitude. Same situation, 2 ways of looking at it: “Our codebase sucks, we’re constantly running into issues, can’t change things. We’ll have to rewrite it all. I hate this” “This codebase allowed our company to scale to XXX $s/users! It served us well but now’s a time to rewrite it to fit our new needs: reliability, scalability. This is a great challenge and opportunity for those working on it. I love this”

1vuio0pswjnm7 5y ago

"Turns out that the harsh truth is... Users couldn't care less about the programming language you used or how beautiful, clean, modular and maintainable your code is. In fact, they don't give a crap about it." This applies to some users, for sure, but not all. The few people on the planet who read, edit and write source code are also users. As a user, I do care about the choice of language and what the code looks like, for a number of reasons. It tells me about how the program works. It is often the best "documentation" provided. It makes a difference if I want to edit the code. It reveals something about the mind of the author. Does this person have an appreciation for the same qualities in software that I have. Is the person careless or careful. Verbose or succinct. Where possible,^1 I generally avoid program written in languages I myself do not use. All those Go programs posted to HN. I skip them all, no matter how good they sound. Python. NodeJS. Rust. The list goes on. I save quite a bit of disk space this way, avoiding large binaries and library installs. 1. I once commented on HN that I do not use programs written in Java and some JavaCard programmer got offended and said I was wrong because Java is in all sorts of devices, and JavaCard is running on SIM cards. That was not the point. The point was I am a user and if given the choice between a Java program and nothing, I will choose the later. The trick developers in "tech" use today is to remove user choice. (See, e.g., "dark patterns.") When choice is removed, then it does not matter if or what users would choose. Turns out there is at least one user who does care and he does give a crap. :)