A paean to normalization of variance.
Absolute truths I unlearned as junior developer
311–320 of 534 posts
Re: Absolute truths I unlearned as junior developer
#312Great article. Related to the “code quality” point, what I have personally realized is that it’s easy to over complicate solutions. Often, a simple solution is better (especially when it is part of a larger, more complex system).
When I was younger, I liked clever solutions to show off my skills. Now I cringe at that. Other people have to read my code. And more importantly, “I” have to read my code tomorrow or next week. I’ve started to really prioritize simplicity. Which is ironically quite hard!
Re: Absolute truths I unlearned as junior developer
#313Earlier quoted context omitted.
Oh this is such a good comment! > Legacy code that I wrote myself is hard to read. Sometimes I don’t even recognize me as the author for a while. Realizing I’m reading something I wrote and can’t understand it without studying carefully has been rather surprising and reminds me of the old Kernighan quote “Everyone knows that debugging is twice as hard as writing a program in the first place. So if you're as clever as…
> the old Kernighan quote “Everyone knows that debugging is twice as hard as writing a program in the first place. So if you're as clever as you can be when you write it, how will you ever debug it?” This quote can be interpreted in an intelligence-positive way, to encourage you to learn by writing the cleverest possible code. Then, when you get to debug it, you will be forced to improve your skills. This interpretat…
> The alternative is a life of boredom where you don't learn anything new.
Now that's an impressive logical leap.
Re: Absolute truths I unlearned as junior developer
#314Earlier quoted context omitted.
> For me, any code that I wrote more than 3 weeks, I forgot. That's why I comment the hell out of my code. I couldn't agree more. A while back I got in the habit of trying to write code for "me, six-months from now". So, if I think I can explain it to "future me", then I'm happy. Ever since I started doing that, I've been much happier with "past me"'s code. In addition to comments (particularly around hard to grok co…
I write notes to my future self all the time. Meta comment: This is bullshit and has problems with this that and the other thing. But to fix that I'd have to refactor this other module and I'm not going to do that now. And the other thing I'm drawing a blank. Meta comment2: I don't think the code needs to do this here. But I can't prove it right now. Meta comment3: We absolutely need to do this exactly as it is. Beca…
Couldn't agree more, except with meta comment 3 it is very important to describe the bad thing, so that future me knows if he can safely rewrite this or not.
Re: Absolute truths I unlearned as junior developer
#315Overall 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 is good enough. That doesn't say anything about what is a reasonable measure of 'good enough' for your particular scenario.
Re: Absolute truths I unlearned as junior developer
#316Earlier quoted context omitted.
Oh this is such a good comment! > Legacy code that I wrote myself is hard to read. Sometimes I don’t even recognize me as the author for a while. Realizing I’m reading something I wrote and can’t understand it without studying carefully has been rather surprising and reminds me of the old Kernighan quote “Everyone knows that debugging is twice as hard as writing a program in the first place. So if you're as clever as…
> Sometimes I don’t even recognize me as the author for a while. This happened to me just yesterday! I was helping a co-worker with a problem, and I noticed some redundant code in the same function, so I told him he could simplify it while he was there. His response was, "...but you wrote that". (And as it turns out, only a few days prior!)
I am coming back from vacations next week and have 2 PRs to finish (couldn’t merge before because they are high risk), I am antecipating a lot of pain just to pick them up where I left off... I would rather do my tax returns instead lol
Re: Absolute truths I unlearned as junior developer
#317What I learned as developper and Data Scientist is: either you know what you’re doing and can see the big picture, either you’re walking blindly to a “good enough” solution.
In the first case, I spend most of my time in architectural design and modelization. The implementation phase is rather quick, because everything is well defined and you can write a lot of tests upfront.
In the second case, you’ll discover the big picture by facing the problems while trying to find and implement a working solution.
While getting experienced means how fast can you figure out the big picture.
Re: Absolute truths I unlearned as junior developer
#318> "Good enough is good enough" +1000 to this. Please don't be the guy that slows me down and prevents me from delivering features because you insist on everything being perfect. I can't tell you how many times and how much money people who are obsessed with code quality waste. They spend months polishing code only to get out a feature that no one uses and doesn't matter. But hey, the code is "perfect"!
Who defines what "good enough" means? Is it basic functionality? What if that basic functionality contains security vulnerabilities? What if it is written in such a way that will cause potential, foreseeable problems down the road? What if it is written in such a way that it is only understandable to the author? What exactly is "good enough?"
Re: Absolute truths I unlearned as junior developer
#319Earlier quoted context omitted.
> Understood as senior: Legacy code that I wrote myself is hard to read. For me, any code that I wrote more than 3 weeks, I forgot. That's why I comment the hell out of my code. The younger programmers have routinely told me "commented code means the code isn't very good." I chuckle and ignore them and wait for them to hit their mid-30s and older.
Also related: > Understood as senior: Communication skills matter most. The reason people dismiss comments is usually that they or others around them aren't good at writing useful comments. Especially when there are linter rules requiring comments you'll have something like def open_thing(x, y): and a comment, "defines a function that opens thing." Yes, those are pointless. Often what's going on is a person is dumpin…
I'm actually thinking more of social skills and written language, not programming. I said something about this in a different thread earlier this week, and someone was baffled as to why I thought being able to write and sell was important, since you just wind up doing what your boss tells you to do anyway.
As opposed to telling the boss what you're going to do.
Re: Absolute truths I unlearned as junior developer
#320Earlier 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…
> Comments don't have to decay. Discipline is important. Culture is important. And yes, these have to be intentionally set and upheld.
These are things that are often completely outside your control.
> If you set a culture...
At most shops, you don't get to set the culture. About the only time you do is if you're a founder or early developer. Otherwise you have to fit into the existing culture, or attempt to find a company that better reflects what you want. Sure, it's not hopeless; you can likely influence to some extent, but your influence is usually limited.
> And nothing really substitutes for an english language explanation of the "why" and the intention of a particular section of code.
I do agree with this. Any code that can't be written in a self-documenting way absolutely must be commented. However, if you find the need to do this often, it might be a sign that you should focus more on code clarity and less on (likely premature) optimization, or perhaps consider if you're really using the right tool (language, framework, etc.) for the job at hand.
I will admit that I probably comment less than I should, but I feel like the average is way too verbose, and that enough comments are out of date and incorrect (often in very subtle ways) that it adds significantly to my overhead when trying to understand someone else's (or even my own) code.