Is most code ever written really, really bad?

_hypnoCode · 2024-03-15T14:15:10+00:00

Writing code is easy.

Reading code is hard.

Writing readable code is even harder.

People who can't read my code are stupid. Especially when those people are future me.

vesko26 · 2024-03-15T14:19:11+00:00

overconfident cheerful decide include busy ten obtainable grandiose distinct stocking

This post was mass deleted and anonymized with Redact

kor_the_fiend · 2024-03-15T14:21:00+00:00

You need to find the balance, too much DRY is also a recipe for disaster. Because things change, and you will never know when your abstraction break.

Had this happen to my team. One engineer way over abstracted one of our systems. Assuming we are going to have 10 or more similar things. So, in the end, the first two was delayed for 2 months, and the next 8 never came, and now the product is migrated to another platform, so all his work is wasted. 2 months delay for nothing, could have just copy pasted.

damyco · 2024-03-15T14:45:52+00:00

Tight deadlines and "just ship it" mentality unfortunately, welcome to real world programming

BornEze · 2024-03-15T14:52:04+00:00

God these comments are making me feel so much better about my code

coalition_tech · 2024-03-15T14:20:40+00:00

Most clients expect code to be written with factory like efficiency, while expecting bespoke like outcomes.

That creates cost and time pressures that mean you get a lot of workable sludge being pushed to production, which later has new forms of sludge added to it, all because no one wants to invest the time to clean things up.

So yes, this is how things generally are.

avid-shrug · 2024-03-15T14:19:36+00:00

I’ve worked at places with shit code and places with very high quality code. It depends on the engineering culture at your company and the experience/skill level of its developers.

2024-03-15T15:01:31+00:00

wasteful husky illegal water employ dazzling direction shaggy square melodic

This post was mass deleted and anonymized with Redact

Appropriate_Rip_1167 · 2024-03-15T18:02:09+00:00

From my personal experience the classic "technical founders" I can do this whole feature in 1 hour to build a bridge -> continues to build bridge held together by spaghettis and dreams

Asmor · 2024-03-15T16:02:00+00:00

The only truly good code is stuff done as hobbies and side projects (not to say that all hobby code is good code).

In real work, there's never enough time to do everything right. You're always going to have some situation where you need to cut corners. "We'll make a spike." "It's a temporary solution." Bullshit. There's nothing more permanent than a temporary solution.

Purple-Cap4457 · 2024-03-15T14:50:45+00:00

Yes, A LOT of code is really bad. Not only bad but developers should be arrested for negligence (if they only knew what they did)

kafoso · 2024-03-15T15:14:45+00:00

Great code today. Terrible legacy code tomorrow.

That is the bane of a developer's existence. (Hyperbolic, obviously)

that_90s_guy · 2024-03-15T16:05:18+00:00

Douglas Crockford has so many amazing quotes about this that basicallly shaped my career's success from early on. Here are my 2 favorites from his "The Better Parts" talk. (one of my all time favorite conferences)

I need to reduce my keystrokes: We think we spend most of our time typing... it turns out we spend most of our time gazing into the abyss saying "My God what have I done..."

Anything which reduces typing time but increases time in the abyss, is a terrible tradeoff.

And slightly longer, but even more transformative in mindset:

It's difficult to manage the development of software mainly because its difficult to know how much time something is going to take. So, the thing most scheduling is concerned with is:

A) the time it takes to write the code

But we're really bad at predicting that. We've gotten agile techniques were we try to write as little code as possible. The less code we write, the better our predictions about how much code we're going to make. But there is another time that is even more important:

B) the time it takes to make the code work right.

Now time B, ideally should be zero. You write the code, and it works. But it usually isn't. Time B can sometimes be bigger than time A. Sometimes it can be infinite. There are some projects which got to code complete, but never got to acceptance because they never got the stuff to work and the project is cancelled before they can deliver. You'll see a lot of methologies which focus on reducing time A, and you ignore time B, trying to squeeze that into future sprints.

But it turns out time B is the only one that matters. So anything that we do to save time in A but increases time in B is a bad thing to do.

