"throw the first one away"<p>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).<p>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.<p>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.<p>Don't write shitty code for other people. That includes future-you.
Nobody cares about what materials you used in your bridge! <a href="https://www.courthousenews.com/34m-settlement-reached-for-defective-work-on-bay-bridge/" rel="nofollow">https://www.courthousenews.com/34m-settlement-reached-for-de...</a><p>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.<p>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).<p>So go ahead! Fiddle with an esoteric language or framework, because there are plenty of open positions that need you.
Weird post. The main insight is easily captured by the phrase "technical debt is a resource, not a vice".<p>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".<p>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).<p>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).
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.<p>I would, in fact, guess that its code is much cleaner than the average Fullstack Javascript app.<p>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.<p>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.<p>The lesson I take away is: Simple (PHP + Jquery) can be better than complex (React, Redux, Express, Passport, etc).
I think it's ironic that the author claims that clean code is.......<p><pre><code> 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
</code></pre>
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.<p>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.<p>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.<p>And the final bullet point in regards to PHP is just false. But I digress.
Silly premise. There's plenty of open-source products out there that will attest to the fact that the <i>quality</i> of a codebase has no effect on its overall commercial viability.<p>The adage <i>"Move Fast and Break Things"</i> 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.<p>> "...or grow in a steady, sustainable and healthy pace and be eaten up by competition..."<p>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.
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.<p>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.
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.<p>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.
<i>I</i> care about my clean code. Nearly every line of code I write is "clean", because <i>it affects the bottom line</i>.<p>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.<p>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.
John F. Woods (who I actually knew IRL briefly - nicer guy than his online reputation suggests) said it best.<p>"Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live."<p>I'll just add that the psychopath in question might be your own future self.
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: <a href="https://github.com/golang-standards/project-layout/issues/117" rel="nofollow">https://github.com/golang-standards/project-layout/issues/11...</a>.
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.<p>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.
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.<p>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.<p>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.
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.<p>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."
This is a false equivalency. Pieter does not run a hypergrowth startup. His businesses are completely different to AirBnB and Stripe.<p>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.<p>I'd also argue that messy code is the <i>product</i> of hypergrowth, rather than messy code being <i>required</i> for hypergrowth. Purposefully writing shit code because you're "moving fast and breaking things" seems like a dumb idea.
If you don't care about clean code, you don't care about collaboration.<p>Projects that don't care about collaboration don't scale.
"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.<p>We code for ourselves. We deliver value to the costumer. Two different things.
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.
"Turns out that the harsh truth is...<p>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."<p>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.<p>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.<p>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.<p>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.<p>Turns out there is at least one user who does care and he does give a crap. :)
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.<p>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).
<i>> "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."</i><p>Here's what I've learned over the past 35 years developing software: I typically don't care much about <i>implementation</i>. There are many ways to skin a cat and it's not very productive to argue amongst them. Whatever. What <i>is</i> important however are <i>interfaces</i>. 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.
> 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<p>This assumes that your app will grow indefinitely. What if we had more apps that were considered finished?
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.<p>The million dollar home page made a million dollars and was probably a single file of PHP.
I think all the wrong lessons were learned here.<p>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.<p>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.
It's true that users want software that works and they don't care about the code...<p>... 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.<p>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.
If "nobody" cares you obviously never talked to someone running ops in your team, ever.<p>Or the CFO when he hears about that little nasty bug hidden away in a gigantic ball of mud (<a href="https://en.wikipedia.org/wiki/Big_ball_of_mud" rel="nofollow">https://en.wikipedia.org/wiki/Big_ball_of_mud</a>) halting production over the SLA thresholds causing a massive financial issue.<p>Customers likely don't give a shit about code, but it can and probably will eventually run your org into the ground.
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.
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.<p>Hidden value of clean code: Developer's sanity and willingnses to work on it.<p>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.
What’s underestimated is attitude. Same situation, 2 ways of looking at it:<p>“Our codebase sucks, we’re constantly running into issues, can’t change things. We’ll have to rewrite it all. I hate this”<p>“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”
If you can do a single page app with no frameworks you definitely should do so!<p>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.<p>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.
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.<p>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...
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.<p>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.
If you are a <i>single developer</i>, sure, knock yourself out, and stick everything in a single file.<p>If you actually ever plan on ever having <i>other</i> 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.
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.
This is very true.<p>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.
This should have been titled "Users don't care about your clean code". But it's 2021, click-bait is necessary.<p>Also this is the difference between a indiehacker and a SDE. Pieter is a indiehacker not a SDE.
Corollary: Nobody cares about the materials you used for the spaceship.<p>(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 ...)
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.
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.
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.<p>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.
very true, i know a system written in django 1.x<p>and the site makes billions a year. the code? complete utter crap.<p>Written by a person that read a book on how to write a website.<p>It still makes billion a year.
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.<p>(In case it isn't obvious, I disagree. Maintainable code lets you adapt to an evolving understanding of what the user wants.)
Obligatory: Not every company is in "that category" (hyperscale startups trying to churn out their MVP).<p>Some places where clean code really matters:<p>- The personal project where, if you can't figure out how you did something, you'll quickly get bored and quit.<p>- The open source project that needs to onboard hundreds or thousands of developers across language barriers in order to successfully solve problems.<p>- The medium-to-large startup or enterprise that needs to maintain velocity on a product line.<p>- The small startup that never quite hit hyper growth and needs to retain developers.<p>- ... many more<p>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).
Best analogy is coding is like writing.<p>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.<p>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.<p>The only good code is code with no ego but not so little ego that's it's dogmatic about not having an ego.<p>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.<p>It's all bad. You can't tell them it's bad.<p>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.<p>Only idiots write software these days.