Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Absolute truths I unlearned as junior developer

monicalent.com

Post reply on HN
Print view View original

171–180 of 534 posts

Re: Absolute truths I unlearned as junior developer

#171

Post by pkaye »

monocasa wrote: post #118
avip wrote: post #99

Earlier quoted context omitted.

And on the best of days - involves deleting code.

Classic story: https://www.folklore.org/StoryView.py?story=Negative_2000_Li...

My old boss of exceptional at this. He had hired a lead engineer to architect on code to support some new features and hardware. This lead was working on one of the important module.s It was 1300 lines of convoluted code and still not done. At that point the guy quit. My boss spend a day thinking about the requirements and wrote something that made perfect sense in 30 lines of code all one function.

Re: Absolute truths I unlearned as junior developer

#172

Post by kochthesecond »

lmm wrote: post #111
docker_up wrote: post #72

Earlier 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.

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.

I'm 29 and can barely remember the code I wrote last week.

Comments don't get updated when the requirements for the code change, more often than not end up as misleading.

The only thing worth commenting are actual libraries that are maintained, and 'magic values'.

Re: Absolute truths I unlearned as junior developer

#173

Post by CuriouslyC »

docker_up wrote: post #72
beat wrote: post #15

Admittedly, my first days as a junior programmer were before some of you were born, but I'm thinking of a particular format here... Learned as junior: If you report an OS bug or some other deep problem, seniors will not believe you and assume you're making excuses for your own bugs and lack of understanding. Understood as senior: If a junior programmer tells me they found a system-level bug, I won't believe them and…

> 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.

Comments rot, and details about what is going on is better incorporated using good variable names and functions that abstract aspects of a task from their implementation.

While I don't like comments that try to explain what code is doing (write better code), comments are very useful for annotating WHY code does what it does. They're also very useful for adding documentation references, code use gotchas and things that need to be addressed in the future.

Re: Absolute truths I unlearned as junior developer

#174

Post by nobleach »

ghaff wrote: post #128
monocasa wrote: post #119

Earlier quoted context omitted.

Unless you're in certain states where engineer is a protected term.

Engineer is not a "protected term" in any US state that I'm aware of. "Professional Engineer" has a specific licensed meaning but, if I have a degree in mechanical engineering I'm pretty sure I can call myself an engineer anywhere in the US without the licensing police coming after me. (Unless, of course, I imply that I'm licensed when I'm not.)

If you work in a music studio, and you call yourself a sound engineer, no one is going to ask to see your credentials because it's assumed that you engineer sound. The same holds through with software engineering. No one expects you to carry some sort of card. When it comes to structural, or civil engineering, there is a far higher expectation that the things you design are not going to fall down. But we're able to understand this distinction. The idea that we should disallow computer coders/programmers from using the term engineer is not based on reducing confusion...

Re: Absolute truths I unlearned as junior developer

#175

Post by jiveturkey »

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…

You're getting some flack because "good enough" is too loaded and everyone reads it a little differently. No one seems to be reading your qualifier, "the consequences of a dupe would lead to a pretty bad customer experience."

Sometimes, good enough is good enough. If you were able to push back hard in this case, I take it you are senior to the other guy and your decision is/was justified by the product/feature requirements. IOW, in this case, good enough was in fact not good enough.

> constraint

most important thing, right there.

Re: Absolute truths I unlearned as junior developer

#176

Post by BeetleB »

agumonkey wrote: post #50
TheOtherHobbes wrote: post #44

Earlier quoted context omitted.

The code is crap. Wordpress is crap. It's unsafe, open-to-hackers crap. The plugins are crap. But it solves the problem users want solved. It's lego-level blog assembly, which is as technical as many users want to get. A much "better" system - maybe a nice type-safe Haskell static HTML templater with a command line build system - wouldn't. Flipping this around, from the user's POV, "I wrote some code that almost does…

I don't agree with the analysis. It's mostly that mainstream life floats on ambiguity and undefined contexts. Wordpress does some things perfect for users but then bug or leak or plugin conflicts happen. While other platform may have solved this prior but it's a problem that users didn't anticipate so they didn't value it.

He didn't say Wordpress solves everyone's problems. That it doesn't solve your problem does not negate his point.

Re: Absolute truths I unlearned as junior developer

#177

Post by colechristensen »

asheikh wrote: post #115

My Absolute truth I unlearned as a Senior developer. your knowledge, hard work and quality of work is not important. The relationship that you have with your boss and your bank account is what you need to focus on.

You need to focus on all, not to switch between one and the other.

It doesn't matter if your work is amazing if nobody realizes it (unless you are fine being a starving artist, no judgement)

The corollary isn't that you should make everyone think your inadequate work is amazing. I don't think you personally are making that judgement but there are people who would.

Re: Absolute truths I unlearned as junior developer

#178

Post by CuriouslyC »

crankylinuxuser wrote: post #121
docker_up wrote: post #72

Earlier 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.

Thats also a reason I will include as a comment the unoptimized code with comments whenever I do optimized crazycode. That way, I can understand what is actually being done. And I can then re-analyze why I did the shortcuts to get to optimization. But 99% of the time, we dont need to optimize. CPU/RAM is cheap. But those 1% of the times when you're going from N^2 to N^logN ... Welll.....

Did you mean N*logN? I don't think going to N^logN is what you want ;)

Re: Absolute truths I unlearned as junior developer

#179

Post by monocasa »

ghaff wrote: post #128
monocasa wrote: post #119

Earlier quoted context omitted.

Unless you're in certain states where engineer is a protected term.

Engineer is not a "protected term" in any US state that I'm aware of. "Professional Engineer" has a specific licensed meaning but, if I have a degree in mechanical engineering I'm pretty sure I can call myself an engineer anywhere in the US without the licensing police coming after me. (Unless, of course, I imply that I'm licensed when I'm not.)

The term "engineer" is definitely protected in Texas, and I think some other states.

Re: Absolute truths I unlearned as junior developer

#180

Post by mannykannot »

lmm wrote: post #168
dbingham wrote: post #145

Earlier quoted context omitted.

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 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. [my emphasis.]

As a common feature of most higher-level languages is that they co-opt natural language terms (and also mathematical notation, which is an option in commenting) with the intent to increase clarity, can you show us an example where code is more clear than natural language in explaining both what it is doing and why?

If you are working in something like APL, I can see there might be a case...

I am not so much interested in the precision issue, as both code and language can be very precisely wrong or right.

Post reply on HN