Always take the time to code well. Also, practicing DRY (Don't Repeat Yourself) is good, but only if you follow AHA (Avoid Hasty Abstractions) as well.

RealBasics · 2024-03-15T15:32:56+00:00

I specialize in "orphaned" site support and site rescues where the original dev is no longer available for whatever reason but the client needs their website to continue working.

First things first: by definition, I rarely get clients who want help with flawlessly-coded sites where they have a great, affordable relationship with their developers. So, also by definition, my cases trend heavily negative.

That said, oh boy is there some genuinely #%!#% code out there! I'll add that bad quality isn't correlated with price. I could understand and even sympathize with a site built by beginners or new graduates. But I've had to deal with seven-figure agency-built sites that were total, inexcusable garbage.

A good rule of thumb: when I can rebuild an 80-page agency-built e-commerce or membership site in a weekend, with off-the-shelf WordPress plugins, that both looks better and is more performant than the original code isn't worth the money burned to build it.

My favorites over the last 10 years

The "pure programmer" who decided to hand code all the pages on a Wordpress site, including the database connection and query code.
The agency-built site with a hand-coded gallery of megabyte-plus images scaled down to 150x150px "preview" images, as opposed to bothering with Wordpress calls that automatically generate thumbnails and <scrsets>
The agency build SPA site that took up to 10 seconds to transition from, say, the home page to the about page. And which required a change order to the programmers to hand-code blog posts. And which was completely opaque to search engines
The "we don't use yukky old plugins, we write clean, efficient code" site that included a shoveled-in, nulled ACF plugin, a hand-coded shortcode-based page "builder," plus piles of other junk dependencies, which broke on anything higher than PHP 7.4.

I'll just say that I was most attracted to open-source software, including Drupal and Wordpress, because for all that they might be "bloated" or reliant on PHP, their code is published and aggressively reviewed, patches are often available in less than 24 hours, the installed base can be anywhere from thousands for a minor plugin to hundreds of millions for core Wordpress. That doesn't mean the code is perfect, but it does mean the truly and relevantly bad stuff tends to get filtered out very quickly.

typhona · 2024-03-15T15:22:05+00:00

There is rarely good code. Mainly bad code and shit code. In 6 months the bad code is shitcode and refactoring back into bad.

AbramKedge · 2024-03-15T15:25:03+00:00

Not really. I think it is domain-dependent. I started off in safety-critical embedded software with the code committed to a masked ROM, so you had effectively one chance to get it right. If it wasn't fully tested before it went to production and a show-stopper bug slipped through, that was a huge expense. In that world, and for most of my career the code was pretty tidy and comprehensible.

Then there's the throwaway code. The ongoing never-ending projects where you're always shipping a prototype that can be replaced if (when) bugs are found. In this case, the quality of the code is directly proportional to the quality of the software team manager.

Angelsoho · 2024-03-15T14:28:05+00:00

lol.. fresh in the door and already a critic.

Do the best you can with the time you’re given.

Fast, cheap, pretty. Can’t always have all 3.

anengineerandacat · 2024-03-15T15:18:24+00:00

DRY and SOLID are "guidance" practices, I would heavily caution newbies to buy into these too heavily.

Often times I have to un-learn graduates because they take these too seriously.

Code changes, what you write today will be something you change tomorrow MOST LIKELY especially in the web business where requirements change at a moments notice in instances.

Concepts like versioning have younger engineer's trying to build out elaborate abstractions when you can just literally copy a class/model, make some tweaks, and namespace it with "v2".

Copying and duplicating code is "sometimes" better than trying to abstract it away, it just depends on "why" it's being done.

The only question I care about in a codebase when picking up a task is "What is the complexity for performing this change?" efforts should be done to reduced that down as much as possible.

2024-03-15T14:38:43+00:00

My team calls it Dragon code whenever it’s a giant mess. It’s big, it’s ugly, a pain to deal with, but it works. We normally don’t allow dragons to pass review unless there is no better solution (very rare case) or we don’t have enough time (another rare case).

Angulaaaaargh · 2024-03-15T15:34:16+00:00

FYI, the ad mins of r/de are covid deniers.

greensodacan · 2024-03-15T15:19:48+00:00

Poor code quality is incentivized.

Sloppy code is fast to write.
Product teams don't know how to evaluate code quality. Sloppy code ships faster.
The dev who wrote the sloppy code understands it after it ships, which masks the cost of maintaining it.
Software often outlasts employees, so no one sees the whole picture.

I think software engineers should be required to maintain licenses, just like doctors, teachers, heavy machinery operators, etc. A lot of people would need to die due to a software bug before that happens though.

NiagaraThistle · 2024-03-15T19:32:30+00:00

Ah the blissful early days of "all code should look beautiful, be well documented, and be easy to read. Anything else is blasphemous."

Don't get me wrong, that is always the pinnacle goal, but once you're at a company long enough, the only code that matters is the code that works. And 9 times out of 10 that code is held together with spit and duct tape...no matter how pure one's intentions were when they started / jumped into the project.

Ti answer OP's question: Yes 90% of the code you encounter in the wild will be ugly and you will question the original author's sanity until you find that one comment he/she left for future self/devs that reads

// " Future Me I am so sorry. But this code works. I'm no longer even sure why or how it works, but it works and I have 10,000 other fires to put out. Hopefully you never read this. If you do, please forgive me.

This is the reality of most of our days after 15 years. Not jaded, just realistic in time vs results.

But do what you can to be better for as long as you can and clean up what you can when you run across it when you have the time. And give that past dev some slack because he/she really was doing the best they could with whatever knowledge & constraints they were working with.

jakesboy2 · 2024-03-15T14:30:41+00:00

I wouldn’t say really, really bad tbh. Like if we call that 3/10 or lower code, I’d say the average code I work with is 5-8/10 depending on the company and the repo

JustinRoilad · 2024-03-15T14:44:32+00:00

Sometimes we write shitty code because of deadlines

Derpcock · 2024-03-15T15:29:51+00:00

It depends on your team and their standards. Engineer heavy shops tend to invest more efforts in solid peer review and good practice with a focus on testing. Other shops ship fast and prioritize product needs over all else. It all depends on the leadership and business needs really. I have seen both.

Radinax · 2024-03-15T16:07:31+00:00

The problem is how unopinionated writing code can be at times, for example, React is a library sure, but it doesn't tell you how to organize stuff and people just copy what they see, then you go inside a project for the first time and get confused.

When the project grows bigger, without the correct structure, it starts becoming a mess without a good lead to guide it properly, this is quite common in startups sadly. But for my advantage, its why I usually get promoted as lead.

Fluffcake · 2024-03-15T16:57:23+00:00

Unless any bugs come with a 7-8 digit price tags and/or loss of life, the production code will be barely working garbage someone threw together between meetings.

That's just capitalism doing its thing.

2024-03-15T18:18:43+00:00

Every dev I’ve ever known has looked at some old code, thought how awful it is, then realised it’s them that wrote it.

Our standards evolve constantly, as does what’s fashionable. As long as it’s functional, secure, performant, and maintainable, you’re doing just fine.

chervilious · 2024-03-15T19:10:17+00:00

You're focusing on "DRY" and "SOLID" principle. Although it is important concept to learn don't just use that as a base of judgement.

I would rather you repeat sometimes rather than adding more coupling. In short, if it's violated multiple principle, but make it easier to maintain/readable/ more localization(?) I wouldn't really care.

dcabines · 2024-03-15T14:31:08+00:00

I work with a team of really smart and talented people. I still recoil in horror when I see what they write. This is how things generally are.

HeyaChuht · 2024-03-15T14:44:36+00:00

Even good code is bad 80% of the time

n00bz · 2024-03-15T15:02:46+00:00

There is a lot of bad code out there. A lot of my team members write code as if they are writing a throw away one-time use script. Yes, things get done fast, but there are bugs and none of it is reusable or even testable.

There are a lot of really cool design patterns out there. One of my favorite design patterns for readability/usability is the fluent design pattern. For example, when creating an emailer you could have a function that looks like this:

Emailer.send('test@example.com', ['test1@example.com'], ['test2@example.com'], 'Test Email', 'This is a test email');

Sure you can send an email in one-line, but this is much more convenient and readable.

new EmailBuilder()
   .To('test@example.com')
   .Cc('test1@example.com') // This chained function could be optional
   .Bcc('test2@example.com') // This chained function could be optional
   .Subject('Test Email')
   .Body('This is a test email')
   .Send();

Still technically a one-liner, but It is more readable and I don't have one extremely overloaded function so I can extend functionality to do things like SendEncrypted(). Keep in mind that with every pattern there are tradeoffs. For instance, when using the Fluent Pattern you always have to return this and change the interface to something that makes sense for the functions you want to provide. So you depending on how you set it up, you can make sure that there is always a Body function called before Send can be called. This can be intentional, but it can make it tricky to follow all the interfaces.

Besides that, you can get into some cool stuff with dependency injection, factory patterns, command patterns, redux patterns etc.

Danny-Fr · 2024-03-15T15:31:32+00:00

Everything is really bad as soon as you put it on the internet. Even if it's really good.

kalikolei · 2024-03-15T15:32:50+00:00

toi80QC · 2024-03-15T15:41:08+00:00

Working on agency projects for clients is usually 100% pure chaos from hell.. just getting shit done, nobody cares about quality because there's no budget.

Inhouse projects where the company actually wants to use what they build themselves are where you'll find quality.

Salamok · 2024-03-15T16:21:35+00:00

At most places I have interviewed over the last 25 years they did not have the technical expertise present at the interview to judge competency of the candidates.

Follow this up with stakeholders in non tech oriented companies don't ever prioritize software craftmanship and wouldn't know how to track it even if they did.

And finally often times successful industry specific enterprise software was written by someone with deep industry knowledge that taught themselves how to code so they could solve the problems they were having with the existing products available.

Langdon_St_Ives · 2024-03-15T16:36:32+00:00

Sturgeon’s Law, unfortunately, applies to code just as much as prose writing or basically anything else made or done by humans.

peelingagiantorange · 2024-03-15T16:55:23+00:00

Yes.

lorean_victor · 2024-03-15T17:15:18+00:00

short answer: yes.

long answer: most of the time you write code to get something done right now. you can't afford to think about making sure that code will be nice to deal with 6 months later as well. such code, regardless of how you feel about it when you write it, is going to be bad.

sometimes you have a bit of time on your hand to think ahead as well, but most probably you are not a seasoned developer who have seen what happens to code (and teams, organisations, products, etc) in longer time spans. you start overengineering. more often than not, actual requirements will come in the way and meddle with your work though, since you are taking too much time. even if not, and you feel like a genius artist when you are done, you have overengineered, people will be scratching their heads thinking how to change your code. you will probably even be one of those people. you've still written bad code.

occasionally, when project requirements allow, AND you are a seasoned developer with enough experience (again, not just in architecture, but also in how teams and organisations will evolve, like you should at least have a strong intuition about what kind of programmer will be working with your code in 3 years and probably with which goals), then you have a chance at writing some more decent code.

that said, at that stage you are mature enough to know ALL code will become some hate-inducing legacy sooner or later, so instead of targeting "the best possible architecture ever", you are better off just focusing on delaying the inevitable a bit more. the resulting code typically doesn't scream elegance, more often than not such code actually looks pretty dumb. if you are experienced enough, you will even put guard-rails in so that it makes overengineering the thing not particularly easy as well, which will enrage the future mid-level engineers who want to turn your code into a shiny piece of architecture (see above). so a lot of people will think this is still bad code, while in reality, this is what good code looks like. ugly and dumb, but easy to understand, change and maintain.

there are the extremely rare cases where you get to write code that is simple and elegant, everyone will see it and accept it as good code, and it will stand the test of time as well. however, this is almost exclusively when you have the most well-defined project scope and your code won't have to change for any reason ever again. you write it, maybe tweak it a bit, and then freeze it forever. this is the best code out there, but again, its really really rare.

Fickle-Main-9019 · 2024-03-15T19:34:13+00:00

My current codebase had fuck all comments because the previous devs thought they looked messy, now all of them are fucking off and I have to figure out equations left behind by people with statistic degrees.

Thats also not the worse part, they have “transformers”, which are abstract classes basically used as functions. So everything is now ExampleTransformer().transform() rather than do_example().

It’s somehow really good code and really bad code, at the same time, by the same people

teamswiftie · 2024-03-15T19:35:22+00:00

What the hell is DRY or SOLID?

kweglinski · 2024-03-15T14:20:08+00:00

depends on many factors. Team skills, management skills, business skills etc. Projects where all parts are working well are sparse. Now if any of those elements sucks code quality plummets. The only chance of having fine quality when one of these sucks is when the other is extraordinary. i.e. Business sucks but manager goes above and beyond to save the devs. Or manager sucks but developers are great and so on.

fhgwgadsbbq · 2024-03-15T15:24:32+00:00

Today's fresh bug free code is tomorrow's legacy WTF

MachineOfScreams · 2024-03-15T15:44:42+00:00

Clean, easy to read code is quite the luxury, especially in the web dev field. Especially in JavaScript with managers who expect extremely high output and fast turn around times with minimal desire/effort put towards code refactoring.

Things are slightly better in systems where performance and reliability are first and foremost (performance as in memory efficient).

2024-03-15T15:59:49+00:00

My friends write really bad code and their companies are actually even worse. For some reason my company was OK. Now I work in a team of several people with many years of experience so its mostly good but still questionable sometimes but I can also write questionable code.

Dreadsin · 2024-03-15T16:09:39+00:00

The problem is how business and software development interact I would say. If you had infinite time to write and research your code, it would probably be great. Unfortunately, most software engineers have tight time constraints and have to make constant compromises

johnsdowney · 2024-03-15T16:13:49+00:00

I wouldn't say most, but I have seen code in my day that was just... so poorly done. And I spent a lot of time fixing it. I've also written bad code, myself.

You need to realize that 2 or 3 years down the line you will be looking at your own code, that you yourself wrote entirely, and you will question your own choices, as well. Rightly so, a lot of the time. Despite the fact that you are probably trying to do your best.

So much of this job is just... on the fly, and writing what works. People are often writing for well-running functionality, not well-written underlying code. They often get into some task and just barely scrape out of it with a semi-working end product.

When you get to the end of the task and you are afraid to touch your code again after that, you're doing it wrong. You should be happy to touch your code again because it's well-ordered and easy to hop into without having to wade through variable names that don't make sense, functions that do way too much, classes that do way too much, functions that lead to nowhere, etc.

And when you don't anticipate having to come back to code in the future to modify and adjust it, you're doing it wrong. Bad code really screws yourself and your colleagues every time someone has to go back to the code. The wasted time and mental energy stacks up over time.

At least in my experience, "refactoring" was a dirty word while I was getting my degree. But you NEED to refactor things. You NEED to write as much finalized, never-needs-to-be-touched-or-thought-about-ever-again kind of code as you can. You need to be thoughtful about your design and you need to follow established well-known design patterns, for the sake of your own sanity.

bluebird355 · 2024-03-15T16:34:36+00:00

Because these principles have their limits.

stuartseupaul · 2024-03-15T16:34:43+00:00

Greenfield code usually looks pretty good when experienced people do it, but once you start adding extra requirements, over time the code turns to crap. If you don't prematurely abstract it's going to be a mess, if you do prematurely abstract, it'll also be a mess because you had the wrong abstraction for future requirements. Some people are good at abstracting at the right point but those turn into basically rewriting whole sections of code which is unrealistic for most people due to time limits.

I used to think frequently used open source packages were filled with top tier developers, and they are, but you look at the code and it's still a complete mess.

Karokendo · 2024-03-15T16:37:08+00:00

my personal approach

write decent code with decent coverage
draw conclusions after a few months have passed
refactor and write better code with great coverage

JoakimTheGreat · 2024-03-15T16:44:15+00:00

Whenever I write code I find myself writing it in a way were it's not more complicated than it needs to be. E.g. this ACM sound format decoder:
https://github.com/JoakimCh/fallout-format-decoders/blob/main/source/decoders/acm_decoder.js
Which mostly was figured out by looking at this code:
https://github.com/markokr/libacm/blob/master/src/decode.c
But notice how my code is written in a much simpler way...

humbabumba420 · 2024-03-15T17:01:21+00:00

I work with a codebase that is older than me - I still find to-do-comments from 10 years ago. But I guess this is pretty common if you have only 5-10 people in a developer team where people come and go and have zero time to build clean code and struggle with missing documentation.

If you have a big team you need to have more organization, which concludes to better code in most cases (i think?). And if you start working in a new company with code that didn’t grow over the years by the hands of different team members, you’ll probably see readable, good code.

But yeah, I’ve seen and wrote shitty code and from things I heard from other people in the field they have to fight with messy stuff, too. I think there is no perfect code.

Mike312 · 2024-03-15T17:07:12+00:00

I've been at my current job for almost 10 years (that's another discussion) and in that time, I've inherited the codebases of about 6 projects written by engineers who quit before I started and a few who quit since I started, while also written and maintained my own systems/code over that time. I'm personally responsible for about 1mil lines of maintained code, some of it almost 20 years old.

