24 ms·
Who wrote this shit?
- jmartrican 5y agoI shed a tear at the end.
- christkv 5y agoEven more fun when you look ay the crap code and realize you wrote it :).
- honkycat 5y agoI always say: "Code happens." Software quality cannot be pinned to a single individual. Software quality emerges from your software development process. So, for me, it is more: "Who approved this shit?"
- democracy 5y agoYeah, nothing beats good documentation or comments - quite often you find some code that doesn't make any sense but you can see someone made quite an effort to do it in this particular way. You do your best to understand why it was done this way, but if the comments/bug tracker/wiki links/people with the context are not there - you just shrug and move on.
- Havelock 5y agoNegative bonding can be a fast way to feelings of camaraderie, but it can also cause resentment to fester.
- hprotagonist 5y agoTo Woods’ Maxim — “Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live” — I usually add the clause “and 90% of the time that maintainer will be future you!”
- moonchrome 5y agoWrite crap code, switch jobs and get 30-50% raise to maintain someone else's crap, rinse and repeat. I feel like a well paid janitor.
- philliphaydon 5y agoHaha I’ve been working at the same place for 9 years. Last year I came across some code and thought “who the fuck wrote this shit”. Looked at the history. I wrote it 7 years earlier. Always fun to dunk on old code but still appreciate it pays the bills.
- FriedrichN 5y agoIf you hang around long enough you'll end up with code you once wrote that was maybe a quick fix, maybe you thought it was brilliant, but now appears to you as a steaming pile of crap. Sometimes it may however still be the best solution but your future self was unable to figure out why because your former self was too lazy to properly document the code.
- hirundo 5y agoThe Margaritaville stages of debugging: 1. It's nobody's fault 2. It could be my fault 3. It's my own damn fault https://news.ycombinator.com/item?id=6478121 https://news.ycombinator.com/item?id=6478121
- rozenmd 5y agoMy favourite is when you're a solopreneur working in your own repos and still asking yourself "who wrote this shit?!"
- Bedon292 5y agoWhile I am not solo, I have still been around for longer than anyone and the primary maintainer of a few repos. I tend to skip straight to "WTF was I thinking", because if its weird it was definitely me.
- mcv 5y agoI once worked as a freelancer for a tiny company that at some point refused to pay me for one day of work. One of their reasons was that my code wasn't up to their standards. I could see in git that the code they complained about was actually written by their lead (and only) developer. They still didn't pay, though.
- PicassoCTs 5y agoI loved those moments, the work was done, you moved on, and they came with all the ammunition they collected to wiggle out of payments. The trick is to give them easily defuseable bad ammunition when they "sneak" around to collect. If you disassemble all their arguments and have emails were they were informed, you can trash them thoroughly. Unpayed though. Cause even good arguments cant help broke little shops.
- ketanmaheshwari 5y agoFeel like there has been increasingly more cuss / inappropriate words showing up on top page of HN. I recommend HN to my kids. Not that they are not exposed to these words online but I would rather not come this from their parent. Not sure how to feel.
- gregd 5y agoThe rules in our house are, the only bad words, are words used to hurt other people. Having said that, cussing is a rite of passage in our house. We all cuss like sailors.
- seanw444 5y agoI think that's actually a great rule of thumb.
- nameisname 5y agoI recommend you no longer recommend content aggregation websites to people who you want to see only certain content.
- anthropodie 5y agoExactly always prefer search over feeds Edit: To add more to this, feeds train our brain to consume content which we don't even need. Search on other hand is inherently required when we are working on something cool.
- anthropodie 5y agoSounds like an opportunity for someone to create an extension that replaces these words with somethingm that would be good for kids.
- theshrike79 5y agoIt's not as easy as you think: https://en.wikipedia.org/wiki/Scunthorpe_problem https://en.wikipedia.org/wiki/Scunthorpe_problem =)
- teddyh 5y agoNB: It’s “rite of passage”, not “right of passage”.
- rhazn 5y agoAh, today I learned something. Thank you for pointing that out, I corrected it. Seems like the title fits the post ;).
- skeeter2020 5y agoYou're correct about the saying, but it actually feels like both when you think about it!
- donatj 5y agoI have worked at my current gig long enough where the answer is almost always me,
- kinduff 5y agoSometimes I say it, then I "git blame" it, and it was me.
- deleted 5y ago[deleted]
- recursivedoubts 5y agoif current you isn't furious with previous you, you are doing development wrong
- datashaman 5y agoprevious you laid the groundwork for the work current you is doing. be kind. :P if current you is always considering future you, then previous you will no longer be the bad guy when future you becomes current you. tl;dr: pay it forward to your future self.
- eerikkivistik 5y agoI find it a refreshing experience to look at your own code from 10 years ago, or even 5 and think "Who wrote this shit?". If I ever look at some of my old code and feel good about it, that means I have failed to improve.
- Aperocky 5y agoCould have meant that you've reached the approximate upper bound of excellence in that particular piece of code. There are objective good code that are timeless, implementations that does not need another look or left few/no space to improve. Granted, it's a lot harder to do at larger scale.
- eerikkivistik 5y agoI suppose I have a long ways to go still :)
- fffobar 5y agoBonus points if you first ask yourself "who wrote this shit?", then open blame, then see your own name.
- dustymcp 5y agoI love this
- SketchySeaBeast 5y agoI find that half the time I'll wonder who wrote it, realize I wrote it, start to rework it, and then realize why I wrote it that way in the first time, add a comment and move on.
- marvinblum 5y agoSame here. Sometimes I add comments like "don't change this shit!" to remind myself that there is a reason why it is like that.
- oxymoran 5y agoIn short, don’t be an arrogant prick.
- jansommer 5y agoI've been annoyed by my own legacy code long enough to try really hard to make sure the features being asked for are REALLY needed, simplifying things as much as possible before going into code. That's usually where most of the code is removed - sometimes all of it.
- Cthulhu_ 5y agoI'm in a constant state of this in the codebase I inherited. The previous solo front-end developer was the manager of R&D so he couldn't be fired easily, he was the only person willing and sort of able to do front-end (PHP + JS/Dojo), he was super productive (most code was written in 2012/2013), but not a very competent or self-critical developer. Think a back-end that concatenates XML into a big global string over the span of thousands of lines of code, then passes it to a function that parses it and outputs it again as JSON. Think functions spanning a thousand lines with triple-nested switch/case and if/else blocks Think a front-end where JS is used to concatenate HTML, CSS and more nested JS together into a string Said front-end will save and reload the currently active page on change of any form field, and there's dozens of form fields across dozens of dialog screens. When I joined I was given free rein to rewrite it in the technologies I thought would suit best. It's been two years, at a stretch I'm about 20% of the way there. It's a project that needs one or two fully staffed development teams, but we have the budget for two people because our management resists faster growth or investments.
- skeeter2020 5y ago>> Think a back-end that concatenates XML into a big global string over the span of thousands of lines of code, then passes it to a function that parses it and outputs it again as JSON. If you squint hard enough this is cgi-bin
- iamthepieman 5y agoIs this GIS code?
- mekkkkkk 5y agoI'm talking out of my ass here, but it doesn't sound like you are trying to rewrite it, but rather refactor it in place. This often takes much longer than a proper rewrite in my experience.
- satyrnein 5y agoWhen I joined I was given free rein to rewrite it in the technologies I thought would suit best. It's been two years, at a stretch I'm about 20% of the way there. This is the danger of rewrites (assuming this was not actually greenlit as a 10 year project)!
- hdjjhhvvhga 5y agoTLDR: Torben.
- smoyer 5y agoIt was me ... several times I have found a bug or code smell and then been surprised that the I was the original author. For the last fifteen to twenty years, I've generally found looking at code I wrote six months ago equally distasteful. So now my default behavior is to assume the code met the business function at the time, acknowledge that I'm continuously improving in my craft and finally, gained a joy in spending part of my time doing maintenance programming.
- berkes 5y agoI'm a strong believer in continuous refactoring. Improve existing code when you touch it. Defer architectural choices untill the moment you have enough info. And leave cleaning up to the moment that it starts becoming messy, not before. That implies, code never is perfect. Not even good. But clunky, cobbled together, expermental or just plain stupid. But always just about 'good enough' to solve the issue at hand.
- bumby 5y ago>But always just about 'good enough' to solve the issue at hand. I think this is context dependent. I generally agree with this statement on relatively low-risk projects. The problem with "good enough" is that it often becomes a rationale for our cognitive biases to take the easier route. I don't want someone doing that on, say, safety-critical code. Maintaining high standards is a way of buffering against those cognitive biases.
- berkes 5y ago> context dependent Isn't that by definition what good enough means? That on safety critical code "good enough" is a very different level than on a throwaway-script?
- bumby 5y agoI suppose, but by that same token standards would be the definition of pre-defined "good enough". In my experience, the nebulous nature of the term is usually a means of rationalizing a sub-standard effort. The benefit of defining that threshold upfront is that it's hopefully more objective, before you let cognitive biases influence your decision making. It really comes down to understanding why the goalposts have moved. Is it because you have more information to reduce the uncertainty about the risks that standards are meant to be mitigate? If so, great! If not, it's a red flag you may be responding to something else that increases risk, like schedule or cost pressure.
- bikingbismuth 5y agoIn my first corporate job out of college (a NOC at an ISP) I was asked to update the documentation for troubleshooting quality of service issues. I checked our wiki for what was already there and it horrendous. I started to mentally thrash the person and was going to go confront them about it. When I checked the edit history I was greeted by a single edit and my username a week after I started the job. I learned a great deal of humility and compassion in that moment.
- duxup 5y agoI’m currently rewriting the first application I wrote on my own. So much code to do pretty simple stuff… but it worked…
- DarylZero 5y agoWell anyone would be pissed if the only documentation was written by some asshole on his first week.
- bikingbismuth 5y agoCompletely agree. My manager at the time thought it was a brilliant idea to have new people write the wiki when they started, because “they just learned the right way to do it from a senior person!”. This is not something I took with me into my own transition to management.
- alexjplant 5y agoI experienced this same moment when I was ~24 years old and digging through a codebase I'd written a few years prior after returning to a former employer. Once you've hit rock-bottom there's no place to go but up :P. I've subsequently noticed that those who are quickest to talk trash about nuanced engineering decisions and minor bugs are often the ones with the most fundamentally-indefensible coding practices (5000-line source files that throw innumerable compiler warnings, using deprecated frameworks, explicit silent failure modes, etc). Latent insecurity is a very real phenomenon.
- 5y ago
- simmerup 5y agoOld code is easy to dunk on, because it's far easier to write new code than modify old code.
- deleted 5y ago[deleted]
- MoroCode 5y agoThis is why writing software is as much an art as it is a science. It is never perfect
- makach 5y agoUsually yourself, you'll notice in a couple of weeks from now when you revisit your code.
- anyfactor 5y agoNothing can be more precise. I once had a complicated codebase and had a extremely friendly and downright great person walking me through that. There was some things that bothered me (of course - entry level and dunning kruger). But I never uttered a word, the dev was so technically competent and overall personable guy, I tried my best not to be a jerk. He might have his reasons because we sometimes get lazy yet the contribution we make goes beyond that day and stays forever in the codebase. That day I learned that, soft skills is the most important thing when it comes to interacting in a team. Suppress your feelings and think of the other guy. See beyond the code.
- Pxtl 5y agoLike the old joke: Debugging is like a murder mystery where you're simultaneously the investigator, the victim, and the murderer.
- donarb 5y agoOr this: Code as if the next guy is a violent psychopath who knows your address.
- ricardobayes 5y agoWorking for a startup I at least say it in a different way. 'It might be trash, but it's running and generating millions of dollars of value'.
- lettergram 5y agoI always try to approach all code, even my own code as “lets improve this”. I tell the junior developers to “Write code like you have to come back in a decade with no context” When mentoring I also suggest the most important quality is a “think skin and an open mind”. Your code always sucks. It’s a time -vs- constraint issue as the author mentions. As context changes, code must adapt. That’s why I’m not worried about AI any time soon.
- monkeynotes 5y agoDid this in a startup, turned out to be the CEO's code and he was not happy. Not everyone understands the traditions.
- Grazester 5y agoI sometimes call out my CFO at my company who still works on the codebase(very Spaghettis like). He is not a trained programmer but his code runs the company and we are the leaders in our industry. He apologises for his older work but without it I guess the company may not have existed in it current form. The also board thinks the codebase is a potential liability since it all Coldfusion.
- sealthedeal 5y agoHERE, HERE!!!
- AtNightWeCode 5y agoThe Dunning-Kruger effect is real.
- JanSt 5y agoLet's face it: often (a) getting it done is more important than (b) getting it right. Often (a) is not only faster but also is the only way to get to profitability. Unless you write code that is touched many times or is performance critical, (b) will only add costs in the short term. Even if you spend more time fixing (a) later, it's often worth it because it made more money than it costs to fix it or your company wouldn't even be there, if all code would have to be of type (b)
- desireco42 5y agoI was surprised you didn't find your name, because I did and it was like 6 months ago and for the life of me I couldn't understand why I did this stupid thing I did then. I found that usually code written around and after 4pm tends to be like that and generally try to avoid more serious stuff in late PM.
- CivBase 5y agoI think it is generally a sign of maturity when a developer recognizes the flaws with their software and desires to improve them rather than piling on new features. Cynically asking "who wrote this shit?" is probably not a very mature way of expressing that, though. In my experience, finger pointing does more harm than good. If a particular developer is consistently producing bad work that is hurting the project, that should be evident by reviews of their new work - not their legacy code. IMO once code has passed review and entered master/trunk/production it should be considered the team's code - not an individual's.
- eps 5y agoAsking who wrote this shit is useless. However asking "what is this shit" is a perfectly valid thing to do. There are good developers producing crap due to constraints. There are also other developers producing crap because they can't produce anything else or just don't give a damn. Being able to differentiate between the two is often helpful, hence the "what" question.
- mcv 5y agoWhen it's written by someone else, I start out assuming it's not shit at all, and I simply don't understand it yet. So I ask the person who wrote it (if available), and often they tell me it was a hack and please fix it.
- 0x445442 5y agoOften times the what is not known by anybody but the who and if you're lucky the who is still around to tell you. If they're not, quite often you screwed because that shit is the only place where the business rules are captured.
- kwertyoowiyop 5y ago“Not everything worth doing is worth doing well.” — Tom West, quoted by Tracy Kidder in The Soul of a New Machine (Modern Library, 1997). ISBN 0-679-60261-5 Previously cited on HN, but it’s a classic quote so worth citing again.
- kwertyoowiyop 5y agoThe best thing is when you replace some shitty code with your own wonderful well-architected code…which causes a bug.
- Jenk 5y agoI did some freelancing (of the "setup an ecommerce site on a vps with some customisation and plugins for mom-and-pop shop" variety) in the 90s. No big jobs just lots of small ones to make some beer money. The usual process was install osCommerce, add some extras, zip it all up and manually deploy it to a VPS and transfer the credentials to the owners. The work was mostly found by word of mouth so it wasn't unusual to get emails asking for assistance/to do work out of the blue. Had one such email to change an existing shop up a bit. Probably no more than a few days work. Received their credentials and ssh'd to the host machine to take a look. Scanning the source files of the plugins had me head scratching in a couple of places, decided this was compiled by someone terrible. Scrolled some more and saw the author's details. Oops. So that's how they got my email address.
- ipiz0618 5y agoI'm pretty sure the guy maintaining my code I wrote in my first (well, every...) job would get irritated at the style. Man, I can't even look at those trash now. I had the same expectations for other senior devs at my company when I started my new job and thought "why would they write such convoluted stuff?". Months later, I was writing similar code because I now know better.
- duxup 5y agoI wonder about folks who get upset about “Who wrote this shit?” Do they never read their own code? Or maybe they never see their own code?
- frebord 5y ago"Torben had constraints I knew nothing about" Indeed a good point, the constraint of laziness and stupidity :P
- NAHWheatCracker 5y agoThis is a good mind set to cultivate, but then I remember working on non-legacy projects. My current project was started in the middle of 2021. The same people have been working on it for 6 months. I've been working on a related project and shifted over at the beginning of the year. I know the constraints and there haven't been deadlines. The staff engineer decided to pick technology by what's cool. They haven't invested in development workflows. The infrastructure is held together manually by those who have admin access. Subsystems that need to communicate don't. I have much sympathy for legacy projects, but those projects got to where they are because people made poor decisions. My current project is well on it's way to being a legacy project in just 6 months. The team I'm on today doesn't say no to requirements and scope creep. They are too invested in tech and aren't adjusting. They don't cultivate truth about how parts of the project aren't coming together. I blame problems on leadership much more than I do on individual contributors. I wish the commit log included the tech lead and managers on the project when code was written.
- ballenf 5y agoThis field is growing so quickly the ratio of experienced to new devs is out of balance. It takes a critical mass of experienced devs on a team or in an org or the scenario you're in is the default. And even that critical mass won't be enough if leadership implicitly or explicitly reward shiny visible progress and ignores structural work and integrity. The experiences we've probably all seen of new buildings going up quickly and then looking like trash just a couple years later are great examples. The problem is that approach "works" during boom years because everyone can move on fast enough to make the problem someone else's.
- satyrnein 5y agoAs they say, legacy code is the code you wrote before lunch.
- thenerdhead 5y agoOne of my first jobs while in college was working on adding features to a VB6 application using .NET 2.0 interop. The developer who wrote the majority of the VB code passed away from cancer a couple years prior. There were many times where I would stop and think "who the hell would write this?", and then pause to reflect that the code I'm complaining about was likely written while in a completely different mindset & battles I had no idea about. That shut me up pretty quickly. We're human after all, and humans have many flaws.
- MrDresden 5y agoThis ofcourse mirrors my first years in the industry, as it does for most of us. However my moment of realization was when, two years into my career, I asked the question and found out it had been me. Here are my own personal views on the subject matter: I am not my code, and my code is not me. As time progresses, so will I. To become better. Never perfect.
- joe8756438 5y agoI get this. It's true, a lot of code is written and we don't know the circumstances that led to it. Those circumstances could have led to monstrosities -- I have created a good many myself. I try to empathize with those people and commits of the past. HOWEVER, sometimes we see things that no mess of external pressure and crazy circumstance could have produced. No, these gems are born out of individual madness (maybe I've even been lucky enough to produce some myself, one can hope). Example, no. But here's a clue: they are usually accompanied by an equally insane commit message. "Magic." "Kill me." "Why not?" or the ultimate "". One technique that helps me keep myself sane: every commit message should describe "why", everything else is in code. I like to think it prevents a lot of future problems.
- satyrnein 5y agoI like the self-aware comment/plea of "FIXME".
- hartator 5y agoSounds like a great company to work for.
- ChrisMarshallNY 5y agoGreat post! I am the main consumer of most of my legacy code, so I make sure to do the best job possible. Nevertheless, I always end up, wanting to rewrite it from scratch. I don't, and do the best I can, to make sure the product is of as high a quality as possible, and ship it.
- lbriner 5y agoIt is kind of mentioned in the article but I think a lot of developers don't realise that there isn't just good code and bad code, there is a whole spectrum and the position on this spectrum is dictated by skill, experience, time pressure, money pressure and shifting requirements (assuming you ever had any!). We pine for the perfect green field where all things are good but there are probably zero companies where all developers are expert, where the solutions are all unique and unambiguous, where the trade-off between maintainability/performance and speed of coding are all completely set in stone, where nothing has ever changed in strategy, framework, etc. where no framework update has ever broken something and needed some dirty hack to work around it, where you don't have managers come and go who are not 100% helpful or useful. So better to look forwards always. Don't try and fix what is there unless it needs changing to move forwards. A lot of the code I have wanted to rewrite in my current company will be toast in the next 2 years as we are writing new apps so just don't lose sleep over it.
- treespace88 5y agoThank you. Developers like you are few and far between. I find it painful when others devs constantly re write working code, instead of moving forward. It’s so easy to trash what is there. Very few have the maturity to work with existing code without complaint.
- runlevel1 5y agoIt's important to have empathy for those that came before you, but I do also try to be mindful of those that come after. A comment explaining "why?" A quick refactor of your patch to make it easier to understand. A small README update. Those kind of little things add up and pay dividends. Best write code with empathy for those that come after you -- including your future self.
- deleted 5y ago[deleted]
- ezconnect 5y agoI don't even want to look and debug my old code.
- sersi 5y agoI can't count the number of times I complained about the code I saw, did a git blame to see who the hell wrote that and then found my name in the commit logs.
- deleted 5y ago[deleted]
- Toxygene 5y agoThe worst programmer I know is myself, six months ago. The most arrogant programmer I know is myself, in six months.
- allochthon 5y agoOh, man. There's some bad code out there with my name on it. It took me years to move beyond the stage where my opinions meant more to me than those of my teammates. I am sad that I was such a boor for as long as I was.
- trixie_ 5y agoIt's an exhausting cycle of writing code, hiring new people who say it's shit, who write their own code that next year the new batch of hires says it's shit again and needs to be rewritten. Of course all of these developers are too good to write a comment because their code is so easy to read that it's 'self documenting'
- hutzlibu 5y agoComments shouldn't be the default way of documentation anyway.
- trixie_ 5y agoFor the programmers working with the code, it definitely should be, but please let me know if you think there is a better place for explanations of code functionality other than the code itself. People like you are the reason why code becomes unmaintainable. You think some document separate from the code is a substitute for comments? It is not, your code is not as good as you think it is. If you have an example on github of something commented the way you think is 'correct' please post it. I hope you're not confusing high level app documentation with code comments.
- hutzlibu 5y agoAll I did, was saying comments shouldn't be default for documentation. To which you reply with this. "People like you are the reason why code becomes unmaintainable." So ... what do you think, I could say of people like you and something with the internet? In any case, I use comments in code btw. But way less often nowdays. Because comments have a tendency to be ignored and still remain there, despite the code for that comment changed long ago or was even removed. That can happen with any documenation, sure - but comments are notorious for it. No comment is way better, than a wrong, missleading comment.
- trixie_ 5y agoI say 'people like you' because this isn't the first time I've heard arguments like, 'comments have a tendency to be ignored and still remain there' and 'No comment is way better, than a wrong, missleading comment'. Those two statements combined is your justification (excuse) for never writing comments and why the code you and people like you write is unmaintainable. Just write the damn comment. You're code isn't as good as you think it is. And no one can read your mind as to your intent when you set upon writing the code.
- deleted 5y ago[deleted]
- golergka 5y agoAlways useful to keep in mind the concept of Chesterton's fence: https://fs.blog/chestertons-fence/ https://fs.blog/chestertons-fence/ If something looks stupid or weird, you may not have all the relevant information to judge.
- Beltiras 5y agoI was waiting for the punchline: I wrote this.
- maguay 5y agoFits writing words as well, where you’ll look back in your first blog posts a decade later and wonder who would write such things.
- Shish2k 5y agoTBH this is a big motivator for my code comments - “Ideally this code would do X, but because of constraint Y we are settling for Z. If you can think of a way to achieve X without the compromise then by all means burn this module with fire, and add me as a code reviewer so we can celebrate together.”
- kgeist 5y agoWe have a rule that if you have to leave shit code as it is for a serious reason (time constraints, shifting requirements) you must leave a TODO in the code which poins to a freshly created issue in the tracker which explains what's wrong with the code and how it can be fixed. The ideal is that these issues eventually get fixed, which is often not the case (new features are prioritized over tech debt etc.), but at least new devs will immediately see that it's a known problem and that there're known solutions.
- KronisLV 5y ago> We have a rule that if you have to leave shit code as it is for a serious reason (time constraints, shifting requirements) you must leave a TODO in the code which poins to a freshly created issue in the tracker which explains what's wrong with the code and how it can be fixed. This seems like a really sane thing to do! In addition, if you want to keep track of the commits and the context behind them, i've found that merge/pull request descriptions are also really nice for this! Back when i had to struggle with an Eldritch DB schema that someone wrote and had to patch in new functionality, i ended up painstakingly mapping out how it corresponded to the business concepts/objects (which was pretty loosely) and threw that diagram into the merge request, because sadly otherwise the schema still wasn't all that clear... ...just to have that very same diagram save my hide when i had to go back to it months later to update some of the code, which necessitated rediscovering how everything works. Now, whether things belong in the issue tracker or somewhere that's more close to the code repo is probably just a cultural question, but i'd say the main thing is to have some place to store information like that.
- physicles 5y agoStaying close to the code where possible always wins, I think. One code base I worked in had a particularly complex state machine, and right above its main function was a giant ascii art diagram of said state machine. It was perfect documentation.
- KronisLV 5y agoOh, definitely! I've had similarly positive experiences with temporal algebra - having some simple explanatory graphics of how two time spans would overlap is really nice!
- davidgerard 5y agoThere's little joy greater than finding a vast swathe of horrible code written by Past Me ("that asshole") and being able to delete it.
- not2b 5y agoThere is a risk if you stay in one place (or work on the same FOSS codebase) too long, because the answer to "who wrote this shit" often turns out to be "wow, what was I thinking?"
- bytebln 5y agoI maintain an analytics tool for a large newspaper. I wrote the code for it in PHP 13 years ago. The app has been running without interruption for 13 years and is used by hundreds of employees every day. Still, it needs a bit of maintenance (APIs change). The code is scary and I will probably maintain the project for the rest of my life because anyone else would pull their hair out. I'm not proud of it and write better code in the meantime, but rewriting all the code from 13 years ago would be way too expensive for the company.
- jeanncoln 5y agoI love how I was kind of relatable to this one. It's just that quick gig made me realize how far I have become since I started this journey.
- englebert 5y agoThe are several insidious problems with trashing code are: 1. It becomes an impulse and ends up cropping up in places where code is not just perceived as shit, but also misunderstood. And once devs aren’t taking the time to fully understand code before judging it all is lost. 2. It takes mental resources to form the useless judgment and clouds the vision with its bias once it is made. Suddenly it’s more difficult to see the nuanced angles in the code since you’ve got a useless judgement taking up mental space and resources. 3. Again it’s habit forming and becomes a barrier to thinking freshly and creatively when faced with new code. 4. It’s negative. 5. As seen here in all the comments it is rediculously faulty. 6. ALL old code gets to be shit with varying degrees of speed. ALL code bases get old. If you want to work on an old codebase, it comes with the territory. You can be a grumpy old man about it, you can be a grumpy old man about anything, but the net effect is just making you a grumpier shittier developer. In a similar way I have some coworkers who I know do not code as well because they don’t have the patience to be detail-oriented or pursue optimal solutions by any measure from code efficiency to maintainability. That’s about the worst thing I can think of to say about another programmer… and here’s the thing, they still occasionally write solutions borne of their own perspectives that I can learn from, their code still needs to be maintained, they sometimes do improve etc. If I let the author factor in I’m still going to miss things even if the prejudgment is right 90% of the time. Finally, I think it is healthy to like people and find the good in them even if they are paddling against the boat, if you can’t lift them up or fire them it’s making the best of the situation. If you can understand that they are humans with their own things going on, that other humans could look at you exactly the same way, I think it lifts us all up. This is my first HackerNews comment. EDIT: Formatting. See previous line.
- jraph 5y agoMany people in this thread are saying they are surprised by their own shitty code, 6 month ago. I read this everywhere on the Web. It's like I should myself be finding my code from 6 months ago horrible. I don't know. I tend to remember what code I wrote, and recognize my own code when seeing it, even years later. My code from 6 months ago looks good to me. My code from 10 years ago looks "reasonable, if a bit messy". I remember what I was trying to achieve with what level of knowledge I had, and often what I had in mind at this moment (sometimes including unrelated feelings). I'd probably write this code differently today and it's clear I learned things in the meantime, but a little bit of linting helps turn this code into "reasonable, if a bit less messy" (mainly limiting line length). I definitely find my way in this code and even find it kind of enjoyable. Sure, there are some details I don't remember but things are mostly here. Do I have an exceptional memory, an exceptional tolerance to execrable code or both? Re: the article, I've definitely felt "who wrote this shit" but I'm past it. Most surprising things have an explanation and this explanation should be sought before the final verdict… which is often not needed anyway. It's just a negative feeling that achieves nothing.
- michaelt 5y agoI suspect everyone was writing badly informed code at one point - just for some of us it was a long time ago, and we were young. For example, I wrote a javascript image editor that stored images as hex strings internally, and saved them to file by screenshotting them. Completely mad design. But that was ~23 years ago, long forgotten by everyone except me, and I was age 14 at the time. This is a young and growing industry; someone who coded like a 14-year-old ten years ago might simply be a 24 year old today.
- CrimsonRain 5y agoYou're not alone. I feel the same except when I wrote something that I didn't care about much. Those, I forget.
- TameAntelope 5y agoIf I felt my code from a year ago was still good, I'd be worried I've stopped learning and growing.
- necovek 5y agoI usually say that when I am pretty positive it was my code that's now... shit :) Unfortunately, I was still warned that this may portray an atmosphere of non-acceptance when done in "public" channels since readers might not be aware that this was my code and that I am making a self-deprecating remark. Honestly, I am not sure whether to keep doing it or not. I like the relaxed and jovial atmosphere that comes out of it (it's more of a joke that all of our past code is shit, and ultimately, that what we are writing today is the shit of tomorrow), but I struggle to come to peace with the PC crowd. Am I really messing it up for someone else?
- hutzlibu 5y agoAh yes, one of the first things I learned when working on my own big code base: I can no longer blame those other idiots for their stupid design decisions. Because suddenly it is all on me. And that probably made me actually grow as a developer. Because I write good code. I write bad code. Depending on the time of day, my mental condition and external pressures. The same like everyone else. And I also was once placed in front of a half finished but abandoned PHP project, for me to finish it. That surely was no fun. That code was not good. And I was stressed and angry with it. But today I would no longer direct my anger at that actual person. He also just did, what he could with the given ressources. And venting anger might be therapeutic in some instances, but I am not sure, it helps get stuff done. And it definitely makes for a bad social dynamic. So anyway, related dilbert comic: https://dilbert.com/strip/2013-02-24 https://dilbert.com/strip/2013-02-24
- physicles 5y agoI had a nearly identical experience a few months after starting my first job out of college. Huge software firm. I was looking through code with a senior colleague, and something looked really off to me. I literally said something like, "How could the person who wrote this be so stupid?" My colleague replied calmly,, "I wouldn't presume to know the mental capacity or state of the person who wrote this code at the moment they wrote it." What he said humbled me and I basically never said anything like that ever again. I also had the opposite experience. Two years in, wrote some code for a library that I thought was pretty clever. One day I got pulled into an online chat with a couple principal devs -- phenomenal engineers, respected the hell out of them -- and one was asking the other about this piece of code. He said something like, "Who wrote this shit? It's so complicated, I can't figure it out." So from that moment I understood that you have to be careful not to be too clever when you write code. Changed my life. To this day I'm so grateful to have had such amazing, patient mentors early in my career.
- bitexploder 5y agoAny time you start having negative sentiment, anywhere in life, directed at the creations of other humans or the humans themselves I have two phrases I use. Four words. Be humble. Be curious. It’s saved me a lot of angst. I think as a developer this is a great mindset, it has helped me a lot, at least.
- polishdude20 5y agoAt the end of writing a feature, I always think "I know this is shit, I know there is a better way to do this, but I did what I could with the resources I had."
- leecommamichael 5y agoI love this post. At some point we all figure out that if every line of code was perfect, the computer wouldn’t do very much at all.
- blindmute 5y agoAm I the only one who just... writes good code? I look back on code from when I was a junior and sure, it's bad. But code from 4 years ago? It's still perfectly fine. I don't believe that it's normal for long-time seniors to think their code from only a year ago is consistently bad, yet there are a lot of comments in here to that effect.
- psyc 5y agoNo, you're not the only one. It's just generally not advisable to say so here (or worse, on Reddit) because the bucket-crabs will getcha. FWIW, I did write atrocious code when I was 16. But I'm in my 40's now.
- linspace 5y agoI have apologized to new hires I knew were going to work on my code
- Vaslo 5y agoThis is also true outside of this in functions like finance. We inherited an important spreadsheet from the contingent finance team brought in to hold things together while the company went through a structural transition. The spreadsheets were horrible - bad logic, lots of “Easter eggs”(points where people hard coded a number in a sea of formulas number where you would have excepted a calculation which is very hard to catch), and just overall poor incremental design that didn’t take much into account except to fix an immediate problem. It was a pain but all the collective griping and work to improve it made us stronger as a group and also made us way better excel designers.
- sudobash1 5y agoI was working on some markdown related code years ago, and didn't test against utf-8 characters. I put a comment in there saying as much, and "I hope this doesn't come back to bite me." Sure enough, a few years later, I was diagnosing a bug in this software, and realized it only happened in documents with some utf-8 in them. After digging a while, I found that comment.
- totally 5y agoC'mon, man. You're better than Torben.
- deleted 5y ago[deleted]
- Yen 5y agoOn the topic of "who wrote this shit", I'd really like to plug the idea that some of the most high-impact documentation you can write is a good commit message. Say you track down a bug, find a line of code that makes no sense, and `git blame` it, to discover that you wrote it yourself, 2 years ago. If the commit message is "bugfix flaky builds", good luck figuring it out. If the commit subject rather, is "bugfix flaky builds", followed by a message that explains what the flakiness was, why you think the change will fix it, what other bugs or limitations you were working around, and what upstream changes you might be waiting on that prevented further work, you're in a much better position. Suddenly you have a lot more context on what you were doing, why you were doing it, why you didn't do it better at the time, and in some cases it can even catch you from making an obvious but subtly-wrong mis-step. Similarly, if someone's confused by your code during code review, that's a great opportunity for either in-line comments, or commit messages, as appropriate. Unlike PR discussions, tickets, emails, slack threads, wiki pages, or photos of whiteboards, commit messages + git blame has an uncanny ability to be exactly the documentation you need exactly when you need it. Good git history practice can be one of the highest returning investments.
- lostcolony 5y agoEh, I'm not sure I agree. What has gotten me the most value is having either the branch or the commit message tie back to a ticket somewhere. -That- has the original bug, the comment thread that led to the decision around why this particular fix, any additional comments around tradeoffs we were aware of, and what other options we dispensed with, etc. A well written commit message might explain what the issue was, but it won't have anywhere near the context the ticket and resulting comment thread should have.
- V-2 5y agoThese two aren't mutually exclusive. Tickets, however, have lower long-term survivability (in my experience). Outsourcing, migrations, there are many scenarios in which the original tickets become inaccessible over time - and some codebases do last for years and years. Meanwhile the repository content (and thus the complete version history) usually survives as-is.
- jonathankoren 5y agoAnymore when I find something stupid in the codebase, I close my eyes and say what’ve taken to calling the Engineer’s Serenity Prayer: “It was the right decision at the time.”
- waynesonfire 5y ago> legacy software is written by people like me legacy software or shit software? The two are not the same. So be clear with your statement, to circle it back to your intro, you're the creator of the _shit software_ -- right? That's what this is about? See how difficult it is to admit it. You couldn't even do it and you're writing the blog post about it. The ego is strong. But, I guess you're on the path towards this acceptance, you kinda semi-admitted to it. You have much more work to do but one day you'll finally understand this distinction and it'll be good for you and all the folks that have to maintain your shit. Keep improving your critical thinking and software engineering skills. The buck ends up with you. It's your choice what you produce and your standard of excellence. And you know what, it may be the case that the sooner you become a manager the better for everyone. That may also be a tough pill to swallow but fear not, you'll be happier... and also some content for a future blog post!
- jp57 5y agoYou haven't been on the project very long if you've never run git blame and found your own name there.
- runjake 5y agoI've had this exact experience, except I didn't see Torben's name, I saw my own name. And there was no excuse about deadlines and whatnot, I was just awful. 10 years from now, I'll be saying the same about the code I write now. And that's okay.
- jbgreer 5y agoI have often said to other devs that if you write code long enough, you’ll eventually find some crusty piece of your own code that will make you want to throw up.
- metadat 5y ago> Who wrote this shit? In both my personal and professional lives, when this comes up or I have the thought, way too often the answer is: I did. Sorry for the attempt at humor (though I certainly find it both tragic, upsetting, and amusing, it's also 100% true).
- kylegill 5y agoWhen I was the first engineer at one job my manager (who joined after I did) anticipated others saying this kind of thing about me, and told me to always remember that "the reason any of us engineers have jobs is because of your code". It's a good reminder, and I appreciate others taking care to build others up.
- remorses 5y agoWho is Torben?
- mod 5y agoOne of us! The most prolific writer of absolutely shit legacy code, in my experience, was always me. I was happy I had evolved to at least be able to recognize it as shit. Sometimes I didn't yet have a better idea! Sometimes I knew it was shit when I committed it, too. Deadlines, frustration, tip-toes, and maybe even imposter syndrome contribute to that.
- divbzero 5y agoAt one of my early software engineering jobs, my team was generous enough to entrust me with building a fairly complex component from start to finish. What I made worked reliably but the underlying code was spaghetti. I hope they felt no qualms about trashing it and have had an opportunity to refactor it since.
- SLWW 5y agoI have a healthy habit of just assuming that if something is bad then i probably wrote it. That way once you realize it's someone else's fault you feel slightly relieved and less prone to talk poorly about them. It's self-deprecating sure, but I've never been a believer in the whole "believe in yourself"/pro-self-esteem mindset, if you are mentally strong enough it really doesn't have an impact on how you operate or think. There's always something more brilliant, and more stupid then you are; that poor deadline based decision has been made by both you and the person who wrote that piece of crap code. We are all the same (barring some exceptions). Though I will say, I hate what modern program "design" has become, anytime someone mentions "sprints" you know that any maintenance you do on that codebase will be a fight uphill the whole way, there's no excuse other then an exec wanted something in half the time, just to have the poor sods that come after to be doomed to poor progress reports for months after trying to fix that garbage code they are tasked to maintain.
- valyagolev 5y agoI love legacy software so much - all the trouble and care I put into making sure it continues to work while I fix and improve it, is like operating on a live patient. I see no point in judging; I like to dig and to understand the particular choices. Seeing how much trouble companies have with legacy code, I tried to market myself as a consultant around those kinds of problem: say, adapting a legacy system for a more reliable and pleasant development process, or things like this. Unfortunately I found that it’s a hard work institutionally. Even where I found gratitude and respect of my people whose quality of life working with the software in question improved, I still was plagued by the problems of blame-assignment and career-making but futile huge rewrites orchestrated by people for whom destroying my work and denying its value was highly beneficial. I don’t know, I burnt out on this last time so hard I’ve been taking kind of a vacation. As much as I love sustainable software development, it’s a losing battle and probably a futile goal in most of the industry. I’m just trying to accept this and move on.
- jamesfinlayson 5y agoI've found a love for legacy code too - after working on a greenfield project and seeing it slowly but surely turn to rubbish, making bad old code good again is a net positive.
- czhu12 5y agoWhen I was a junior engineer a long time ago. I wrote a change that someone approved, and merged. A few weeks later a senior engineer saw the code in passing, proceeded to rewrite all of it, submitted a PR with a 2 page description tearing into the original code. Explaining why it was terrible and unacceptable and then posted the PR into our it into our team's slack channel with some comment like: "@here everyone please read this PR as an example of terrible engineering" The code was indeed quite poor, and the lessons were valuable, and I took them to heart. I also spent the next 18 months actively avoiding requesting feedback, in fear of this happening again. I think as a senior, this kind of behavior tends to really leave a lasting impact on starry eyed juniors. Something to keep in mind.
- teaearlgraycold 5y agoSounds like an incredibly toxic work culture. A manager should have stepped in to shut that senior engineer down once that got posted to Slack.
- Mandatum 5y agoIf someone did this on my team, I'd publicly tear into them if I wasn't their manager for being not just unprofessional, but cruel. If I was their manager, they'd be forced to apologize for how it was handled to the person with myself and HR on the call, and then I'd force them to read a productive feedback book. I'd also expect they quit. I usually find people overly cruel at work are especially insecure and in need of counseling. Usually something else driving that behaviour. Most people aren't just assholes.
- throwawaythekey 5y agoI once tried to do regular postings of 'funny bits of code' in the slack at my company. It was mostly meant to be in jest, but also had the side aim of trying to get the team to aim higher. The first few editions were snippets of my own code. I got a few token lols from other devs. I then saw a senior had committed what looked like a gem... something obviously contorted but fairly short and understandable for if they were coding on autopiliot `if day.isWeekday() && !day.isWeekend() && day.isMonday() { // this is a monday` The day I posted that to slack was the day I learned never to criticize in public, even non-personally and even in jest.
- EdwardDiego 5y agoSomething I've always tried to drill into ambitious intermediate devs - you're writing the legacy shit of tomorrow, today! And when you're a senior, the next generation of ambitious intermediate devs will wonder aloud at wtf you were thinking when you wrote it, and it's just part of the software developer maturity cycle. Code-bases grow through different phases along with the company - there's the "we need to ship the MVP, so just comment that out" codebase, then there's the "we're starting to understand the problem domain better" phase, followed by the "I just read a book by Martin Fowler/Uncle Bob, and I'm going to fix all the things", then the "wait, the problem domain is hairier than we thought, let's iterate on this", then perhaps, depending on company dynamics, the "a charismatic senior developer convinced enough people to use <technology X>, so we started moving towards it" followed somewhat later by "well, the senior dev left, and everyone decided that X was bollocks" moving away... Or perhaps the entire model of the system changed. Your batch ETL pipeline delivered yesterday's data in time for start of today's business, and that was fine for a few years, but now the sales team want today's data refreshed twice a day, hang on actually, we want it updated every hour, now we want it updated within five minutes. Code written for old paradigms always look crap when all you know is the new paradigm.
- dhosek 5y agoIf you've not looked at code, said who wrote this shit, then did a git blame and saw your name next to it, you've not really done serious programming.
- WalterBright 5y agoI once was challenged on who authored a game (Empire) that another was claiming to have written. The person who was judging this turned to a particularly messy section, and asked the other guy to explain it. He mumbled and stumbled. I could, and why it was so weird. The other guy caved and apologized.
- dshpala 5y agoI've been dealing with legacy part of our app for the couple of days now, and I'm pissed. But not at the code, I fully understand how code can become hairy, deadlines can be tight, etc. No. I'm pissed at my team (I'm new) who didn't have time in the past 5 years to even attempt to clean this shit up.
- kayodelycaon 5y agoIn the jobs I’ve had, management is response for not allocating time for maintenance. It’s difficult to justify allocating that time without the numbers on a spreadsheet to prove it’s needed.
- democracy 5y agoShit code is the code is not working, or not tested/ not covered by unit-tests. Everything else can go to production.
- maccard 5y agoI've got similar stories to others here about dunking on code/documentation that it turns out I wrote. These days I try to assume that I wrote all of the bad code and just can't remember why. Doesn't always work, but tends to take the edge off my sassiness.
- trwhite 5y agoI've written about this and some of the ideas being discussed here. Essays that I'm reasonably proud of: https://notoriousbfg.com/building-software-sharing-knowledge https://notoriousbfg.com/building-software-sharing-knowledge https://notoriousbfg.com/code-and-context https://notoriousbfg.com/code-and-context TLDR: I don't think that poorly written code is as common as devs like to thing it is. Context is just as important in our general perception of how well some code has been written/designed. There are several ways we can and should document our code including descriptive variable and method names, commit messages, tests and PR comments.
- spiralx 5y agoDo not do this to the CTO about their own code is a lesson I learnt painfully many years ago. And today as a technical lead there's far too much wince-worthy code I come across that I was personally responsible for a few years back. Onwards and upwards.
- danielyaa5 5y agoAlso just because someone’s on the blame didn’t mean they wrote it. They maybe refactored