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

191–200 of 534 posts

Re: Absolute truths I unlearned as junior developer

#191

Post by taneq »

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.

Re: Absolute truths I unlearned as junior developer

#193

Post by war1025 »

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.

Comments and `git log -p ` to see what the comment originally referred to is pretty useful.

My personal favorite comment style is to wrap a chunk of code in `#{` `#}` blocks and add a general comment of what that chunk of code is accomplishing. Sort of like an inline method.

Re: Absolute truths I unlearned as junior developer

#194

Post by macintux »

CuriouslyC wrote: post #173
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.

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 tha…

Comments are critical for explaining the code that isn’t there. False starts, obvious optimizations that don’t actually work, etc.

Re: Absolute truths I unlearned as junior developer

#195

Post by drbojingle »

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.

There's truth to both sides. Depends on the comment really.

``` doesAThing() //does a thing ```

doesn't help anyone.

My rule: Code is for how, comment is for why.

Re: Absolute truths I unlearned as junior developer

#196

Post by ben509 »

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.

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 dumping their stream of consciousness into the comment field.

It takes practice to understand what a reader needs to know. You have to actually practice reading comments and thinking things through (another reason code review is important in your team) to get good at undertanding what you should write down.

All that said, if you truly hate commenting, at least build a habit of descriptive naming and exploiting your type system as fully as possible.

Re: Absolute truths I unlearned as junior developer

#197

Post by macspoofing »

Good writup.

>Imagine 50+ comments on your PR with all the semicolons you missed!

Depends. You should have a style guide and it should document what the expectation is. If it was decided that semicolons are mandatory, then code review should be failed. If they are optional than the code reviewer shouldn't flag it. The alternative is to use a linter/formatter and either auto-fail during a pull-request or have the tool fix it up.

Re: Absolute truths I unlearned as junior developer

#198

Post by docker_up »

mixmastamyk wrote: post #152
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 is by definition, good enough. It's up to the team and customers to decide on that however. Database integrity is particularly important, so with limited information, I'd say you made the right decision. Therefore the first draft of the code was not good enough. So, we should all be in agreement now, right?

Right, but who decides what "good enough" is? If I weren't code reviewing, then it would have passed as "good enough". And that's the point of why just saying good enough isn't good enough. There should be a threshold that no one fights over.

Re: Absolute truths I unlearned as junior developer

#199

Post by prashnts »

taneq wrote: post #7

The big one for me was the realisation that the code doesn't matter . I mean sure, it does, to us. It's what we do. But really, code doesn't matter. To the end user, what matters is that we solve their problem. We let them do their job, and we make that job as easy as possible. And that's what they pay us for. And to the company we work for, what matters is that we solve the end user's problem, and that we do so in a…

I think I get your point. As someone who doesn’t have any particular specialty (I do webdev, “embedded” devices, image processing, tooling, design, etc.), I always hesitate when someone asks me what I do. I consider the things I can do as tools to get something done.

I interned at a research facility where I had to figured out obscure serial commands for a two axis objective stage, interface microscope camera, and image analysis. Then I wrapped it all in a python library for them to use.

From my mentors perspective however, the goal was “simple”: you find a microorganism swimming under microscope, and keep following it to record its trajectory. Make sure each tick is max 10ms because those little ones move FAST. They didn’t care if I used 4 space indents or 2. They cared about getting pandas dataframe so they could do all the analysis.

I can’t explain this in a word or few, and I still don’t know what to call myself! Am I a developer? I don’t know.

Re: Absolute truths I unlearned as junior developer

#200

Post by taneq »

jiveturkey wrote: post #162
dahart wrote: post #34

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

When seniors (and above) complain about the low quality of junior code, I tell them to go look at their own code from 6 months ago. It's an endemic issue, core to the problem of poor software. > My goals used to be to write code that looked and felt cool to myself and others, ... My goals are now to: - make code so easy to read it’s boring Same for me, and I'm sure same to many of the folks that have advanced past se…

> seniors [...] complain about the low quality of junior code [...] their own code from 6 months ago.

What classes as 'senior' that their own coding style has changed that much in 6 months? O.o

> I still do write "cool code", for code that I will only use myself that doesn't go into production. But for all others, I write easy-to-read code.

Good dev. Remember, you are not your audience. Unless you're just writing play-code in which case go nuts and be as 'clever' as you want. :D

> When comments have a typo that alter the meaning of the comment, I insist that be fixed. Juniors hate me for being too picky.

Then they're wrong, and tbh that's not something I'd accept more than once from an employee.

Post reply on HN