261–270 of 300 posts
I'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.
When 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 ple…
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.
Earlier quoted context omitted.
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.
I was once looking to see if there were any projects or discussions regarding via the google search " Hacker News". I clicked on the top link because, read the comment, and was annoyed that it didn't actually address the things I wanted it to. Then I realized I wrote the comment. I didn't address the things because I was looking for it then and I'm stilling looking for it.
Earlier quoted context omitted.
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. :-)
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 cod…
Like when you learn a natural language's vocabulary, but you still need to figure what conjunctions of words are not intelligible or natural phrases to fluent speakers. Phrases that have ambiguous meanings or otherwise generate confusion.
I think there's a comparable notion of fluency in programming that goes what most people mean they say they're fluent in a programming language.
Earlier quoted context omitted.
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.
I disagree. There are lots of examples of standards that define what is "good enough." For example, NASA has different standards depending on risk categorization and the predefined threshold of quality gradually gets higher as the use gets riskier. A business application is held to a much lower level of quality than software for a robotic mission which is lower than a human rated development effort.
We are laying out an approach to software development, refactoring, and a model for how to view old code that you some acroas that seems bad.
You seem to be stuck on the term "good enough" and arguing semantics that don't make sense. Yes, sometimes there are standards. that you need to meet. Sometimes just meeting the offical standard is not "good enough", and you need to do more. "Good enough" is inherently contextual, and you seem to agree with this, but seem still be arguing against using that term?
Earlier quoted context omitted.
I was once looking to see if there were any projects or discussions regarding via the google search " Hacker News". I clicked on the top link because, read the comment, and was annoyed that it didn't actually address the things I wanted it to. Then I realized I wrote the comment. I didn't address the things because I was looking for it then and I'm stilling looking for it.
Well now I want to know what is!
Let's submit ideas! I'll start
He wanted to learn about using Machine Learning to predict how often his pet dog would need to go to the bathroom
Earlier quoted context omitted.
I fixed a bug the other day that I was so embarrassed about, I intentionally left the commit message cryptic. (It was a personal project.) Sometimes the best documentation is seared into your soul as a mark of shame. I think I’ll wake up a few times wincing about it.
A team I worked with had a fun little habit I have since borrowed: you add a "BOGUS" comment next to the offending line. Sort of like: // BOGUS: assuming 'x' will never be greater than 1024. Sort of tells future engineers, yeah, I know it's shit.
A comment I left that I am sometimes reminded of by ex-coworkers still at that company.
Earlier quoted context omitted.
I also had that moment; ask “Who wrote that shit?”, run ‘git blame’ and find yourself. This happened 1 year into my second job.
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.
Earlier quoted context omitted.
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…
I've never used git-notes, but it sounds like this is what you are describing: https://git-scm.com/docs/git-notes
Earlier quoted context omitted.
I didn't mean to imply they were mutually exclusive; just that in terms of "most high-impact documentation you can write", I find ensuring I link the ticket higher than making sure I have a thoughtful commit message, for the reasons listed. Fair that it can disappear eventually if you change ticket trackers or whatever; that's a risk of changing ticket trackers. Hopefully you maintain both for a bit, and once you're…
> But just in terms of "what would I rather have", a link to the ticket every time In practice over the past 20+ years, I've had to rely on commit messages far more than tickets, but a well-written ticket is defnitely awesome to have. When I ran Engineering for a startup, one of the things we invested a lot of time in was making sure commits had good messages, tickets had good writeups, and the two were linked. We re…
I went through 5 different CVSs and the history was gone forever in each migration - but actually JIRA is still the same after 16 years )))