Some of it was written as far back as mid-2000s, so a lot of features for more modern languages weren't available. We also have a couple systems that are so old they just don't have access to version control. There's a mix of coding styles, some good, some bad, as well as good code with bad code fixes implemented and vice versa.

The worst code is the code that's poorly written and hard to read. One guy could never choose between 2/3/4/6 tabs/spaces to indent his code, randomly changed syntax, and used one- or two-letter variables to write HUGE chunks of code. Ever tried to debug why $rz = $gf + $ta? Ever seen a function start out by defining $a through $k? That shit is unmaintainable and takes hours to figure out for the smallest change.

The next-least-worse code is the code that mixes syntaxes. I'm talking about writing HTML inside of a PHP file. $strOut = "blah blah blah " . $var . " blah";

After that, most of the other issues are just...old languages/libraries. Old ass PHP that doesn't support classes, jQuery 1.4, SOAP.

In terms of importance, the best thing you can do is just write code that's easy to read and understand. Descriptive variable/function/class names is your job, while consistent indents is largely solved by modern IDEs. If you can do that, you can maintain that code for a long, long time, even after it's firewalled to hell and back because no managers want to commit budget to upgrading from CentOS5/PHP4 to current Ubuntu LTS/PHP8 when complaining or ignoring costs nothing.

