Absolute truths I unlearned as junior developer • Hacker News Board

Re: Absolute truths I unlearned as junior developer

#431

Post by Udik » Fri, Jun 07, 2019, 11:35 PM UTC

docker_up wrote: post #67

Overall a good article, but I completely disagree with the notion that "good enough is good enough". I've been in a lot of code reviews where developers push back because it's "good enough". You need to maintain a defined level of quality otherwise codebases go to shit very, very fast. I was recently told in a code review that a Cassandra read before a write (to ensure there were no duplicates) was "good enough" beca…

> "good enough" because a duplicate "probably wouldn't happen very often". Meanwhile, the consequences of a dupe would lead to a pretty bad customer experience. [...] My bar is much higher than this developer...

I see a lot of posturing in this anecdote, what I think is missing are:

1 - an indication of how often would a customer experience the issue;

2 - how bad would his "bad experience" be;

Did you calculate the former and took in account the latter in forming your judgement?

Or, otherwise, was the "correct" solution simple and obvious enough that any non-junior developer would have picked that first without hesitation?

Re: Absolute truths I unlearned as junior developer

#432

Post by mpolsz » Fri, Jun 07, 2019, 11:46 PM UTC

Sharlin wrote: post #251

enobrev wrote: post #170

Earlier quoted context omitted.

