Yeah, 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.
Who wrote this shit?
271–280 of 300 posts
Re: Who wrote this shit?
#272I 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…
I'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.
Re: Who wrote this shit?
#273Shit code is the code is not working, or not tested/ not covered by unit-tests. Everything else can go to production.
Re: Who wrote this shit?
#274Earlier quoted context omitted.
> 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 tha…
Staying 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.
Oh, 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!
Re: Who wrote this shit?
#275On 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 flak…
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…
A well-written commit message should explain "why", this may partially consist of linking to external things (bug tickets, whatever). Although it is probably important to have enough of a "why" that the reviewer can make an informed decision if they need to go check the external reference or can continue with the review as-is.
I ended up writing https://github.com/vatine/sressays/blob/main/change-requests... to try to clarify to myself what I thought a good change request ("PR", "CL", "CR", whatever you want to call them) needs.
Re: Who wrote this shit?
#276Many 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"…
If I felt my code from a year ago was still good, I'd be worried I've stopped learning and growing.
This only makes sense if one is junior or is learning a new programming language.
If one can’t write good code after several years of experience, then they’re in the wrong profession.
Re: Who wrote this shit?
#277Earlier quoted context omitted.
Always check git blame before winging out insults. Then, only blame people no longer at the company ;)
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...
... as a service... ;)
Re: Who wrote this shit?
#278I'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.
Re: Who wrote this shit?
#279I'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/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.
Re: Who wrote this shit?
#280Earlier quoted context omitted.
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.
> always just about 'good enough' to solve the issue at hand I've seen this approach really bite teams that only focus on the cost of implementing application behaviors rather than the long-term costs in terms of maintenance and systems complexity. If too many poor design decisions are made when a project is greenfield under the premise of "good enough" it can create technical debt so bad that the devs can't extricat…
> this approach really bite teams
Me too. But that is typically a problem with how they define "good enough". And how that evolves over time. If "good enough" means "what we decided on 7 years ago" or "It works on my machine" then certainly that term is not covering what it seems to cover.
"Good enough" should, obviously, take future maintainability, security, new hires, evolving standards, moving business-cases and changing markets into consideration: i.e. overall complexity, reusability, consistency, maintainability etc.
Or, to put it differenty: if your "Definition of Done" is not evolving or changing over time you can be sure that the "quality" part in that DoD is sub-par in a few years and your project development will grind to halt somewhere in the next years surely. (edit: that, or it is so vague and up to intepretation that any new hire or insight can change it already. Which may be a good thing, IDK)