I tell all the junior Devs: if you aren't horrified by something you wrote a year ago, you aren't learning fast enough. 20 years in and I still find things I wrote 8 months ago that I would not do again.
My favourite is when I go back to old code, think "why on earth was that written that way" and then proceed to rewrite it. Then after an half an hour in I realise that my rewrite is worse than the original method I used. At which point I promptly undo my changes then leave a comment for future self explaining why my superficially bad code works well.
Sadly those instances are fewer than those where my old bad code is literally just bad.
I don't mean this as a response to you personally, but instead to everyone who works this way.
We've been in this situation lots of times, where we'll write some code, then finish the solution after a few days or a week, then look at it a month later and say "Wow, this is really not a good way of doing it," only to spend another few days or weeks rewriting it.
The idea of spending 10 minutes drafting a solution, throwing it out, spending another 10 minutes on diagrams and guesses, throwing it out, typically gets met with "Just _code_ damnit," but, diagramming could compress months of rework into minutes.
You're not wrong and my programming style is very much like that albeit I use the code itself to diagram as I find that's easier for my brain to parse than flow charts. But effectively it's the same process of "sketching a design and throwing it out" cycle that you described.
I suspect quite a few developers who "just code damnit" follow this same process too. After all, it's not exactly hard to rewrite code and with tools like Git in place you can easily stash the different implementation methods so you're not having to lose any work during the cycles.
Usually when bad code gets written by experienced developers it's not so much because of a lack of willingness to conceptualise the design but often just because either the deadline is sufficiently tight that you are forced into writing a "quick fix" rather than something robust. Or because the code base is already an mess (due to the evolution of the product and the aforementioned issue of quick fixes) which means the "ideal world" solution is a significantly larger undertaking than it should be and best not undertaken while you have deadlines depending on it. Or sometimes you see "bad" code simply because the aim of the project is a minimum viable product or proof of concept, thus it's more about proving the product works as a concept than the implementation of it. In that scenario it can make a lot of sense to throw quick code at a problem with the understanding that chunks of the application will be revisited when you start to scale the product.
I do sketches both on paper, and in code. I write all my code in many, many drafts, so that by the time it ships each function has been rewritten. I'd guess about 5-10 times on average. Possibly contrary to intuition, I find this enables me to work much, much faster, and have far fewer defects than not doing it.
> My favourite is when I go back to old code, think "why on earth was that written that way" and then proceed to rewrite it. Then after an half an hour in I realise that my rewrite is worse than the original method I used.
...and remember that the "rewrite" is similar to an even older version that you temporarily forgot about.
As I've matured as a developer, I've taken to commenting much more heavily. However, I focus more on capturing why I'm doing something, which sometimes includes why I didn't do it a particular way.
Why vs What in comments is such a hard distinction to make, that I suspect many professional programmers never reach.
In my past few contracts, the devs at each shop fell cleanly into the overcommenting or never comment school of thought. Many old time C coders hate or love comments for exactly the opposite reasons as new grads writing Javascript or Ruby, and when conversing most argued that the code should explain itself. It is very hard to make code explain why because it is doing what it does, and this tiny nuance is hard to grab.
Just associating the code with a bug or feature request often helps the next guy intuit why you did something.
One job we kept reintroducing the same bugs and the customer was furious. I started reading the version histories more closely and figured out two developers were dueling over two separate bugs in the same block of code. Each would reintroduce the other' bug. Since then and due to some other experiences, I spend time looking at how the code arrived to deduce why it was the way it was. I pride myself on a low regression rate and this helps a lot.
Note that if you value quality over quantity, you're self
-selecting for writing less code but in more critical parts of the application, like libraries or cross cutting concerns like security or localization. And you also have to accept that if you insist that everyone on the team coded like you then nothing would ever get done. The last bit is, IME, the hardest part.
Once I had a situation where I was the developer assigned to a particular interface and my code was synonymous with the code.
Unbeknownst to me, a defect was entered and another programmer made a change. It wasn't really a bugfix but more like a change in the desired functionality. His change worked perfectly well but I wasn't made aware that someone else had changed the code. When I was assigned another defect, I used the version of the code that I had from my last checkout to make the change. When I checked in, I overwrote his change.
We quickly discovered this during testing and I reverted my change. I used his last checked in code as the basis for my change and all was right with the world but we had a confused user and two confused programmers for a couple of hours.
I'm surprised your version control solution let this situation arise considering this is exactly the kinds of problem version control aims to resolve. Usually you only hear of these things happening when you have multiple devs FTP / SFTPing files to a shared repository rather than following a managed check out and check in procedure via your preferred VCS frontend.
My father was a fairly well-known concert pianist in his day, who also taught students continually. Each week, he would be enthralled with a new practice technique or hand exercise he had arrived at. Last week's technique was abandoned, not mentioned again. My mother would mock this, implying that he must not know what he was doing, since he changed his mind so often about what works.
He explained to me that the exercises were not being abandoned at all. They were being refined gradually over time. He had one goal, which was improving the uptake and resilience of brain and muscle memory for music. Every refinement was an opportunity he'd spotted, deep in his own mental language, to hone in on that goal.
The way my coding style (both deep and superficial) changes continuously over time always reminds me of the way my father taught piano. My goal, roughly, is to find the perfect balance of clarity and brevity, while maximizing the ease of continued development. My 27 years of practice has resulted in a long chain of insights about how to achieve that. It's always changing. The way I wrote code 8 months ago wasn't wrong, but I found a set of principles that's better. It wasn't bad, but I would not write in that style today. Why would I? I've learned things in those 8 months.
I disagree, if you consistently think that the code you wrote a year ago is shit then you are probably just chasing a new fad every year. I'd say that if a junior developer with a year in a language doesn't write code he can rightfully be proud of then he is focusing on the wrong things.
Meh, I've been doing this for around 10 years now, and I dislike code I wrote yesterday. It's not wrong, it's just merely sufficient.
Why?
To paraphrase someone else: I wrote sufficient code because I didn't have the time to write good code.
There's always a better abstraction I could have teased out, a more complete refactor to make that one line hack never have to exist, and better documentation which would read more like English and less like shorthand.
25 years of C++ myself. Back in the 90s I coded up all the grossest memory management blunders many times over. Long time since I produced one of those; these days I'm capable of producing some exquisitely subtle synchronisation and threading bugs ;)
Much of the time what I'm learning today is how to write code that is obviously correct or obviously wrong to everyone who looks at it. It's not prima facie 'better' than the code I wrote before, but it's more likely for the original intent to survive multiple modifications by others, and emergency fixes are less dramatic.
The analogy I'm experimenting with now is stage performers for Opera or Musical productions. If you see them up close, such as video recording, they clearly 'overact'. They use exaggerated facial and arm expressions to project their performance far enough so the people in the middle or even the back can see what's going on. They are expanding the audience greatly, but admittedly at the expense of those closest to the action. But on the whole it's a better performance.
When I find bugs in my code, introduced by me or added by someone else, I think about how it looked before and try to determine if it was just a dumb mistake or whether I tricked them into it. Maybe I grouped the code oddly, or chose an unfortunate variable name that implied something else was going on. If it's the latter I think about whether I really want to use that pattern anymore. What's tricky is that everyone tries to make their code look like the existing code, so people may be copying the pattern thinking it'll get them a clean code review. If I think the problem is bad enough I may stop and refactor all the places it's used (it only works if you're really, really practiced at refactoring), otherwise I'll just make a note so stop doing that in the future. I might mention it in a team retro.
I want my code to be as plain as it can be and still get the job done. Indeed at this point I positively fume when a 'senior' developer writes clever code, because they should know by now this isn't about them and they're hurting the entire team trying to fluff up their own ego. Look how important I am that you need me to fix all the really hard bugs. Fuck that, and fuck your dazzling bullshit. The only thing that pisses me off more is a manager that thinks 'blame allocation' is a viable management style.
thank you, I say the same thing every time I see this come up.
That's a young mans game, after you've been doing this stuff long enough the things you learn are in terms of systems design, maintenance, etc. I regularly go back to code I wrote 2 and 3 years ago and think to myself "knowing what I know now, that code is mostly alright".
I can't understand how someone can go back and look at some authentication code, for example, and think the way they did it was horrible. Just how many different ways can you write auth code?
It's one thing if you're a young developer, but at some point the improvements to your code are negligible and have nothing to do with the value you bring to a project.
Where do you guys get a job without any time constraints? Also were you born with all knowledge? You are saying for example that the booking system you made in 2009, which was the first time you ever "programmed time" is pretty much perfect? (change the example to shaders, or physics, or your first Node back end blah blah). I am calling Bullshit.
I would think the ones who constantly go back and worry about old code are the ones you would accuse of having no time constraints.
The thing is, if you're going back to the first time you've ever "programmed time", then what you're assessing is design, not code, which falls in line with what I said.
Yes, the scale at which you notice problems with older code changes as you gain experience. i.e. you may have it down at a function or class level but then, at a system design level, or perhaps in the way that the code addresses business needs there will likely be improvements that you can see given the benefit of hindsight and experience.
I didn't say I still think my old code is horrible (well, some of it is). I said I wouldn't do it that way again. That's more like, "Well this is alright, I guess, but..."
I regularly ask interviewees at all levels, after they've talked me through some code they've written, how they would do it differently (emphasising that I always wish I'd done things differently). It's one of the questions I've found to be consistently helpful in finding out how a person thinks about making software
1. it's a good indication about how they think about improving existing code
2. it can show how they learn from what they do
3. it give them license to talk openly about mistakes (much better than a rote 'tell me about something that hasn't gone well' type question)
That's the best strategy. The most bug-free code is the one that wasn't written in the first place, therefore I refuse to write code unless absolutely necessary :).
Not to mention the best one for code coverage. When junior devs ask me for advice regarding increasing code coverage, I tell them instead of writing more tests, how about writing less code? Our boss really liked that one.
Unfortunately, I've seen IT departments taking this joke as an axiom. It seems common in schools and universities, where the infrastructure is maintained by being so limited as to be completely useless - and hence unused, and thus without problems caused by users...
One of my favorite tricks, that I sometimes play on myself:
Insist the person documents all the quirks and gotchas in a block of code or library. Sometimes the embarrassment at having to justify it will prompt them to fix the problem, other times they (or I) will realize that it literally takes less time to fix the issue than it does to apologize for it.
Something about the writing process unearths simpler solutions to tricky sounding problems. Possibly the same phenomenon that TDD tries to exploit.
Yeah absolutely. I always reduced this to "three months" and passed the phrase around to juniors, etc. And when I interviewed at the last company I worked for, the CEO specifically said, "If you aren't horrified by something you wrote three months ago..." And that's when I knew I wanted to work there (among many other reasons, of course).
I would worry that this would encourage more tech debt than I'm comfortable with. I already struggle with people shrugging off obviously predictable consequences of their thoughtlessness. I kind of expect people to at least attempt to think three months out. Who knows what we'll be doing in six but cmon.
Do you really look at code you wrote three months ago -- or any code you've just written -- and not see a lot of things you could improve? This isn't about not having foresight or failing to plan or not designing well.
Every time I am about to do a commit, I look at the code and give myself fifteen minutes to make it better. Always have (probably a habit I learned doing homework in college? I'm not quite sure).
In the grand scheme of things you'd hardly notice that it takes me a little bit longer. Over time those improvements become habituated and I just do a lot of them while I'm coding. Especially when I get stuck.
It's not in like cleaning while you cook. Once you have a tempo it hardly takes any longer to prepare the food but you don't leave yourself with a mess that discourages you from doing it again.
You seem to be implying that you only ever need fifteen minutes after any programming task to make all possible improvements that could ever happen to that code.
One of my favorite quotes, "the dev whose code I hate the most is me from 2-years ago."
One of the unfortunate outcomes of the job market encouraging job hopping for salary bumps is many new engineers don't get the opportunity to see the cost of their own mistakes.
The difference between a junior dev and a senior dev is that you already know it's ugly code and it's going to bite you some time in the future when you write it.
Or maybe they just had a decent feel for design already? I look back at some things I wrote in the first couple of years that I was coding, and it's actually pretty alright. Maybe a bit amateurish and not how I'd do it now, but not terrible. I can't be the only one like this.
> Maybe a bit amateurish and not how I'd do it now, but not terrible. I can't be the only one like this.
Not at all. I started my first real project in September 2015, had a release out by mid-November. And the code worked, really well. I was praised by users of the software for how reliable it seemed to be. Now, 15-16 months later, I can definitely see the warts - there's a lot of global state, some crackpot abstractions and if I ever want to add new features to it I'll have to do some spring cleaning. But at the same time... it still works. The design is appropriate enough for the needs of the project and its functionality.
Judging by some of the 'professional' code I've read over the years, I'd say that's not a particularly high bar...! At least if you're horrified by code you wrote, it shows you care, and that shows some promise :)
I concur. Especially if you define "professional" as "stuff people do at work, for money", the kind of code I saw in my career... well, it wasn't that much different from the code I was writing when I was 13.
I once had to implement "encryption" that consisted of rot13(base64(data)). The class ended up being named SecurityTheatreUtils, to ensure no one else in our team ends up thinking it does any actual encryption...