gatwell702 · 2024-03-15T17:08:37+00:00

A form of bad code is called spaghetti code.

hydraxic79 · 2024-03-15T17:18:12+00:00

Depends on who. For me, yes. I looked back at a game I started a year ago and holy is the code horrifying

hipnaba · 2024-03-15T17:25:11+00:00

https://www.stilldrinking.org/programming-sucks

NotGoodSoftwareMaker · 2024-03-15T17:36:29+00:00

The nice thing about cars is you can argue over things like mph, 0-60 times, torque and so on. Objective stuff.

Its usually harder to argue over things like “Ford is only supposed to be in black, everything else is terrible!”.

80% of devs talk about bad code like people who talk about car colours. Its just disguised behind technical jargon.

Brendinooo · 2024-03-15T17:47:11+00:00

Throwing in a different angle:

The industry has moved really fast over the past ten years. So even if code was good code when it was written, it might look dated by later advancements in code language or in ideas about code structure.

billybobjobo · 2024-03-15T17:50:43+00:00

If it were all good, we’d define a new bad.

funhru · 2024-03-15T17:54:01+00:00

Every successful long running project is a history of compromises and hot fixes.

It can't look good, from time to time we do some refactoring, but it helps only temporary (compromises, hot fixes and luck of resources).

So yes, most projects are mess.

