[HN Gopher] Who wrote this shit?
___________________________________________________________________
Who wrote this shit?
Author : rhazn
Score : 380 points
Date : 2022-01-10 12:56 UTC (10 hours ago)
(HTM) web link (www.heltweg.org)
(TXT) w3m dump (www.heltweg.org)
| jraph wrote:
| Many 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.
| TameAntelope wrote:
| If I felt my code from a year ago was still good, I'd be
| worried I've stopped learning and growing.
| jraph wrote:
| I still don't get this. Not knowing everything I've learned
| for the past year did not prevent me to write clear code back
| then. I hope I'm writing better code now because I actively
| reflect on how to write correctly, but that does not prevent
| my old code to be reasonable.
|
| If I found my code from a year ago bad despite all these
| years of programming, I'd be worried I'm not in fact any
| good. The whole point of taking care to write good code is
| that it will still be readable and maintainable (i.e., good)
| in a year and more, and I'm sure I can achieve this, and
| could back then.
|
| I'm also able to recognize good code from other people from
| years ago, if I systematically thought my code from one year
| ago was bad, that would mean I'm consistently bad too.
|
| It just does not compute.
| TameAntelope wrote:
| I _was_ "not any good" relative to how much better I am
| now. I'm happy and fortunate that trajectory is continuing.
| Thirteen years and counting, in fact.
|
| Who knows, maybe you're a better coder than I am and you
| just "got" it instantly! It's immensely important for me to
| keep growing, so I guess it's a good thing I may be so much
| worse than you?
| jraph wrote:
| I'm not sure I'm above average and would not assume to be
| better than you, but you could be more self-critical than
| me.
|
| Few more years than you (it depends when to start
| counting), definitively in the same range.
| CrimsonRain wrote:
| You're not alone. I feel the same except when I wrote something
| that I didn't care about much. Those, I forget.
| michaelt wrote:
| I 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.
| [deleted]
| christkv wrote:
| Even more fun when you look ay the crap code and realize you
| wrote it :).
| MrDresden wrote:
| This 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._
| MoroCode wrote:
| This is why writing software is as much an art as it is a
| science. It is never perfect
| maguay wrote:
| Fits writing words as well, where you'll look back in your first
| blog posts a decade later and wonder who would write such things.
| ketanmaheshwari wrote:
| Feel 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.
| Ensorceled wrote:
| > Feel like there has been increasingly more cuss /
| inappropriate words showing up on top page of HN.
|
| I wouldn't consider the word "shit" to be inappropriate for a
| reader that I felt mature enough to expose to HN content and
| conversations.
| anthropodie wrote:
| Sounds like an opportunity for someone to create an extension
| that replaces these words with somethingm that would be good
| for kids.
| theshrike79 wrote:
| It's not as easy as you think:
| https://en.wikipedia.org/wiki/Scunthorpe_problem =)
| iqanq wrote:
| foxfluff wrote:
| clbuttic
| TheGigaChad wrote:
| Cthulhu_ wrote:
| Isn't there a minimum age requirement to be on HN? I mean I
| don't see anything obvious.
|
| That said, we're all adults here, mostly liberal leaning, and
| we all grew up with the internet; a bit of potty mouth won't
| hurt anyone. I mean you can take the moral high ground and
| consider anyone using swear words as immature and move on, I
| guess.
| kasey_junk wrote:
| I'm not worried about my kids seeing curse words. I am
| concerned about the downward pull normalizing unprofessional
| writing has on my profession.
|
| Does it make our whole environment less professional? Does it
| influence us to be unprofessional in other parts of our craft?
| Do outside observers view us as less a profession because of
| it?
|
| I don't know the answers but I certainly worry about it. Though
| perhaps I'm just aging out of this audience.
| TheGigaChad wrote:
| d1sxeyes wrote:
| I think there is something to worry about, but it's not
| 'unprofessional writing' or any kind of external downward
| pull, I'd say a lot of the problem is how much time
| professionals now spend in unprofessional contexts, even
| during working hours (he says, typing while clock-
| watching...).
|
| This is a post on someone's personal blog with some
| reflections on something they saw at work. I'm not sure why
| we should expect him to write professionally (leaving aside
| the question of whether swearing is acceptable in
| professional writing or not).
|
| I also wouldn't necessarily expect HN to only carry
| professional content - although some of what's shared here
| might be interesting from a professional viewpoint, it's not
| a portal for professionals (what even is 'hacker' as a
| profession? What percentage of the HN community are amateur
| hackers rather than professional hackers?).
|
| Ultimately, it's a discussion forum on the internet, where
| self-proclaimed hackers share things they think are cool, and
| if others think it's cool too, then it gets shown to more and
| more 'hackers' until not enough new people think it's cool
| enough, at which point it gets shown to fewer and fewer
| people.
| gostsamo wrote:
| Agree, the overuse of a word devalues its meaning. It shows
| certain lack of imagination as well.
| nameisname wrote:
| I recommend you no longer recommend content aggregation
| websites to people who you want to see only certain content.
| anthropodie wrote:
| Exactly 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.
| throw__away7391 wrote:
| This is a pretty entitled comment.
|
| I'd suggest that if you don't want kids to read the word "shit"
| you keep them off the Internet entirely for life rather than
| running around trying to impose your morality on everyone else.
| satyrnein wrote:
| He expressed a concern and said he's "not sure how to feel".
| Your response seems way over the top.
| gregd wrote:
| The 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 wrote:
| I think that's actually a great rule of thumb.
| nottorp wrote:
| Isnt cursing a requirement to make electronic/mechanical stuff
| perform as specced? Im pretty sure my computers overclock when
| cursed at.
| gregd wrote:
| This is kind of an odd viewpoint.
|
| Whether we spell "shit" or "s**t", you say the same word in
| your head.
| sudobash1 wrote:
| I 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.
| lbriner wrote:
| It 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.
| [deleted]
| treespace88 wrote:
| Thank 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 wrote:
| It'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.
| makach wrote:
| Usually yourself, you'll notice in a couple of weeks from now
| when you revisit your code.
| oxymoran wrote:
| In short, don't be an arrogant prick.
| leecommamichael wrote:
| I 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.
| Jenk wrote:
| I 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.
| joe8756438 wrote:
| I 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 wrote:
| I like the self-aware comment/plea of "FIXME".
| polishdude20 wrote:
| At 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."
| teddyh wrote:
| NB: It's "rite of passage", not "right of passage".
| rhazn wrote:
| Ah, today I learned something. Thank you for pointing that out,
| I corrected it. Seems like the title fits the post ;).
| skeeter2020 wrote:
| You're correct about the saying, but it actually feels like
| both when you think about it!
| Shish2k wrote:
| TBH 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."
| hprotagonist wrote:
| To 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 wrote:
| Write 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.
| jp57 wrote:
| You haven't been on the project very long if you've never run git
| blame and found your own name there.
| kgeist wrote:
| 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. 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 wrote:
| > 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.
| Yen wrote:
| On 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 wrote:
| Eh, 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 wrote:
| These 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.
| wruza wrote:
| The commit message idea always felt a little strange/off to
| me. It's a string that you can't (generally) fix/extend
| later for those who may seek this information. Also nobody
| except the committer can write them. (Imagine an explicit
| @docsguy role for documenting commits along with writing
| ticket-based documentation.)
|
| What if VCSs used a single file or a folder, like
| .gitcommits, where anyone could append any sort of info in
| _the same_ commit, so it could be a part of it. Then, when
| you commit a feature, you add to this file(-s):
| @@ @@ +--- +added websocket support to the
| server + /ws - main socket + /ws-events -
| events socket
|
| And few commits later you decide to extend it, editing the
| same record: @@ @@ +--- +added
| json-rpc over websockets + /ws-json-rpc
|
| And VCS would then extract these records at `git log`:
| ... 4509812 added websocket support to the server
| 0732691 <no .gitcommits message> 8712389 added json-
| rpc over websockets
|
| Few commits later you want to expand on json-rpc:
| @@ @@ --- -added json-rpc over websockets
| +added lifetime-related json-rpc over websockets
| +task: ./tasks/1873.md +supports 'start' and 'stop'
| methods: ./doc/ws-lifetime.md /ws-json-rpc @@
| @@ +--- +enhanced commit descriptions
| A tasks/1873.md A doc/ws-lifetime.md
| 4509812 added websocket support to the server 0732691
| <no .gitcommits message> 8712389 added lifetime-
| related json-rpc over websockets 6034007 enhanced
| commit descriptions
|
| Full commit messages would then be just diffs. Also, one
| could write a commit message gradually, with the sources
| they are modifying. Write two commit messages at once
| (because we all do commit two+ changes sometimes):
| @@ @@ +--- +refactored foo bar heavily, @docguy
| please expand +--- +fixed a bug in baz, didn't
| care to backport ... 0923423 refactored
| foo bar heavily, @docsguy please expand fixed
| a bug in baz, didn't care to backport
| u801e wrote:
| > 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.
|
| That works until the bug tracker goes down or the company
| decides to use a different bug tracker and the import doesn't
| preserve information, or the link in the commit message
| doesn't resolve to the corresponding ticket in the new bug
| tracker. This is far less likely to happen to the git history
| given that it's distributed.
|
| That being said, adding information to the merge commit
| message linking to the discussion or actually summarizing it
| in the commit message itself would definitely be an
| improvement. The merge commit has references to the commit
| the branch is based off of and the head commit of the branch,
| so you can limit git log output to just commits in the branch
| long after it has been merged.
| blindmute wrote:
| Am 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 wrote:
| No, 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.
| totally wrote:
| C'mon, man. You're better than Torben.
| remorses wrote:
| Who is Torben?
| anyfactor wrote:
| Nothing 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.
| sersi wrote:
| I 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.
| necovek wrote:
| I 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?
| jonathankoren wrote:
| Anymore 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."
| runjake wrote:
| I'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.
| jansommer wrote:
| I'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.
| jbgreer wrote:
| I 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.
| Havelock wrote:
| Negative bonding can be a fast way to feelings of camaraderie,
| but it can also cause resentment to fester.
| Cthulhu_ wrote:
| I'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.
| satyrnein wrote:
| _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._
|
| This is the danger of rewrites (assuming this was not actually
| greenlit as a 10 year project)!
| pacifika wrote:
| The trick is to declare it out of scope and bury the follow-
| up ticket.
| mekkkkkk wrote:
| I'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.
| skeeter2020 wrote:
| >> 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 wrote:
| Is this GIS code?
| [deleted]
| hdjjhhvvhga wrote:
| TLDR: Torben.
| ricardobayes wrote:
| Working 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'.
| honkycat wrote:
| I 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?"
| ipiz0618 wrote:
| I'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.
| hartator wrote:
| Sounds like a great company to work for.
| lettergram wrote:
| I 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.
| Pxtl wrote:
| Like the old joke:
|
| Debugging is like a murder mystery where you're simultaneously
| the investigator, the victim, and the murderer.
| donarb wrote:
| Or this:
|
| Code as if the next guy is a violent psychopath who knows your
| address.
| davidgerard wrote:
| There's little joy greater than finding a vast swathe of horrible
| code written by Past Me ("that asshole") and being able to delete
| it.
| Vaslo wrote:
| This 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.
| philliphaydon wrote:
| Haha 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.
| hirundo wrote:
| The 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
| FriedrichN wrote:
| If 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.
| donatj wrote:
| I have worked at my current gig long enough where the answer is
| almost always me,
| waynesonfire wrote:
| > 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!
| mod wrote:
| One 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.
| monkeynotes wrote:
| Did this in a startup, turned out to be the CEO's code and he was
| not happy. Not everyone understands the traditions.
| Grazester wrote:
| I 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.
| hutzlibu wrote:
| Ah 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
| not2b wrote:
| There 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 wrote:
| I 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.
| sealthedeal wrote:
| HERE, HERE!!!
| AtNightWeCode wrote:
| The Dunning-Kruger effect is real.
| [deleted]
| ezconnect wrote:
| I don't even want to look and debug my old code.
| JanSt wrote:
| Let'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)
| ChrisMarshallNY wrote:
| Great 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.
| smoyer wrote:
| It 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.
| wildzzz wrote:
| There's a bunch of little scripts I've had to write for my
| workflow. Time is short so I've taken parts and pieces from
| experiments, treated them as black boxes, and wrote interfaces
| to make them handle way more than I ever anticipated. It
| usually looks bad and has little useful documentation for the
| heavy math inside but it works and will work for years. I try
| to spend time on making the interface clear and friendly for
| anyone else that uses it after me but the internals are a nest
| of wires and obtuse mechanisms that I can barely remember how
| they work.
|
| We had an excel spreadsheet that was used for at least a decade
| to process some measurements. There were a lot of magic numbers
| shoved in the equations to handle some issues with the
| equipment along with math that I'm surprised Excel can handle.
| The results would be correct but it was a total black box but
| the steps to get to them were nearly incomprehensible. A
| coworker decided to spend some time upgrading it to Matlab to
| allow for some better interfacing with new test equipment we
| were buying. She thought it would take a week, it took months.
| Talking to the original author was useless as he couldn't
| remember how he built any of it. Finally she got it working
| with both the old and new test equipment and now has properly
| documented everything so it explains the use of any magic
| numbers. I did not envy that job at all.
| berkes wrote:
| I'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.
| hutzlibu wrote:
| I reached the same conclusion.
|
| I just would add, that the urge to refactor things whenever
| possible, definitely introduced bugs for me, because also
| refactoring has to be done with consideration and some things
| were weird for a reason, you do not see at first glance.
|
| And refactoring can also hurt you, or another person just
| used to that code in its old shape. And then
| missunderstanding things.
| berkes wrote:
| > definitely introduced bugs for me
|
| I'm an avid TDD developer. Red-green*refactor*. The latter,
| often overlooked, is IMO by far the most important part of
| TDD. But the _refactor_ is _only_ possible because of the
| tests you wrote, asserted, and tested (testing the tests)
| in the red-green phase.
|
| It gets hairy when a refactor needs to also refactor the
| tests - often a sign that the tests were lacking in the
| first place (and the more reason to refactor them). In
| which case I try to refactor them not in lock-step but
| decoupled: first refactor the tests without touching the
| SUT. Then refactor SUT (and then, most likely, another
| round of this)
|
| There is no fool-proof way. There will be bugs. There will
| be regressions. But that is a artifact of "change", not of
| refactoring. I'm also a believer in "never fix something
| that ain't broken". Which, unfortunately, only works for
| software that is not ever upgraded, has no dependencies,
| runs on hard- and software stacks that never change and has
| no changing business-needs ever. I.e.: non-existing
| software.
| hutzlibu wrote:
| One day I probably shift into TDD as well, as .. yes, I
| am not big on systematic testing. And that often hurt a
| lot.
| bumby wrote:
| > _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 wrote:
| > 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 wrote:
| I 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.
| shkkmo wrote:
| The point is that there is no one predefined "good
| enough", but rather the level of quality that code needs
| to reach is context dependent. That is why you end up
| constantly refactoring a little each time you touch the
| code as that context has usually shifted.
| duxup wrote:
| I 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?
| desireco42 wrote:
| I 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.
| jmartrican wrote:
| I shed a tear at the end.
| Toxygene wrote:
| The worst programmer I know is myself, six months ago. The most
| arrogant programmer I know is myself, in six months.
| allochthon wrote:
| Oh, 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.
| metadat wrote:
| > 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).
| CivBase wrote:
| I 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.
| trixie_ wrote:
| It'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 wrote:
| Comments shouldn't be the default way of documentation anyway.
| trixie_ wrote:
| For 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 wrote:
| All 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_ wrote:
| I 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.
| hutzlibu wrote:
| See, this is why comments are often so bad. They get
| ignored (and then forgotten) most of the time anyway.
| Like you did with my comment, where I explicitely stated,
| that I do write comments. Just less, than I used to.
|
| To which you just made a strawman argument of
|
| "Those two statements combined is your justification
| (excuse) for never writing comments and why the code you
| and people like you write is unmaintainable."
|
| You do not know me, nor my code - yet you judge about it,
| claiming it unmaintainable. Well, what more is there to
| comment on? Probably nothing.
| trixie_ wrote:
| You have some sort of defeatist attitude with comments
| saying they're ignored/forgotten. I wish I knew your life
| experience to see where this happened and how you formed
| this opinion. Is it because YOU ignored them and didn't
| update them with code changes? Or others did so and it
| got past a code review? You don't maintain your comments
| with your code, given your attitude it sounds like you
| don't.
|
| Your attitude in infectious. It causes new developers to
| have the same now unfounded opinions and not write
| comments themselves. The cycle of unmaintainable code
| continues.
| hutzlibu wrote:
| Erm, you realize that it was YOU, who ignored the
| essential parts of my comment, proofing my point?
| Apparently not.
|
| Otherwise, sure:
|
| "Is it because YOU ignored them and didn't update them
| with code changes? Or others did so and it got past a
| code review? "
|
| Both happened. And I doubt this never happened to you.
| And if it really never happened to you - then you either
| are a superhuman - or never had to ship lots of code with
| a tight deadline.
| trixie_ wrote:
| It does happen, but it is the exception and not the rule.
| If you're entire argument hinges on the exception case
| then I'd rethink your position.
| hutzlibu wrote:
| My entire argument is, on average there are way too many
| dead comments around and I would rather recommend to
| people using comments as exception where the code is not
| clear enough, to decrease the burden of maintaining them
| and rather focus to keep the proper higher level
| documentation up to date and readable.
| eps wrote:
| Asking _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 wrote:
| When 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 wrote:
| Often 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.
| kinduff wrote:
| Sometimes I say it, then I "git blame" it, and it was me.
| rozenmd wrote:
| My favourite is when you're a solopreneur working in your own
| repos and still asking yourself "who wrote this shit?!"
| ChrisMarshallNY wrote:
| I am working on a fairly ambitious project. It is in the stages
| where we are nearing the end, and the tofu is getting firmer.
|
| I had an issue, last week, where a bug was caused by an
| omission I left from an SDK that I wrote, maybe, eight years
| ago. It was a simple thing. I didn't add a "RefCon" to a server
| interaction, so I couldn't attach a reference context to a
| callback. This is a classic pattern, that I've used for
| decades, and I have no idea why the hell I didn't add it to
| this SDK. I suspect that it might be that the SDK was for a
| fairly wide audience, and I probably thought that they wouldn't
| understand it. So here I am, paying the price for
| underestimating my user base (which, so far, is Yours Truly).
|
| Anyway, the "fix" was to implement a semaphore, and treat the
| call as blocking, which is _awful_. I really need to go back
| and change the SDK, but that 's a fairly fundamental change,
| that I can't afford, right now (the SDK tofu is rock-hard).
|
| Such is the life of a shipping developer...
| mcv wrote:
| I 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 wrote:
| I 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.
| toxik wrote:
| Small claims court. It's not acceptable to not pay people
| accordingly.
| mcv wrote:
| I talked to a lawyer, and it just wasn't worth going
| after them for this amount. I wrote it off as a valuable
| lesson and went to make more money elsewhere.
| toxik wrote:
| You don't need a lawyer for small claims court as far as
| I know, just an FYI.
| dragonwriter wrote:
| Unless you are a citizen of the same state the
| corporation is, you'll need a lawyer when they file a
| removal petition to have the case moved to federal court
| on the basis of diversity jurisdiction.
|
| And if you don't consult a lawyer to prepare for small
| claims court, you stand a decent chance to be blindsided
| by that or something else.
| chris_wot wrote:
| Do it anyway. For them to hire a lawyer to determine
| this, then they have to pay quite a bit of money. It is
| quite possible they might be bluffed and pay up, or
| decide it is cheaper to pay up, and then actually pay up.
|
| If the initial action costs nothing, you have nothing to
| lose, but they will almost certainly lose something. If
| you do nothing it will cost you nothing also, but you
| have no chance of gaining anything at all.
| dragonwriter wrote:
| > For them to hire a lawyer to determine this
|
| They don't need to hire a lawyer to determine it, the
| junior paralegal in the in-house counsel's office with a
| checklist will do just fine, since all the information
| needed to make the determination will be on the papers
| they are served with.
|
| > If the initial action costs nothing, you have nothing
| to lose
|
| Not at all true; one of the other standard techniques for
| getting things out of small claims court is for the
| defendant to find anything about the interaction in
| question that they could countersue for that would raise
| the amount in controversy above the small claims limit
| (since the requirement for linked counterclaims to be
| handled in the same case and the small claims limit
| interact to requiring moving the case when this happens),
| even if it is something that they wouldn't sue over
| otherwise.
| mcv wrote:
| It's possible that the jurisdiction I live in works
| differently than yours.
| justinmchase wrote:
| On the other end, it's fun when you encounter a bug and go
| search for an answer and end up reading an answer on Stack
| Overflow that _you wrote_ 5 years ago and totally forgot about
| it.
| thecellardoor wrote:
| Seems like life goals
| HalcyonCowboy wrote:
| Haha, this happened to me for the first time recently. Asked
| a question, didn't get any answers, ended up updating my post
| with the answer I eventually found. Even had a couple of
| responses thanking me for the follow up. Five years later,
| ran into the same problem and forgot the answer, my answer
| was the top result on google.
| DiggyJohnson wrote:
| I was once looking to see if there were any projects or
| discussions regarding <insert niche domain> via the google
| search "<niche domain> Hacker News". I clicked on the top
| link because, read the comment, and was annoyed that it
| didn't actually address the <niche> things I wanted it to.
|
| Then I realized I wrote the comment. I didn't address the
| <niche> things because I was looking for it then and I'm
| stilling looking for it.
| someotherperson wrote:
| Equally fun is using a package or a part of it that you
| haven't used for a few years and going to read the docs for a
| certain feature... and realising you're the one that wrote
| those docs :)
| rob74 wrote:
| That's another old saying - you should try to make code
| readable not only for the sake of other developers who will
| work on it in the future, but also for your own sake...
| eddieroger wrote:
| I'm not a solopreneur but instead a corporate drone, and every
| time I git-blame questionable code, it's mine. But like others
| have said, if you're not embarrassed of something you wrote a
| year ago, that's not good.
| bitexploder wrote:
| I am usually embarrassed by my code of five minutes ago, but
| someone has to write it.
| pbalau wrote:
| After about 20 years of doing this (not particularly as a
| solopreneur), I understood the following: I sucked really bad
| yesterday compared to today and today I'm sucking so much more
| than I will tomorrow. And it makes me really happy that I can
| still say this. The moment I won't be able to say this anymore,
| is the moment I'm done and I can finally die.
| chris_wot wrote:
| Well, the fun thing is that at the moment you expire you can
| be sure that you sucked the least in your life but some young
| and inexperienced coder will still look at your code and ask
| "Who wrote that shit?" :-)
| klyrs wrote:
| Haha, yeah. My reaction to the title was "my past self,
| usually." I've seen utterly horrible code written by people who
| I consider myself leagues beneath. Sometimes git blame is a
| lesson in humility.
| Bedon292 wrote:
| While 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.
| sbarre wrote:
| I heard a saying once: "all developers should be embarrassed
| about code they wrote more than a year ago" as a (cheeky)
| measure of ongoing growth and development. :-)
| DarylZero wrote:
| I'm already on the decline sad to say.
|
| EDIT: Actually I feel like an aging chess GM -- better than
| younger at strategy, worse than younger at tactics.
| notreallyserio wrote:
| Jokes on me, I'm embarrassed about the code I'll be writing
| today!
| david422 wrote:
| I honestly find that kindof frustrating. I look at code I
| wrote a year ago and think - why didn't I do it this (better)
| way. And I also think - haven't I learned to write decent
| code by now? Why do I keep writing code like that when I
| should know how to write it better.
| DiggyJohnson wrote:
| I don't mean this sarcastically, you're probably an better
| coder than this comment implies, but what you described is
| the mind's mental content that _should_ motivate you to
| write "decent" code.
|
| Do you only feel this motivation when you look back at old
| projects? Perhaps the improvement could be in organization
| (code-level or otherwise) such that you do not feel lost or
| confused looking at your old stuff.
| pjerem wrote:
| Interestingly, I recently looked back at an old disk drive
| with my first "real" unfinished side-project which I started
| as a teen learning to code.
|
| And, to my surprise, it was not _that_ bad.
|
| Sure, it was full of naively implemented stuff that could
| have been implemented way better. But, even a decade and a
| half after, it was pretty clear to read, and it was decently
| organized.
|
| And, in some ways, I preferred this code to the one I'm
| writing professionally. I was honestly prouder of myself as a
| teen than myself as a professional programmer.
|
| The difference, I think, is that I had a clear idea of what I
| wanted to achieve for this project to be considered as
| definitely finished. Since I started working on code (for
| money) I've always been working on never ending projects.
| This industry (and me, as a professional) is obsessed in
| writing code for long term maintenance and evolution instead
| of effectively finishing products.
|
| So, to get back on topic, I'm not sure you really write
| better code with time. I mean, yes, you totally do, but it's
| not as important as learning how to code for others to be
| able to understand and modify it with constraints you can't
| even imagine.
|
| And I saw a lot of people writing super nice open source side
| project and then, when you work with them on some
| professional level, well, they still write the same shitty
| code as everyone else.
| Jerrrry wrote:
| If you think of your own thoughts in the past and cringe,
| then your brain has grown since then.
| DarylZero wrote:
| Usually I'm cringing about what I said 5 seconds ago.
| greenonions wrote:
| Quick delivery cycle
| stonemetal12 wrote:
| The code you wrote a year ago should have good points and
| bad. If it is just bad, then you either started programming a
| year ago, or should perhaps start thinking about changing
| jobs.
|
| If you are actually improving then there should be some good
| in there (you got better from two years ago right?). If you
| can't identify that good, then either you are just chasing
| fashion (that perfectly good construct from two years ago is
| now out of fashion so it is "bad"), or you haven't improved
| your ability to tell good code from bad and just calling it
| bad because you are unfamiliar with it.
|
| If you want to actually get better at code then you should do
| a real review of the code you wrote a year ago. Where did
| bugs occur in the code you wrote? Is there something that you
| could have done to make it less error prone? Is there code
| you wrote that is easy to understand? What design choices can
| you make so that more code ends up in the good code camp? How
| were the bugs detected? Can I integrate that in to what I do
| for testing? Then actively practice moving your code in the
| good direction and away from the bad.
|
| Anything less is chasing fashion and using familiarity as a
| good and unfamiliarity as bad. "As is" it is a pithy blog
| post for Coding Horror, but won't get you there. Pursuing
| greatness requires directed improvement
| lamontcg wrote:
| Or you were just constrained so you stopped well short of
| perfect.
| jnsaff2 wrote:
| Pretty funny, about 15 years ago I started looking back at
| myself a year ago and decided that until that dude from a
| year ago looks like an idiot then all is well with my life.
| Hasn't failed yet.
| CapmCrackaWaka wrote:
| I've seriously considered removing some of the older semi-
| popular projects from my github solely because I would be
| embarrassed to show them to a prospective employer, or even
| other developers.
|
| In the end I think it's actually kind of fun to look back
| through the code though, and think "surely I should have
| known about X back then... Why didn't I just do that
| instead."
| ocdtrekkie wrote:
| Remember that your repos and commits are dated. If someone
| looks at code that old... what they see is a trend of
| improvement.
| thecellardoor wrote:
| As someone who looks at GitHub accounts as a resume, I can
| tell you that improvement over time is amazing to see.
| Assuming it's clear what's most interesting or recent.
| lettergram wrote:
| Yup lol that's what teaches me that you need to do test driven
| development.
| [deleted]
| kwertyoowiyop wrote:
| "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.
| [deleted]
| linspace wrote:
| I have apologized to new hires I knew were going to work on my
| code
| recursivedoubts wrote:
| if current you isn't furious with previous you, you are doing
| development wrong
| datashaman wrote:
| previous 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.
| kylegill wrote:
| When 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.
| frebord wrote:
| "Torben had constraints I knew nothing about"
|
| Indeed a good point, the constraint of laziness and stupidity :P
| [deleted]
| bikingbismuth wrote:
| In 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 wrote:
| I'm currently rewriting the first application I wrote on my
| own.
|
| So much code to do pretty simple stuff... but it worked...
| matwood wrote:
| _Always_ check git blame before winging out insults. Then, only
| blame people no longer at the company ;)
| taocoyote wrote:
| Find incomprehensible code. Get email from blame. Search for
| them on Linkedin. If they are working as a developer in some
| senior capacity, then the code is probably a learning
| opportunity for me. If they are working as a scrum master
| code is probably as bad as it looks.
|
| I say this in jest, mostly...
| lostcolony wrote:
| I dunno; I've known horrible senior devs who wrote
| solutions that were clearly resume driven development who
| ended up as tech leads elsewhere when there was a regime
| change and actual scrutiny began to be applied to them.
| kingcharles wrote:
| This is standard development policy at every corporation I've
| worked at.
| terafo wrote:
| You should check out GitLens for VSCode, it makes the process
| of working with git blame seamless.
| wnoise wrote:
| https://github.com/jayphelps/git-blame-someone-else
| alexjplant wrote:
| I 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.
| sshine wrote:
| I also had that moment; ask "Who wrote that shit?", run 'git
| blame' and find yourself. This happened 1 year into my second
| job.
| rwoerz wrote:
| If you want to take that to the next level, accidently
| address an email to yourself and then complain that the
| "response" is all but helpful.
|
| I mean... that could happen... hypothetically... to...
| someone.
| Yajirobe wrote:
| It sometimes can be misleading. If I'm refactoring large
| parts of code (e.g. splitting a large file to smaller ones),
| then sometimes the original logic written by someone else
| will be left, but git blame will show me because I was the
| last to make changes
| abainbridge wrote:
| More than once I've googled how to do something new and found
| the answer on Stackoverflow, written by me. I haven't even
| written that many answers on Stackoverflow.
| DarylZero wrote:
| Well anyone would be pissed if the only documentation was
| written by some asshole on his first week.
| bikingbismuth wrote:
| Completely 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.
| golergka wrote:
| Always useful to keep in mind the concept of Chesterton's fence:
| https://fs.blog/chestertons-fence/ If something looks stupid or
| weird, you may not have all the relevant information to judge.
| Beltiras wrote:
| I was waiting for the punchline: I wrote this.
| simmerup wrote:
| Old code is easy to dunk on, because it's far easier to write new
| code than modify old code.
| NAHWheatCracker wrote:
| This 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 wrote:
| This 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 wrote:
| As they say, legacy code is the code you wrote before lunch.
| thenerdhead wrote:
| One 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.
| eerikkivistik wrote:
| I 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 wrote:
| Could 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 wrote:
| I suppose I have a long ways to go still :)
| fffobar wrote:
| Bonus points if you first ask yourself "who wrote this shit?",
| then open blame, then see your own name.
| dustymcp wrote:
| I love this
| SketchySeaBeast wrote:
| I 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 wrote:
| Same here. Sometimes I add comments like "don't change this
| shit!" to remind myself that there is a reason why it is like
| that.
| sudobash1 wrote:
| I prefer to add comments which contain some rational, like
| "Changing this causes race condition headaches in the
| frobulater." Or "Ugly... but it handles the edge case of
| XYZ in the foobar config"
|
| If I don't then the comments either have the effect of a)
| scaring future me, or b) getting ignored because I think
| that I can do better now.
| Mezzie wrote:
| Those comments would help if future me would listen to
| them. "Huh, I wonder why I put that in here... let's see
| what happens if I change that shit."
| SketchySeaBeast wrote:
| "I'm certain I've learned enough in the last 10 months to
| solve this problem now."
|
| "I did not."
| kwertyoowiyop wrote:
| The best thing is when you replace some shitty code with your own
| wonderful well-architected code...which causes a bug.
| jeanncoln wrote:
| I 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.
| physicles wrote:
| I 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 wrote:
| Any 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.
___________________________________________________________________
(page generated 2022-01-10 23:00 UTC)