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

321–330 of 534 posts

Re: Absolute truths I unlearned as junior developer

#321

Post by yakshaving_jgt »

taneq wrote: post #191
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…

> 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. My mum told me "if you think you found a bug in the compiler or OS... you're wrong". This advice applies until you're good enough to know it doesn't. She was right.

I wish my mother knew what a compiler was.

Re: Absolute truths I unlearned as junior developer

#322

Post by chupa-chups »

esoterica wrote: post #253
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…

You are missing the point entirely. No matter how clear your code is, it is only expressing the “what”, not the why. I can see that you’re using a binary tree, but why a binary tree and not a hash table? Why a decision forest and not a linear regression? Why a regularization penalty of 0.1 and not 0.2? Why cache A but not B? Why create an object at startup instead of generating it on the fly? You need comments to exp…

For the cases you mention a combination of package name, class name and method / function name could serve as a comment with the benefit of making sure any place referencing the code also "documents" why something is happening (tests for example, or callers of your methods).

This is not always possible, and in those cases I also strongly prefer well written, concise comments explaining what is going on and why, ideally with a link to a reference/source which explains the background.

Some examples of method names:

- generateTreeToAllowPartitioningOfItems(...)

- getMatchingRegularizationPenaltyForSpecialCaseX(...)

- getShortTermRedisProxyCache(...)

- createNewPrefilledTemplateObjectForXYZ(...)

I hope this doesn't sound snarky. But more often than not comments do date in my experience (and they don't handle refactoring well), while (compiler-known) names are handled as 1st class citizens by the current IDEs and thus are corrected and updated anywhere.

In code reviews we usually aim for "low comment" density, the implementer shouldn't explain what or why he was doing, the reviewer has to understand just from the code (as it would happen if she/he has to maintain it later on). The review is "not good" or even fails if the reviewer doesn't understand why and what is happening. The outcome will in most cases be an improved design, not more comments.

Re: Absolute truths I unlearned as junior developer

#324

Post by eitland »

grogenaut wrote: post #225
snicky wrote: post #187

Earlier quoted context omitted.

Semi-related story of mine: 1. Stumble upon some specific problem with a web framework we use. 2. Jump straight to stackoverflow. 3. Sbd had a similar issue, nice. 4. Sbd wrote a very concise answer, nice too. 5. There's my nickname under the answer. Oh, wait...

I'm getting the statement about once a quarter at work of: Yeah I found this bug and I worked through it, did a bunch of googling or internal searching found a similar issue and welp it was a ticket from you (me) 2 years ago.

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

Re: Absolute truths I unlearned as junior developer

#325

Post by retiredcoder »

TheAceOfHearts wrote: post #299
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…

Sometimes you encounter some questionable code and you wonder: "What idiot wrote this?" So you `git blame` and you find out "Oh, I'm that idiot."

I have been in this situation and tried to remember what was going on while I wrote the questionable code. It frequently came down to a day full of interruptions and context switching. Also motivation plays a tremendous role, I know that whenever I have to work on a code base I don’t understand and don’t want to have anything to do with it long term, it ruins my ability to focus.

Re: Absolute truths I unlearned as junior developer

#326

Post by dranka »

docker_up wrote: post #90
mlent wrote: post #78

Earlier quoted context omitted.

Hey! OP here. I definitely don't mean "good enough is good enough" as an excuse -- pushing for quality is extremely important. My point was more about nitpicking line by line for perfection. What you're talking about sounds like a legitimate performance issue. I think we're on the same page, but maybe my point wasn't clear enough. I tried to make it clear in my last point that "code is quality is important" but it's…

When I code review, I differentiate between "code quality" and "opinion". First off, there needs to be a coding standard guideline so that 80% of all issues of "opinion" vs "coding standard" are well defined. This is one of the reasons why I like go, because things like go fmt are the great equalizer. I probably won't like the variable names people chose but I won't comment on that because that's "my opinion". I will…

Agree with this. I obviously comment on bugs and also convoluted code that I know will be hard to understand later. If it is just small details it is easier to just change them myself when I inevitably have to revisit the code later on rather than nitpicking and arguing during the review. If I don't have to revisit the code for any change then just let it be. Out of sight, out of mind

Re: Absolute truths I unlearned as junior developer

#327

Post by beat »

chadash wrote: post #284
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: 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…

I actually found an OS bug in AIX on my first real I-designed-this code project. Worse, the bug was discovered only when the code went into production - it behaved differently on the test servers than on the production servers! The bug caused mmap() system calls to randomly overwrite certain pages in memory with NULLs. Yeah, that was fun. And it was caused by the order in which patches had been applied, which was why it behaved differently in production than in dev/test.

If some second year programmer told me that nonsense, I'd make them go back and either find their bug, or write a test program that exercised the bug in isolation (which was what I did).

Re: Absolute truths I unlearned as junior developer

#328

Post by RussianCow »

wa1987 wrote: post #248
BurningFrog wrote: post #94

Earlier quoted context omitted.

I've found myself saying "I, uh, build software" lately. I guess because I don't like any of the established terms.

I tend to avoid the word "building" in the context of describing what I do. After all, the compiler does the building :-) "I design and develop software" is what I usually say. Would be nice if there was a word that captures the idea of someone both designing and constructing the internals of a machine.

I try to avoid the word "design" because most people immediately think of graphic design and get the wrong idea of what I do. Even though it's not as technically accurate, I think "building" or "engineering" are better words to use for people not familiar with software development.

Re: Absolute truths I unlearned as junior developer

#329

Post by beat »

kps wrote: post #154
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…

Lemma: > Learned as junior: Legacy code is hard to read. Understood as senior: Legacy code that I wrote myself is hard to read. Lemma: > Learned as junior: Technical skills matter most. Understood as senior: Communication skills matter most. Theorem: Communication needs to target the people of the future.

Outstanding observation, thank you!

Re: Absolute truths I unlearned as junior developer

#330

Post by beat »

taneq wrote: post #191
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…

> 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. My mum told me "if you think you found a bug in the compiler or OS... you're wrong". This advice applies until you're good enough to know it doesn't. She was right.

One of the first rules from the book The Pragmatic Programmer is "SELECT isn't broken". (It might even be the first rule.)
Post reply on HN