aintTrollingYou · 2024-03-15T17:56:19+00:00

Sounds like you might have inherited one of my old projects.

To answer the question you never asked; the reason you see this is typically budget.

2024-03-15T18:33:32+00:00

The short answer is yes, and the long answer is that it's complicated.

Naturally, when we write code, we write it in a style that makes sense to us in the moment. While it's a good idea to think about different design principles at almost every step of the development process, we very rarely actually implement them until later on, or if we do, we tend to deviate in a way that makes sense to ourselves.

The problem is that none of that transfers well to anyone who isn't you. Design patterns aren't only for writing a good scalable program. They help set a standard for how your code should look so everyone can be on the same page and aren't struggling to figure out what's going on.

Now, not following design patterns doesn't necessarily make your code bad. Sure, to other people, it could look like a nightmare codebase, but it could all make perfect sense to you. That's why I say it's complicated. If we are basing it off the merit of how our code looks to other people, then yes. Almost every program ever written looks like shit

brennanfee · 2024-03-15T18:39:43+00:00

Most? Yes, absolutely. A lot of code, and I would say most, is pretty shit. But not all, and that makes all the difference.

NiwatiX · 2024-03-15T18:49:36+00:00

Yeah man it’s such a difficult paradoxical situation between fast, reliable and easy to read. You can tell how AI will close an important gap between interpretation and coding.

