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.
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 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.
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.
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...
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.