> code that I wrote myself is hard to read This has happened more times than it probably should: 1. Arrive upon some code I wrote at some point in the near or distant past. 2. Review it to get some idea of what I was trying to do 3. Laugh at my young self for being so naive 4. Refactor or Rewrite 5. Re-realize the edge-cases and difficulties 6. Remember this being a problem 7. Refactor And Rewrite 8. Either `git rese…

This is probably the primary actual use case for comments. Explain why something is done the way it is; to justify to those who come after why Chesterton's Fence [1] should apply in this case. [1] https://wiki.lesswrong.com/wiki/Chesterton%27s_Fence

That someone being me not knowing why in hell would I write this monstrosity... git blame + some archeology work to get jira ticket number (I put issue numbers in commit message/branch name) and from that I know why.

Re: Absolute truths I unlearned as junior developer

#433

Post by Rapzid » Sat, Jun 08, 2019, 12:04 AM UTC

mywittyname wrote: post #392

lmm wrote: post #168

Earlier quoted context omitted.

> If you still believe this, then - to be brutally honest - I would question the quality of the team's you've worked with. To be equally brutally honest: right back at you. I would trust the quality of those I've worked with over those who believe in comments, any day of the week. My point was simply that I started as a believer in comments when I was more junior, and became anti-comment through experience. So even i…

> code can be much more precise and clear than English, This doesn't address the parent's criticism. Clear, precise code only tells you what the computer is doing. What it can never tell you is why the computer needs to do it exactly like that. Software breaks in weird ways when pushed to the limits. The fixes for these edge cases are not always obvious and may not be something that can be replicated with testing. Wi…

This is my problem as with this argument as well. English and other spoken languages seem first and foremost about conveying ideas. Programming languages seem first and foremost about conveying instructions to computers that don't comprehend "ideas"..

Reconstructing the original idea or meaning can often involve far more context than local variable and functioning naming can provide.

Re: Absolute truths I unlearned as junior developer

#434

Post by jayd16 » Sat, Jun 08, 2019, 12:15 AM UTC

AnimalMuppet wrote: post #390

jayd16 wrote: post #384

Earlier quoted context omitted.

Tests might make you personally feel safer making changes but they are not Agile(tm) because they attempt to predict needs instead solving an explicit existing need. They violate YAGNI and worse there is work in removing and rewriting old tests.

I see absolutely nothing in the Agile Manifesto that precludes tests. Nor do I see any basis for saying that tests attempt to predict needs. They are for the future, true, but they're also for the present - as is every line of code you write.

>Nor do I see any basis for saying that tests attempt to predict needs

The prediction is that the next time you revisit this code your original assumptions will still be valid. In games, which is my background, game rules (our business logic) are constantly changing during development to the point that you're fighting tests constantly for no benefit. Games are an extreme case but you can extrapolate the experience.

You've already admitted that there is a point when tests are not worthwhile when you are iterating. My argument is simply that in my experience you're in that state more often than not. Ultimately user value is the only thing that matters and tests don't predict that.

And I'm not saying you're not allowed to write tests. If something helps you do it. I'm arguing against code coverage and test enforcement.

Re: Absolute truths I unlearned as junior developer

#435

Post by heelix » Sat, Jun 08, 2019, 12:17 AM UTC

harrisreynolds wrote: post #336

Tade0 wrote: post #289

Earlier quoted context omitted.

Here's what happened to me(A) and a friend(B) from a former workplace of mine(open-source project): B: Take a look at this shit code that I found. A: Whoah, it really is shit. Blame it so that we can see what kind of genious is behind this. B: ... A: Well? B: Apparently you wrote and I reviewed/approved it.

This is really funny. So good. I ask all the time, "Who wrote this shit??" knowing it was probably me.

Honestly, this is usually a good sign. I'll code at the edge of my current skill. Six months from now, I hope I can look at that code and consider it primitive from where I hope to be then.

Re: Absolute truths I unlearned as junior developer

#436

Post by drbojingle » Sat, Jun 08, 2019, 12:24 AM UTC

neetodavid wrote: post #279

drbojingle wrote: post #240

Earlier quoted context omitted.

I agree with you but I can't bear to say code doesn't matter. Try not writing any and see how valuable software is without it. Better yet, delete it and see what happens :D. I expect Codeless will become a thing one day but, until that day comes you will write code, because the code is necessary and I have trouble saying that the code is needed but also doesn't matter. Least important necessity maybe?

I've read on this website about people launching minimum viable products that appear to the customer to be some kind of automated service that in reality are the owner manually satisfying the order. The software isn't necessarily what the customer values. You can provide a valuable service with 0 LOC

What tool makes them, and what's the tool made out of? You go back far enough, someone had to write code for something. You're not wrong though but it sounds like a domain specific thing too. Vending Machine as a service essentially. Still, as long as people are writing code it'll be because there's no choice but to write it for their use case.

Re: Absolute truths I unlearned as junior developer

#437

Post by parasubvert » Sat, Jun 08, 2019, 12:27 AM UTC

chasd00 wrote: post #409

A good plan violently executed now is better than a perfect plan executed next week. - Patton It's much better to get something, anything, on the screen and working than an elegant design constantly refined but never put to actual use.

Not just "anything". Patton did say a "good" plan. A bad plan can tank you just as much as elegant design that isn't used.

Re: Absolute truths I unlearned as junior developer

#438

Post by grogenaut » Sat, Jun 08, 2019, 12:56 AM UTC

pfranz wrote: post #355

eitland wrote: post #324

Earlier quoted context omitted.

Which is why I am trying to get better at what I used to to: writing down and sharing problems I saw.

It drives me nuts when you find a forum post and they never reported back. Or it's a terse "I figured it out." I try really hard not to do that for internal or public forums. The odds are better than you think that you'll stumble on the same topic a few years from now.

I try to at least move the problem forward. However does anyone have a way they make sure to close those things out and circle back? I mean other than just doing it?

On internal tools I do do that but that's a smaller number.

Worse is stuff like car and fridge repair. I have no idea what forum I find qqs on.

Re: Absolute truths I unlearned as junior developer

#439

Post by opportune » Sat, Jun 08, 2019, 12:56 AM UTC

koala_man wrote: post #374

chadash wrote: post #284

Earlier quoted context omitted.

> Understood as senior: If a junior programmer tells me they found a system-level bug, I won't believe them and will tell them to go figure out what's wrong with their code. My first job was in finance and I remember one time that I had a glitch on a complicated Excel spreadsheet. I checked it over, checked again and checked again until I finally concluded that the bug was in Excel itself. So I go to my boss and tell…

Junior programmers find an amazing amount of system-level issues. One noob came to me with a serious codegen bug in GCC, where even with `-O0` it would fail to correctly run a trivial for loop. Another found a huge security hole in `sudo` that gave everyone unrestricted access. My favorite was one who asked if the JDK standard library had any known bugs processing the letter "g". They all turned out to be user error,…

Haha, that last one is hilarious!

Even though I'm still juniorish, I still run into issues like this that stump me. But then occasionally you do find bugs with existing software which keeps you second guessing everything. Usually those bugs come from using two things in conjunction that haven't been well tested together.

Also sometimes, you find a bug that isn't accepted by the software vendor/owning team as a bug, because it has some sort of obscure work around that would take you a week of tinkering to figure out. Those "aren't bugs" but yeah, they are bugs. Software vendors that also sell consulting and related services love to pull shit like that

Re: Absolute truths I unlearned as junior developer

#440

Post by kurtisc » Sat, Jun 08, 2019, 1:01 AM UTC

dbingham wrote: post #145

lmm wrote: post #111

Earlier quoted context omitted.

Early 30s here and I've realised that comments are worse than useless most of the time. Nothing enforces that the comment is correct, so a significant proportion of comments will be false, so no comments can be relied upon. Descriptive types, clear tests, and sensible variable names are much more effective strategies for making code understandable. Comments should be a last-resort stopgap.

Honestly, I would add this whole comment to the list of "absolute truths" juniors unlearn as they get more experience. And I would also point to the original post's point that types of experience matter - just because you're early 30s doesn't necessary mean you've had the right experience. If you still believe this, then - to be brutally honest - I would question the quality of the teams you've worked with. Comments…

>If the developer doesn't remember to do it when making changes, then the code reviewer can catch it and enforce it.

They can. Just after correcting all the buffer overflows and before fixing all the use-after-frees. Then the comments can be consumed by all the other teams with the discipline and culture to avoid writing bugs for all time.