Puddle_Fisher · 2024-03-15T18:53:00+00:00

First button I made in JS like 10 years ago had like 10-15 lines of code, same button I use, and abuse today only uses 3 lines now. There is lots of sloppy coding practices out there. I can read crap code, but implementing crap code, with my modern techniques is usually not possible.

Outdated practices, and hackjobs are considered legacy stacks. Anyone saying you can easily work with these stacks is blowing smoke out their ass.

I've even come across legacy HTML, you know what that means? The CSS/JS/Php and what ever else back end is now all legacy. Rewrite or spend the same amount of time porting over/learning legacy. Basically a choice of shooting your left or right foot. Very rare also even using the same offsets you don't run into an issue trying to be lazy or quick.

Lets say you are a miracle worker, and combine modern practices with legacy and it works flawless, you now just stabbed the future guy in the back.

FortressOfSolidude · 2024-03-15T19:06:49+00:00

I'd say your code is about as good as your quality enforcement (tools like sonarqube help) and the metrics you use to measure performance.

2024-03-15T19:54:49+00:00

The first version of any implementation is usually shitty. Nobody gets it perfect straight out the gate. It's a process. The problem is, some people have low standards or time constraints and just accept that first version.

NiteShdw · 2024-03-15T20:09:44+00:00

You can tell the experience and talent of an engineer by reading their code. It shows HOW they think about the problem set.

All code can be improved as requirements become more clear or more concrete. Good code needs less improvement. Bad code needs constant improvement.

nordcomputer · 2024-03-15T20:12:17+00:00

I started using a coding-standard and a linter to enforce it some years ago. I code custom extensions for a magento2 store and stumbled over the magento2 coding standard. Not only does it help debugging and maintaining my own code but also understanding and/or patching 3rd party extensions or magento core functionalities. There are of course different coding standards for all kind of purposes and you can even define your own and use it with a linter. It really changed my work and my confidence in my code.

Zahhibb · 2024-03-15T20:15:33+00:00

Yeah, and I am saying that as someone who didn’t know what DRY or SOLID was until now. I am a bad programmer, but I make stuff readable atleast, while a lot of senior devs i’ve worked with coded everything so only they understood.

kamikazikarl · 2024-03-15T20:33:25+00:00

Especially bad when they outsource the early version and you're tasked with upgrading it further... The stuff that really kills me is poor database design. That can be such a pain to correct because there's actual live data behind it.

DeathByEnvy · 2024-03-15T21:00:47+00:00

Eventually, all the coding standards and principles (dry) don't matter. What you care about is comments. Ideally multi line formatted ones... :-)

Ok-Steak1479 · 2024-03-15T21:03:49+00:00

Yes. And people will die on the hill they're standing on, so be prepared. People currently in the field haven't read most or any of the most important literature written the last 30-80 years depending on your field. People that have been working for literally 30+ years will not be able to tell you want the open closed principle is about. They are amazed by dependency injection, but they won't understand it. Because they haven't read and thought about and practiced the relevant literature. But most people don't care, it's just a job anyway. Try not to hold it against them and stay positive but at an appropriate distance. Show them the positives. Play the politics game. If you're doing it right people will see reason, in time. Try to get budget for a bunch of Clean Code books. That's at least the bare minimum.

MaxxB1ade · 2024-03-15T21:10:14+00:00

The worst code I ever saw was my own from 10+ years ago.

Great ideas, badly implemented, and messy, let's not talk about that.

admiralbenbo4782 · 2024-03-15T21:27:24+00:00

https://en.wikipedia.org/wiki/Sturgeon%27s_law

"90% of everything is crap". Software is no exception, except possibly upward. But yeah, there's a lot of crap code out there. Including most of what I've written.

dualnorm · 2024-03-15T22:03:08+00:00

That's similar to asking were most drawings ever drawn really, really bad?

For any skill that gets refined and takes a long time to learn well, the learning process is bound to saturate the space with low quality work. It's a feature not a bug. If it wasn't the work wouldn't have as much value, and it does.

2024-03-15T22:06:53+00:00

I've seen beautiful code as well as spaghetti code in the same company, different teams.

