Ask HN: Is all code crap?
Or have I been unlucky for the last 20 years as software engineer?
Other people's code? Of course. /s
Most code? Yeah, I kind of think so, actually.
The demands of business will always be at odds with engineering, and everyone is at different levels in their coding journeys, and everyone's got different opinions on what code should be. It's a tug of war where no one actually wins but everyone gets a consolation prize that hopefully makes it worth it.
Code sometimes surprises me, in a good way, and it also disappoints me a lot of the time. I can't really say that My Way TM is better. The disappointment mostly comes from a lack of will from the rest of an organization to not take steps to make things better, even when the writing is on the wall that they will have to sooner or later.
In short, yeah, it's kinda bad, but it's also not so bad. Something we all need to do, I think, is accept that what we were taught that coding would be like is fantastical. I guess I was influenced early on in such a way that I believed that one day the code would actually get better. With a handful of exceptions, it usually doesn't. Unless one is lucky, our job is to make it work and to figure it out when it's not working.
Another thought... At some point there's going to be a software caused disaster with very large human cost of life such that the governments of the world will demand and force regulation and certification. Software "Engineer" will have the same hoops and red tape every other engineering profession has to deal with and over the long run we may all be better off if it's not to late. If the transhumanists give birth to free willed laser-beams-for-eyes robot hybrids... probably too late. As dark as this sounds I hope a software disaster comes sooner than later.
The problem is that often management has been technical at some point in the past and will want a full breakdown of why something costs more time than they think to implement. Soon as you detail having to refactor X or do some other “non-essential” thing then it gets put on the cutting room floor.
I’ve experienced this a lot. It’s often people who have escaped having to write code that are the biggest backstabbers.
It's usually in the manager's best interest to deliver a feature faster even if it results in future features taking longer, because their bonus/promotion is dependent on delivering the current feature, not on the long-term impact.
I think part of it is just realizing there is no perfect code, as there's a tradeoff with everything. Acknowledging that someone else was wanting to optimize for something (e.g. efficiency, performance, robustness, scalability, time to implement, ease of maintenance, readability, handling a particular problem) and that it came with a cost at one or more of the other categories, and you realize that the strengths of anything can also be its weakness (and vice versa). It's why languages that are easy to understand, are often criticized to be verbose. Why code minifiers can improve performance, at the cost of readability. Additionally, sometimes the problem isn't fully defined when code is getting written, so it's hard to simply blame code for bugs that do crop up. It's simply unfinished code in such scenarios, not necessarily crap code.
But that said, there is definitely objectively bad code out there. I'd say if you see code trying to solve a given problem, but doing it a much more complicated way than is necessary (by like orders of magnitude, not just a couple of degrees), then it's clearly crap, as it isn't good at any of the categories mentioned above, let alone at its intended purpose.
I'd say I come across undoubtedly bad code less often than not.
For example, I think it's very hard to have code that is as fast as possible, and also is very readable. It's hard to have code that has a good UI and is also not verbose. It's hard to have code that is both complete and easy to change. So for every code you run into, you can say "this is crap because X", and there will be at least one X for which you are right.
But some code is much worse than other code. There is code that is generally good quality, even if it is rare.
I come from a culture of space-flight software where it needs to be right the first time or the mission fails. Good software is possible, it just costs more.
The crappier a codebase is the harder this becomes
Releasing without as much up-front costs lets you test more ideas. Getting your stuff space ready is a waste if your stuff doesn't actually have a market. There's a small margin of products where low initial quality kills the market, but mostly low initial quality is a pragmatic way to reduce cost of failure.
Sometimes it's a lot easier to do things the right way when the requirements are clear, and the best way to get clear requirements is to do it wrong and figure out why it was wrong.
The engineering/quality side of SWE matters way more in 90% of roles than the comp sci theory... so the whole training system is pretty backwards.
But industry will move to higher and higher level abstractions over time, just like bit manipulation questions don't get asked in interviews anymore. And I suspect serverless will neuter the design interview to a pretty great degree over the next few years.
At least personally, I've found interview questions that are light on theory (but still contain some), and heavy on coding to provide a signal that correlates much better with real world performance.
No amount of rigor and discipline can stop this trend. If you truly care about high code quality, design your programs to be small and modular, and redesign them when assumptions change instead of repeatedly patching them.
Rewriting is often unsuccessful as well, though. So practically speaking: best get used to the smell.
https://github.com/torvalds/linux
https://referencesource.microsoft.com/
https://github.com/redis/redis
I am sure there are lots of others.
$ ./helloworld.py >file.txt
SyntaxError: Missing parentheses in call to 'print'. Did you mean print("hello")?Present me and future me, however, are certainly not other people.
Code is a liability, not an asset. Over time it decreases in value, it is forgotten, misunderstood, and everything will change around it. Many times I've been happy to replace a custom system with an off the shelf one, just to reduce the amount of code I have to worry about.
Even if you keep working on it, requirements change, the code becomes a tangled mess and requires refactoring, tests need to be more complicated, you have to support more operating systems, etc.
At best it does what it needs to do well enough to pay for itself, and then some. Until it needs more work! You don't realize it's crap until it goes wrong and you look under the hood usually either.
Structure, testability, documentation and automation of the system give you a fighting chance.
It depends whether you're a true craftsman, a capitalist, or somewhere in between.
I've seen some ugly crap code that made loads of money. Still pig lipstick imho.
Revenue was probably the wrong word. Is it doing what it was intended to do? Does it do it well? That’s the beauty, not what it looks like in a text file.
(not a craftsman, not a capitalist, closer to a nihilist utilitarian with a pinch of hope)
With few exceptions, I have almost never been paid to work on code that turned out to be something I was proud of. This is on of the reasons I dropped out of pro dev, despite it being easy money.
You can see it on GitHub for now: https://github.com/gulkily/RocketScience
I love this.
I recently posted a somewhat detailed comment about my practice, and linked to even more writing about it, which can be seen at this address: https://news.ycombinator.com/item?id=31077742
Understanding systems, algorithms, design patterns etc. takes time. Nobody ever starts out writing a solution that incorporates things they don't know. That's why we have education, training, certificates etc. to rectify that and have people start out with some sort of foundation instead of from scratch.
It is rare I come across something I would classify as _good engineering_. It is mostly just crap.
Only artisans put any value into being succinct, using appropriate algorithms and data structures. Everyone else struggle with getting it to work. I think that paradigm covers just about any field of engineering out there.
https://mobile.twitter.com/id_aa_carmack/status/290886163454...
---
Thanks!
A few comments:
In some ways, I still think the Quake 3 code is cleaner, as a final evolution of my C style, rather than the first iteration of my C++ style, but it may be more of a factor of the smaller total line count, or the fact that I haven’t really looked at it in a decade. I do think “good C++” is better than “good C” from a readability standpoint, all other things being equal.
I sort of meandered into C++ with Doom 3 – I was an experienced C programmer with OOP background from NeXT’s Objective-C, so I just started writing C++ without any proper study of usage and idiom. In retrospect, I very much wish I had read Effective C++ and some other material. A couple of the other programmers had prior C++ experience, but they mostly followed the stylistic choices I set.
I mistrusted templates for many years, and still use them with restraint, but I eventually decided I liked strong typing more than I disliked weird code in headers. The debate on STL is still ongoing here at Id, and gets a little spirited. Back when Doom 3 was started, using STL was almost certainly not a good call, but reasonable arguments can be made for it today, even in games.
I am a full const nazi nowadays, and I chide any programmer that doesn’t const every variable and parameter that can be.
The major evolution that is still going on for me is towards a more functional programming style, which involves unlearning a lot of old habits, and backing away from some OOP directions.
http://www.altdevblogaday.com/2012/04/26/functional-programm...
John Carmack
YEAH HUMANS!!
Given that context, what do you mean by crap?
The platforms & systems we build upon have not significantly improved in noticeable ways. And most critically, there are zero innovations we work with that have included users. All software improvements have targetted developers, development experience, and at no point have we tried to bring a wider world onboard (XOPC being perhaps the only notable exception the last decades). Software is fallen and trash. Code is fine, and good, and noble, but none of these developers have any chance of building a single solitary lone good thing: for all that we build upon is shaky burning platforms of no merit or worth.
Software is shit. We are shit, just trash people. We have been whipped into building solutions, fixed un-soft coercive services, into building complete & totalizing things. This is bass-ackwards, wrong: anti-soft. What's actually important is building extropic systems, is sharing what's happening, is making basic soft systems. We've fallen away from the soft in software. Everything is wrong, we fail to serve the "soft"ware cause, we are misaligned to help the world, and we could do much better. Alas.
We could pivot on a dime. We could decide to start unlocking potential, not gating it, at any time. I view work's like Karlicoss's exploration of all their systems[1] as a starting place, as what software ought do by default, ought assist this species with. But they fight to help advance an equitable basis: against countless resistive piece of shit systems. This should be expectable.
In my experience I've only ever seen varying levels of crap once a codebase is large enough to sustain a business.