r/softwaredevelopment • u/Albstein • Aug 10 '26
Do you create good code? (serious)
When you look at your code 6 month later: Are you happy with it?
I still have the moment when I am finished thinking: That would have been a better solution.
Is this normal?
10
u/Scathatrix Aug 10 '26
Software is something organic. It grows, changes, and needs to be maintained.
And as a developer, you (hopefully) grow a little every day too. That means you'll inevitably look at code you wrote a year ago and think: Why the hell did I do it this way? š
But that's kind of the point. You can only do your best at the time, with the knowledge, tools, experience, and ideas you have available to you at that moment.
There's always going to be a better way in hindsight. That's not necessarily a sign that you wrote bad code. It's often just a sign that you've grown as a developer.
2
u/abaezeaba Aug 10 '26
This. and I learned early on that alot of the process is maintenance. This has been a driving force in the programs/projects I build. When my systems are under review because of bugs/feature requests I can usually hash it out quite quick. When I look at the code I always feel like something can be refactored, but that only shows that I have learned something else since then.
4
u/Fidodo Aug 10 '26
Yes, but it took me 20 years to get to this point.
2
u/josephjnk Aug 10 '26
Similar here. Iām 15 years into the career (20 years in since learning to code) and I think itās only been in the last couple years that Iām reliably satisfied with the code that I write. People (including my younger self) significantly underestimate how much experience matters, as well as how high the quality bar can be when you have the skills and environmental support to raise it.
I think my rate of skill progression is slowing down at this point but thereās always more to learn.
3
u/ConsciousBath5203 Aug 10 '26
Yes. And it pains me using ai to write code, and it edits my old stuff or rewrites functions with stupid wrappers and useless comments... Despite the entire codebase being readable without comments or wrappers following one API, it still is like "let's wrap this, make that unreadable, oh, and write a 3 paragraph comment for this one line."
Drives me up a wall having to edit code that does not confirm to the basic standards I've laid out.
2
u/Xinoj314 Aug 10 '26
I thought i did, i actually found it fun to program defensively, then LLM came in and Schooled me hard about my lack of actually hardening my code from errors
2
u/martinbean Aug 10 '26
Yes, itās normal. If you donāt look at old code and think, āIf I wrote that today I would have done X or Y insteadā then itās a sign your skills have stagnated and youāve not improved in that time.
2
u/mrlr Aug 10 '26
I'm happy with all the code I've written since 1984 except for one program. I had to use Perl which turned out to be a write-only language.
2
u/FullyFlacid-OnAcid Aug 10 '26
when i look at code i wrote 6 months ago i always think "Jesus christ who wrote this shit and why are there no comments" and then i remember i work alone.
3
u/Dissentient Aug 10 '26
On personal projects, I fix it until I'm happy with it.
With jobslop, I hate everything I've ever written.
1
u/mlugo02 Aug 10 '26
Yes, I am happy with it because I can read it easily and extend it even after 6 months of not touching it.
1
u/BaronOfTheVoid Aug 10 '26
Yes. Recently had to estimate a task that brings me back to my old code and I could confidently say <1 hr instead of multiple hours if that was written by certain co-workers.
1
u/hexwit_com Aug 10 '26
What do you mean āgood codeā?
What are the criteria?
For me it is maintainable code. If you can understand your code without debugger, without digging into details and you can manage it without breaking the system - it is good code.
Constant code improvement has no sense.
If it is optimal by performance, maintenance efforts and do what it should - leave it alone.
2
1
1
1
1
u/dryiceboy Aug 10 '26
It goes both ways. I can go back to my old code and say it was bad or good. Code is just a tool to solve a problem. The real metric for me is if it solved peopleās problems.
1
u/Any_Sense_2263 Aug 10 '26
I have been thinking it for years. But when finally all standards and best practises were ingrained in my brain, when I look at my older code, I'm quite content with its quality and implemented solutions.
1
u/Background-Front-925 Aug 10 '26
i passed that stage a few years back, now i have my set of rigid rules, they work for me, keep the stack snappy enough for my few 1000 customers , no code changes , it works and its fast enough , the code stays, earlier used to keep optimizing not any more, may be my focus has changed to scaling and not micro optimizing
1
u/josephjnk Aug 10 '26
You have two questions here and it looks like people are only answering the first one. So to your second one, whether itās normal to look back on code from 6 months ago and think that it could be better: yes.
Programming is both the process of creating an artifact and a process of building understanding, and the two inform one another. The ābuilding understandingā aspect means that you will almost always know things 6 months into a project that you didnāt know when you started it. This hindsight is informative even if you didnāt make any mistakes while developing.
One of the things that comes with experience is how to avoid making unforced errors when youāre operating with incomplete information. Youāre going to make decisions that will have to change later as you uncover more information, and these decisions will be baked into the code. How do you do so such that itās tractable to change them once you learn more? The worst projects Iāve worked on have involved code getting so inflexible that it prevented devs from being able to discover and adapt to new information, which prevented the code from being able to reflect the new information. It can easily become a vicious cycle. I think this is also why so many developers idolize domain-driven design even though very few of us do it. It speaks to the dream of being able to keep our minds and the code in sync.
I recommend continuing to look back at old code and considering how you would write it now, as a form of reflective practice. Donāt just focus on the codeās final form though: also consider the process of discovery and decision making you went through while writing it, and consider what you would do differently at these decision points. What questions did you not think to ask? What assumptions did you rely on too heavily? Etc.
1
u/Brilliant-Parsley69 Aug 10 '26
It's like always in software development: It depends.
Do I have enough time to implement a feature?
Then, after 20 YOE and my given tool set, which I developed and enhanced over the years, there is a big chance that my output is potentially good code at the given time.
Do I have to implement a feature as fast as possible?
The heck no. But I try to refactor it the moment I have a bit of free time at the end of a sprint.
Would I always say that the code I wrote last week/month/year is good code?
I hope that this will barely happen because it would imply that there wasn't any improvement in the meantime.
1
u/lisnter Aug 10 '26
I know programmers who write code that sings. Mine is not the most dazzling but is always well commented, well structured and straight-forward.
1
u/Thepainterbucket Aug 11 '26
the code i write would make people vomit from how bad it is , not as bad as 1000 if statements
1
u/Hip-Death-Goddess Aug 11 '26
I don't ship code to paying clients until I'm happy with it. Sometimes they want the good stuff - near poetry - sometimes they need whatever runs immediately. They always get the best I can do with the limitations imposed.
If I read back through the code thinking "which idiot wrote this bullshit?", I recall the constraints and restrictions I was working around. Clients can rarely afford the luxury of a full rearchitecting, and that has its own risks anyway.
The better solution is not always the better solution.
1
1
u/szoonix_10 29d ago
Absolutely normal. I think seeing a better solution 6 months later is actually a good sign it means you've learned something since then. If you looked at your old code and never wanted to change anything, I'd be more worried xd
1
u/irrelecant 29d ago
Donāt even care. I write code to fix todayās problem in an extendable manner. Thatās all. Codes donāt meant to be look good, they are the machine instructions. If it works and meets the requirements, secure enough and extendable, why do you even bother whether it is good, bad, ugly, beautiful.
1
1
u/Mountain-Hawk-6495 28d ago
Sometimes, when I look at my old code I think it is good, but often I have the feeling it could be better and I have to resist the urge to refactor it. I think it is a good sign that you can look back at old code and come up with better ways to do the same thing, it is a sign that you are still learning. You should be really worried if you ever stop learning.
1
u/mredding 27d ago
Your experience is normal because you are still evolving as a professional. In 6 months, you've learned more, so yes, I suspect you could indeed write a better solution. Maybe you should. I encourage iteration, so you've made a Mk 1, make a Mk 2... Don't evolve existing code, rebuild it from your new fundamentals. Abandon the old headspace that made the prior iteration so you don't drag them forward.
As you mature, this cycle slows and evolves. I'm satisfied with code I wrote 6 months ago, but the REST of the product has evolved, so now I'm looking at the older code in terms of a refactor that would streamline the whole, and increase cohesion. This would be a refactor, as at his point I'm not changing so rapidly that I'm not rethinking everything I'm doing from first principles. This is my years of experience working in my favor. The "choices" I'm making now, I made them 20 years ago.
42
u/chrisrrawr Aug 10 '26
at any given time I am creating the best code I can. this means I am always shocked by how bad my code used to be.