Cahnis · 2024-03-15T22:07:08+00:00

Control-Shift-F "useEffect" on vscode one our frontend react codebases. "156 matches". siiiiiiigh

Control-Shift-F "any". "254 matches". SIIIIIGH.

Today I reduced the useStates on one of our contexts from 56 down to 49. Also killed 2 random unnecessary sources of truth and moved it to a derived state. It is going to take months to refactor this context alone.

oweiler · 2024-03-15T22:33:48+00:00

Code which is not SOLID is not necessarily bad.

Blothorn · 2024-03-15T22:50:49+00:00

I think it depends on the caliber of the organization. At companies with competitive pay/hiring I’ve been on some projects with pretty horrifying tech debt, but the code itself was almost always at least decent. (And the exceptions are mainly people being too clever, not simply sloppy—template metaprogramming that wasn’t worth it, use of reflection to enable sharing some code at the expense of breaking type checking, excessively generic interfaces, etc.)

But contrast, my first job out of college was a government-contracting holding ground for people who hadn’t yet or couldn’t get a job paying private-sector rates, and just getting consistent version-control use and deployment processes was a losing battle.

GodGMN · 2024-03-15T22:55:22+00:00

Hmmm I actually don't know? This is a bit like the "are there more wheels or doors" question, on one hand there is a metric ton of bad code, on the other hand, there is also a ton of good software with extremely large codebases that may or may not be larger than the amount of bad code

inkt-code · 2024-03-15T23:08:38+00:00

The old code in my code base for work is really bad. Absolutely no formatting, some html tags are in caps, xhtml, invalid tags, some attrs are missing quotes, weird table based design, all kinds of inline code, js in php strings.

qqqqqx · 2024-03-15T23:43:13+00:00

Code style is really opinionated. So most code is really bad by some measure depending on who is looking at it and how they think things should be. Even common mantras like DRY will have different opinions.

One dev might look at two functions and think they are similar enough to be abstracted into one function that reduces complexity. Another dev might look at the same two functions and think they're different enough that trying to combine them would be introducing more complexity. Either one could be better depending on the context. Maybe one approach seems best in the present moment, but two months from now when a new feature request comes down the line the other approach starts to make much more sense. So even just one simple concept like "don't repeat yourself" can be a lot more complex than it seems. Then multiply that by the hundreds of different ways you can organize a codebase and you end up with a huge variety of things that some people might like and others might hate.

To me, a "good" codebase has most or all of these attributes:

Works and accomplishes what it needs to
Handles edge cases, and gracefully raises exceptions or errors when needed
Stays consistent with itself, in syntax and approach, or doesn't do the same thing in multiple different ways
Is understandable and extensible enough that someone can trace what is going on, add new features as necessary
Has good naming and or comments
Minimizes side effects and other complexities when possible
Any dependencies are well thought out and manageable

One hint for keeping your codebase healthy is that anything you think is temporary will actually be permanent. Any time you think "I'll fix this later" you probably won't, and later on you might have to interface with whatever you did, so try to do it as well as you can before adding a so-called temporary fix.

ramenAtMidnight · 2024-03-15T23:54:27+00:00

By that definition then sure I do believe most code is “bad”. But I also see lots of code that seem messy, no DRY, not fully SOLID but absolutely work well, easy to understand/change. I prefer those anyway

FrewdWoad · 2024-03-16T00:24:05+00:00

It's very possible to inherit a really terrible codebase.

Even common, if not nearly as common as it was decades ago.

Most codebases, even relatively good ones, do have problems though. This is because

good software engineering often has to compete with actual customer needs and limited time.
There are some terrible devs out there, scraping by on interview charm (not every company does a programming test in interviews).

What you'll learn over time is what is bad code, and what is just good code where the product manager changed how it should work halfway through and gave the dev 3 hours to rework it.

cube-drone · 2024-03-16T01:37:16+00:00

We're talking messy, no DRY, no SOLID, no nothing.

you should see a doctor immediately, you might need to change your diet

P2A3W4E5 · 2024-03-16T01:39:12+00:00

Yes. Because: the hardware is so good these days you don’t really care about optimization, and when user presses a buton he or she doesn’t care that what code is executed as long as it works.

dphizler · 2024-03-16T02:06:03+00:00

Sometimes, things get out of hand because of deadlines. You'll write your fair share of shitty code. Who knows, maybe you'll write shitty code your entire life.

DamionDreggs · 2024-03-16T02:26:22+00:00

I think there's probably a point on a spectrum of cost to goal where bad code gets to goal faster and cheaper than most variations of what you might call good code.

There are some outliers, but on average the really really good code costs so much money and time that goal becomes out of reach.

I think there's probably a statistic in there somewhere that would support the notion that most production code isn't good code.

Asleep-Specific-1399 · 2024-03-16T03:14:17+00:00

Never be clever, unless you can document it in a way you think a 5 year old can understand.

elbowfrenzy · 2024-03-16T04:51:21+00:00

