How often do you write code you would describe as bad?
Posted by Whatever4M@reddit | ExperiencedDevs | View on Reddit | 106 comments
Recently, I've written a piece of code that I can only describe as bad. I got into the flow and quite literally got lost in whether I could write it rather than whether I should, and ultimately it was released.
Looking back at it, I realized it needed cleanup, and I figured out a way to make it much cleaner, which I'll implement when I have the time, but this was the first time in my life that I've written bad code without a "real" excuse, I could usually blame it on the tight deadlines or something along those lines but that wasn't the case here, and I just feel like a piece of shit because of it.
Is this normal?
david-bohm@reddit
How often do I write bad code? All the time.
The first try rarely gets the job done. Once I know where I'm getting at the initial ideas and architectural decisions often turn out to be not the right ones. That's the nature of software development: You're learning by doing - incrementally getting more understanding of what you're trying to achieve.
Steinrikur@reddit
This. My work flow is:
Do not change the order of the steps. Stop any time after step #1 is complete.
adhd6345@reddit
I personally prefer make it pretty over make it fast, but I guess that depends on the particular application.
Steinrikur@reddit
"fast enough" is the goal. Premature optimisation is the root of all evil
arihoenig@reddit
No make it secure .. sigh... As a security engineer this is my life.
Steinrikur@reddit
If it's not secure it doesn't work.
As a security engineer this should be your mantra.
_SnackOverflow_@reddit
Yeah, make it secure, make it accessible, make it maintainable, etc.
There are so many things to think about that I prefer a simpler formula:
arihoenig@reddit
Make it good works so long as the semantic of "make it good" includes "make it secure" in the minds of developers. I wish that were the pervasive view.
_SnackOverflow_@reddit
Yeah exactly. “Good” in my mind encompasses a lot of things that management (and bad devs) would like to skip
graystoning@reddit
Same.
It is a habit. I don't even think about it. I often have to loosen my standards when I know it doesn't matter
rayreaper@reddit
Yeah, that’s totally normal. I don’t think anyone writes "good" code all the time, most of us hack something together first and then clean it up later.
My approach is kinda: make it work, make it pretty, make it fast.
Sometimes if it’s a small, obvious change, I’ll just write it straight up. If I know exactly what I want and I’ve got tests in place, I’ll write the test and code until it passes. But honestly, most of the time I just bang out a messy first draft that does the job, and once it’s working I’ll circle back and ask, "okay, how do I make this not awful for the next person who reads it?"
Whatever4M@reddit (OP)
Definitely, but are you talking about mid way through writing the code, or are you talking about looking back at some stuff you've written in the past.
david-bohm@reddit
Both.
My biggest enemy is me from a couple of weeks ago. I don't know how many times I've looked at an older piece of code and thought "What idiot came up with this crazy idea?!". Guess who I'll find when I look into the Git history.
Also bad is a pretty flexible description. I'm as bold to say that the code isn't bad in the classical sense that it's not doing what it's supposed to do, it's not performant or has security holes in it... but simply not as good as I want it to be in terms of structure, clarity and "aesthetics". That's okay though. In hindsight everything looks easy and crystal clear.
farox@reddit
Then there is the question of how bad bad code really is. At the end of the day most of us work for companies that need to make profit for us to have a job.
And my theory is that lots of good companies run on shitty code. Some code bases are really infamous, like windows, but it made Microsoft what it is today.
On the other hand I have seen companies really suffer because they couldn't get features out, but had a pristine code base.
Finding the balance here is key. If no one is happy (business doesn't get their stuff fast enough, engineering doesn't have enough time to do it right) you're probably on the best path.
Wow, I'm bitter this morning...
sandspiegel@reddit
As someone who looks up at people like yourself and see you guys as role models for myself it is very interesting to read that these situations will never stop as I find myself in the same situations you described and I look back at old code of mine and think to myself "Who wrote this garbage?". I actually thought, that once I progress far enough years from now this will eventually go away, but I guess not.
Revision2000@reddit
I think it’s a good sign, because it’s means I’m still learning and evolving. I’d be worried if I ever reach a plateau.
Intelligent_Water_79@reddit
Ahhh yes "What idiot wrote this?: Check blame "Oh"
Whatever4M@reddit (OP)
I see. And yeah, same issue here, the code is 100% functional, just absolutely spaghetti.
yxhuvud@reddit
Also often you gain a much better understanding of something when you get back to it months after it was first written.
puremourning@reddit
2000%
es-ganso@reddit
Every time I look at my old code, I question whether my old self was really such a dumbass. So... Always?
SergeantPoopyWeiner@reddit
Almost every time when I am pressured to deliver way too fucking quickly.
Constant_Stock_6020@reddit
Me: who the fuck wrote this?
Oh. It was me.
super_lambda_lord@reddit
I've lost track of how many times I've seen a piece of code, been like "what asshole wrote this", and then realized that I, in fact, was the asshole.
MonochromeDinosaur@reddit
My first draft of everything I write is usually a horror show I would never want anyone to see EVER
mlitchard@reddit
I just did yesterday. Even though my architecture is beautiful I proceeded to break it. Even Claud expressed concern “this code breaks your design” uh sorry code my head was elsewhere.
stewart-mckee@reddit
I don’t, I let the AI do it for me now.
There are a few comments above that mention six months, I think that’s quite accurate. I would say about 10 to 20% of my code after about six months i’d like to rewrite
nNaz@reddit
Once in a blue moon. I prefer to do things the ‘right’ way and build on solid foundations as it leads to less work in the long run and, importantly, it feels more fun to me. When I prototype I’ll forgo handling certain errors and not adding telemetry/logging.
Sleepy_panther77@reddit
Everybody single time I write something I think it’s bad. But I just keep editing it until I feel like it’s better and… tolerable.
Mission_Cook_3401@reddit
Spend 5 years on perfecting the code, perfectly and the world will pass you by
YouDoHaveValue@reddit
Mostly when I'm under a deadline or I'm not sure we're even going to keep a feature.
And then of course what happens is it becomes a core part of the application that is tightly coupled with everything else 😅
mpanase@reddit
I don't always have amazing requirement definition and lots of time to get things done.
Make a guess.
n9iels@reddit
More often than I like to. Sometimes I need to write code that is already legacy before it even hits prod. Usually this is because I need to extends some old code and cleaning up would take way more effort compared to accepting it for that moment.
LordFlippy@reddit
My first draft is rarely inspired, but I guess it isn't really inherently bad. Most bad code doesn't become obvious until after some time when I've improved. Sounds like what you're describing is more like an MVP they allowed you to release instead of an actual full fledged solution. You going back into it now will be the solutioning.
I'd say that definitely happens and is normal, but maybe not best practice ;)
dual__88@reddit
A better question would have been "how often you write code you would describe as good?".
severoon@reddit
All the time.
How often do I submit code that is bad? Never.
homerdulu@reddit
All the time
rcls0053@reddit
You start with bad, you improve it and that's the cycle. Sometimes the improvement part comes after you've accumulated a bit more skill, but that's the cycle.
orlandoduran@reddit
Depends on when I’m describing it
nickelickelmouse@reddit
All the time. Honestly I’ve had so many projects cancelled/pivoted to hell that I won’t take extra time to do the last 10% type stuff until I know for sure the code is gonna be used in production with at least some level of regularity.
servermeta_net@reddit
Everyday. Who claims otherwise either never have written good code, or is unemployed.
For the sake of business we have to write bad code, as an experienced dev you lean to reduce the impact that bad code has on your codebase.
Then you can have your open source project where you only write good code.
failsafe-author@reddit
I am very curious about your definitions of good code and bad code.
servermeta_net@reddit
Code with a formal proof for correctness and lack of defects.
LEAN is the forefront of this, some crypto primitive libraries are getting this, Rust and strong type systems are a step towards this.
SmokyMetal060@reddit
Usually. Getting something down helps me think. It's prototyping. After I have a proof of concept and it holds up, I go back and make it good code.
TheMiracleLigament@reddit
Either 0% of the time or 100% of the time.
Acceptable-Fudge-816@reddit
Very often, but it's bad as in still better than some I've seen, so good enough.
RedBlueKoi@reddit
From 9 to 5 and then I can do my side project without corpo restrictions
OpeningMysterious739@reddit
I never write bad code… now.
In 6 months, it will probably be bad code. 😁
s0ulbrother@reddit
Someone messaged me on slack about an old project I was on about a couple lines of code. I told her not sure but I put a lot of comments there because i knew it was screwy. Code wise looking at it, it didn’t seem ideal but we had some weird business logic we needed to handle it.
I try not to write bad code but when I do it’s because of weird logic usually
it_happened_lol@reddit
Almost never. After enough YOE you generally find coding easy, easy enough to write immaculate code while churning it out quickly, and incrementally improving other code as I go.
If I'm working in a new language or problem domain this will come with a tradeoff of being slower, but it pays dividends in the long run since I'm making sure I have a strong foundation.
it_happened_lol@reddit
Also, generally people are going to say but the business requires poor code, there's not enough time. In my experience, this is not true. They dont make enough time. People mucking around in VScode with their mouse while not being able to touch type or take 60 seconds to find a file since are obviously going to take exponentially longer to code than someone who has memorized every single IDE shortcut needed to do their job as efficiently as possible. Coding is a learned skill.
MoveInteresting4334@reddit
I often write code that in six months I will describe as bad.
AakashGoGetEmAll@reddit
The first write is always all the use cases inside my head built up. Once I got that down, I just started structuring into a more readable format, breaking down the code into small chunks. Apply basic patterns like fail early. Add exceptions over it for exceptional cases etc etc.
The first write up is always bad, but it amps my speed up and helps me validate use cases.
BomberRURP@reddit
All the fucking time. And I don’t mean the humble brag “oh everything I write is bad a few months later because I’ve learned so much”.
I mean time pressure, shitty requirements, etc. sometimes you have to “get something out the door” and that means you don’t have the time to do a great job. We work in the context of a business and that’s what it leads to.
I hate the man but I think Musk was instrumental in breaking the whole mystique of FAANG being quality when he took over Twitter. Remember all the leaks of their internal code? Oh yeah baby they write over complex bowls of spaghetti shit like the rest of us
78fridaycrew@reddit
Always. Code is just expressing ideas in formal language. Most of the time, our thoughts are just unstructured and go through many iterations, getting better or worse with each on.
ivan0x32@reddit
You guys write good code?
Legal_Warthog_3451@reddit
It depends on what you mean by "bad". Does it look ugly, but it works? Then yeah, very normal and happens all the time - priority is to ship something that does the job. Write some tests for it, then refactor and improve til' looks neat - if you can afford the time. Code isn't ideal in most projects, most of the time; we all gotta learn how to live with it.
CallousBastard@reddit
I have a raging case of imposter syndrome, so I'm convinced that all the code I've written over the past 25 years is bad.
ReefNixon@reddit
All day err day baby
ButWhatIfPotato@reddit
All the time, but it was good enough given the circumstances at that time.
Cahnis@reddit
Imo that is the problem with agile, theres always people breathing on your neck pressuring you to release code fast.
mauriciocap@reddit
I copied from painters and sculptors the idea of "studies", a focused throwaway experiment to get something in your mind. You will find many from Michelangelo where he drafted toes and fingers from every angle until he got in his mind the clarity to paint e.g. the creation of Adam we all recognize immediately.
failsafe-author@reddit
It’s rarely a binary thing (good/bad). But I dislike it when it’s not my best.
I wrote my first Go app (that was used in production last year, and it bugs me out that it’s not the quality that I expect to produce from C# (which I have decades of experience in). But other developers who have worked in it say it’s good quality- that they had no difficulty picking things up and making changes. Still, I’m working on a new code base and this one is MUCH better (and I find I have to answer less questions about how things work).
The last time I truly wrote objectively bad code was likely over a decade ago.
humbleHam_@reddit
Always and never simultaneously
CartographerGold3168@reddit
very often.
why would you put so much heart into things that might be called bad or disposed whatever those people up there says? too much workhard in a thing that no one cares causes burnout. and those are not compensated
Cyhawk@reddit
Ya'll are writing good code?
Really, just the stuff on my public git. No job has ever given me enough time to write good code, just good enough code before being forced onto something else.
Wonderful_Device312@reddit
Every piece of code I wrote is bad. Every piece of code I'm writing is good. Weird how that works.
Blueson@reddit
Most of the times when we talk about bad code it usually grew from limitations, lack of understanding or just a completely different perspective of the problem that has changed with time.
We all write bad code, there's no escaping it. Sometimes it's actually just stupid code, but most of the time there's reason behind it.
Understanding that makes life a lot easier if you're in this career for the long term.
Professional_Mix2418@reddit
When I look back at it three months later? Every single time.
The point being, if you can’t improve and aren’t groenig you are not in the right game and not challenging yourself enough.
yxhuvud@reddit
I find it less to be personal growth and more to be that the first time i solve something it is just a brain dump of the problem space and of how I arrived to the solution, whereas when I come back to it I have to make the code tell a coherent story.
Professional_Mix2418@reddit
Yup, I can recognise that. And yes perhaps growth in 3 months is a little ambitious 🤣
Whatever4M@reddit (OP)
Fair enough, thanks for the insight.
syklemil@reddit
This sounds like it should go in the weekly ask experienced devs thread, plus this is such an incredibly common theme. Everyone experienced knows that as long as you're growing, you're going to find faults in your old code, and as long as you're on some sort of schedule or have more tasks to move on to, you're going to ship stuff in a state you're not satisfied with.
Whatever4M@reddit (OP)
I wouldn't describe myself as unexperienced, just haven't had this particular experience before.
syklemil@reddit
In three years?
Whatever4M@reddit (OP)
I have more than 3 years of experience, and I've written my share of bad code before but there was always an external reason for it, not this time.
syklemil@reddit
Alright, but this is really /r/ProgrammerHumor level stuff. I can't count the amount of jokes I've seen about people groaning at seeing their old code.
Even just visiting it now, one of the top posts is about it.
Spitfire_ex@reddit
Never wrote anything bad. They're just always WIP.
flavius-as@reddit
It depends on the abstraction level.
Not all bad code has an equally bad effect on the overall system design.
As long as the higher level abstractions are rather fine (or easy to refactor), then bad code in the details does not matter all that much, except for aspects like security and performance.
The non-negotiable though is to structure the bad code such that it can be easily refactored into something better, at a desired abstraction level.
For example: the Facade for this subsystem is well designed, but the code behind it needs refactoring.
As long as the abstraction level at which you choose to set this "pivot" in mindset is clear, and all other parties agree, then all good!
ForeverIntoTheLight@reddit
Depends.
If I'm working on something very new to me, it's better to write something quick that proves that my ideas actually work, then refine it into production-grade code.
Also, one should always keep learning. A side-effect of that is when one looks at code written a few years ago, and cringes over all the things that could've been done better... 😅
thekwoka@reddit
Not that often.
Mostly only when it's on a legacy code base, where it's bad primarily because of the old stuff that I am not interested in cleaning up at this time.
Or a game jam type of thing where it's just "make the thing cause there aint no time"
BogdanPradatu@reddit
everyday
Practical_Cup_6583@reddit
Bad code? Congrats, you’ve officially joined 99% of the industry.
The difference is only that some of us call it ‘MVP’ or ‘legacy code’ and ship it proudly.
If it works and you hate it later, that’s not failure, that’s just future-you’s problem.
NecessaryExpensive34@reddit
If you don’t write bad code probably you aren’t doing real work. But seriously there is code that is buggy and difficult to maintain, which is bad, but there are also suboptimal or inelegant implantations which don’t matter in the real world
aveihs56m@reddit
Test scripts and other automation scripts that I use for my personal use are usually terrible, so they work only for me on my system.
My first language is C, so when I write Python, my code "looks like" C and would make seasoned Python programmers cringe.
YahenP@reddit
There is no such thing as good code. There are no such things as good architectures. There is only a desire to write good code and design good architectures. And it is the desire to do things well, and an understanding of where, how, and why one will have to do things poorly that distinguishes a qualified programmer from an unqualified one. We constantly cut corners and compromise.
DeterminedQuokka@reddit
I have entire docs that are just lists of bad things that were purposefully put into various parts of the codebase. It’s always a trade off between time and quality. It’s usually around 60/40 for the compromise
Oktofon@reddit
It still happens. I guess the fact that you are reflecting over it makes you an experienced dev. You now have the knowledge and context to see what is bad. Did you make someone‘s day worse with your bad code? If not, learn what you can from it and just move on. Otherwise, offer to help.
Whatever4M@reddit (OP)
Ehh, not really. It is spaghetti but it is absolutely functional. It's likely that I'll clean it up before anyone ever needs to butt heads with it but still, it bruises the ego. And honestly I have the experience to know it's bad
Fidodo@reddit
The first try isn't always going to be good. That's why we prototype. First pass is to understand the problem, second pass is to do it right.
ButchersBoy@reddit
Bad code gives me the ick. Mistakes are made, often in hindsight some things could have been better... But all out "bad" code, no, even under pressure I try to write good code...
Honestly, not that often.
Whatever4M@reddit (OP)
Bravo, hopefully I get there eventually, any advice?
ButchersBoy@reddit
Yes. Write code. Reddit is full of people asking. The best people write code and ask less. Over and over again. It's ok to write shit code, especially if a few months later you start realising how much better you could have written it. Experience is what makes you grow.
In the world of AI, minimise it. Struggle, and get used to solving syntax and API issues. If you get a solution from AI, don't copy it in verbatim. Type it in, tweak it a little, step through it so YOU understand it.
Fidodo@reddit
AI is great at explaining things. The best way to use it is to ask for explanations instead of asking for solutions.
Fidodo@reddit
When you revisit code try to leave it better than it was and look for better cleaner abstractions. Even better, figure out safeguards to prevent it from getting bad again, like adding extra type safety or linter rules.
The very best practice is doing serious code review with a team that also cares about improving.
tanepiper@reddit
Writing bad code is like writing a letter to yourself about all the things you've found out, so future self can learn from it
Fidodo@reddit
I'm actually very proud of my code. I make controlled concessions all the time but it's very rare that I think it's bad. Of course go back a decade and it's a whole different story.
Relevant_Thought3154@reddit
We write code to move the business forward, so really good code mostly matters to engineers only. Business doesn't care about quality if bad code prints money.
So why spend time writing “perfect” code when, in most cases, it’s just validating a business idea?
And on top of that, why bother polishing code if your team is using AI anyway - which often produces far-from-ideal solutions?
DigThatData@reddit
all of my code is bad. it's just usually also good enough.
metekillot@reddit
The code I write for my own at-home tools and utilities is usually a mutant beast against god and nature. The code I write for collaborative projects is, conversely, a source of personal pride/arrogance and I'm constantly seeking to improve.
RedditIsBadButActive@reddit
I strive for working code if that's what we need (however I have my own minimum standards), and I strive for code that's "good" when:
• It's core code that needs to work and will be visited often by myself and other devs. • It's the beginning of a new project/module, since we're establishing patterns. • I'm working closely with a junior, I want them to learn to do things "well" otherwise I'll get another cargo cult programmer.
I do have another category, garbage code, which I will write when:
• It's a time critical patch, and we don't have the liberty of doing "best practice" • It's a one time task • It's code that's already very close to the deprecation path
Infectedinfested@reddit
Not really snippets of code, but more applications, i am the only SE on this microservice application, and i wish i had more time to properly do spec driven development, more unit test coverage, more environments than dev and prod 😅 might be the bane of startups.
Whatever4M@reddit (OP)
I see, but this sounds like an issue of deadlines due to having to move fast as a startup. Best of luck.
Infectedinfested@reddit
Definitely
vibes000111@reddit
In the moment - almost never. Very rarely I need to knowingly sacrifice quality for speed.
Retrospectively - very often. Past me had written a lot of garbage.
codescapes@reddit
I only write hacky code as part of a spike / proof of concept when I just want to see if something theoretically could work. Otherwise it's essentially never worth it for a real project you'll have to maintain. It feels bad, it takes longer to debug when things go wrong and it is professionally embarrassing to ask for peer review for.
That said, you can write hacky code in a bad way or a "good" way. The bad way is to riddle your code with improper cross dependencies, global state, God objects etc. The "good" way to write bad code is to ensure it's swept up into a clearly defined functions so at least all the shit is pushed into one corner.
It makes it easier to refactor e.g. really inefficient looping to do some calculation in the future if the name, input and output of the function all make sense it's just knowingly inefficiently written. For which I'd literally put a comment saying something like "brute force approach used here, Map of Maps would be more efficient".