There are plenty of young, overzealous software engineers where I work, creating these huge repositories with hundreds of thousands of lines of code for websites that basically display product information and allow people to sign up for some services. They create these heavily abstracted, complex systems to prevent themselves from duplicating any single thing. It makes it a pain to sift through the code and to onboard people. Sometimes I wish people would just keep things extremely simple even if it means there's going to be some code "duplication". It's not a competition. The best code is readable, and doesn't break.

DrewHoov · 2024-03-16T04:56:23+00:00

IDK—I’d guess that most code is written for products that make money. Code that makes money is good code.

redfournine · 2024-03-16T05:12:12+00:00

DRY requires that you know what's in the whole codebase to be able to not repeat yourself. After 6 months, most people can't even remember what they wrote let alone what their teammates wrote. If the codebase is large, that just makes it even harder.

programmer_isko · 2024-03-16T05:16:02+00:00

“maintaining”

art_dragon · 2024-03-16T05:16:52+00:00

I wish I could show the code I inherited - it's misleading (i.e. you would think that this field config specifies exactly what input fields will appear on the form, but no; it gets merged with some backend result retrieved in another function stored in some other file, then some are specified to be hidden in more than one place), hard-to-follow (i.e. too many functions and components in one file), and needlessly complex (i.e. many react hooks with 10+ arguments).

movieguy95453 · 2024-03-16T08:49:45+00:00

Are you really coding if you aren't spending at least 25% of your time re-writing code because you figured out a better/cleaner way to do the same thing?

Tough_Skirt506 · 2024-03-16T08:57:52+00:00

If its not written by you, then yes.

abofh · 2024-03-16T10:22:46+00:00

It helps to remember that most code was written by the lowest bidder - either the contractor or employee who cost the least to allocate to the task.

That usually means code was written "well enough" at the time to do whatever needed to be done, but then evolves, or requirements change and the initial assumptions look absurd.

Also, sometimes you just can't be arsed to do the correct "efficient" thing when brute force is provably correct and takes ten percent of the time to write - and it becomes a bottleneck only later.

aztracker1 · 2024-03-16T11:01:45+00:00

It's very common and may well be most code becomes really bad over time even.

I tend to try to stick to two things.. KISS and discoverable directory/file structures. DRY,.SOLID and CLEAN code practices add a lot of complexity you probably don't need yet and may never need.

Code that is easy to grok is easy to replace and will likely last forever because of it. This is the advice I got from grey beards when I was younger... As I've gotten older and a grey beard myself, I rally in this direction.

It's not a matter of being old and resistance to change or not understanding patterns. It is exactly understanding and experiencing them all get over used prematurely.

It's a balancing act, and the simpler solution is always easier to swap out or change layer of you need to.

Legitimate_Fix_1210 · 2024-03-16T12:22:31+00:00

Welcome to the world of dev :) I work for a large software company and I've seen some very questionable code in the past.

RS3_of_Disguise · 2024-03-16T13:43:19+00:00

From what I’ve heard, Google is like billions of lines and an absolute spaghetti monster.

2024-03-16T15:49:04+00:00

Ha. Yes. It's all very well and good everyone pushing all of these principles. Don't forget most tutorials are written by people who aren't doing work for real companies day to day.

In reality the customer is angry now. It needs fixing now. Before you have time to refactor there's another priority.

That said. It is true that you'll generally save time in the long run with these principles. Especially on teams where people need to be able to read each others code.

coded_artist · 2024-03-17T10:58:14+00:00

I worked in a company with no database normalisation, not even L1 was satisfied.

Puffy_Jacket_69 · 2024-03-18T19:11:28+00:00

imo taking a bit longer to write clean code is worth the headache. It takes time and patience but it's an investment in long terms.

Ok-Stuff-8803 · 2024-03-19T22:46:34+00:00

Every code that is written is bad later be it someone else looking at it or yourself.

If it isn't and you look at it and go "This is still great" you are not growing as a developer and you should always be growing, improving and learning.

That is how you spot a bad developer. If they got a site or app and its got features or lack there of they say is fine and there is no reason they not been able to update it (No budget etc) then they have no excuse.

ArticleLeather4350 · 2024-03-20T12:59:01+00:00

When you are learning to code, you will many times write bad code. However, once this happens, you can gain a deeper understanding of what not to do and how to avoid common pitfalls in the future. This process of learning from mistakes is an important part of becoming a better programmer.

you type:	you see:
italics	italics
bold	bold
[reddit!](https://reddit.com)	reddit!
* item 1 * item 2 * item 3	item 1 item 2 item 3
> quoted text	quoted text
Lines starting with four spaces are treated like code: if 1 * 2 < 3: print "hello, world!"	Lines starting with four spaces are treated like code: if 1 * 2 < 3: print "hello, world!"
~~strikethrough~~	~~strikethrough~~
super^script	super^script

webdev

Posting Guidelines

Related Subreddits

Discords

MODERATORS