Live data from Hacker News

Absolute truths I unlearned as junior developer

monicalent.com

441–450 of 534 posts

Re: Absolute truths I unlearned as junior developer

#441
post #73

Earlier quoted context omitted.

>If you think "All code must be perfect" then you're not a pro yet Or they're a pro in a very different field than you. When I worked in web development, I was gobsmacked at what professionals considered "good enough to ship". Now that I work in Medical EHR, the standards for 'good enough to ship' when lives could be on the line is very, very, very different. I imagine a NASA engineer creating famously low-defect cod…

People in fields where they write code that has to be proven can still know when it's appropriate to write bad hacky code. If they believe "I write proven code for my EHR system therefore all code must be like that." I would argue they're not pros. Being a professional is knowing how to do your job well. Applying a single heuristic to every problem isn't that.

> If you think "All code must be perfect" then you're not a pro yet.

> Applying a single heuristic to every problem isn't that.

How ironic :)

Re: Absolute truths I unlearned as junior developer

#442

Earlier quoted context omitted.

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…

Review process surely mitigates differences between "junior" and "senior" code?

This also would require that devs who are on the PR reviews ACTUALLY look at the code. In about every job I've worked at in my short career there are people I work with that I don't trust them to actually review my code. I've come to accept that. I instead make sure the people I know will do a decent job are on the PR. Some people will just look at the diff and an even smaller few will actually pull the branch locally so they can see the entire context. That being said I always do my best to review other peoples code regardless of whether or not they will review mine.

Re: Absolute truths I unlearned as junior developer

#444

> So imagine my surprise when I showed up at my first day on the job at a startup and found no tests at all. No tests in the frontend. No tests in the backend. Just, no tests. > Nada. Zip. Null. Undefined. NaN tests. On my current project I have 100% test code coverage. Which I believe is quite unusual. But I am pretty sure that if I give a talk about how I did it, most people will be horrified.

I worked on a project that achieved 100% code coverage and still had loads of bugs. That’s precisely when I lost all faith in TDD.

Re: Absolute truths I unlearned as junior developer

#445
post #114
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…

After 15 years in the business I think it’s worse than that: code is a liability. It matters - to have as little of it as necessary and not a line more.

Nope. Sometimes it's the right choice to leave something in that your heuristic would lead you to rip out.

Can we stop with these simplistic maxims? Engineering is about tradeoffs and dealing with complexity. Trying to reduce the decision-making process to a single sentence is silly.

Re: Absolute truths I unlearned as junior developer

#446

Earlier quoted context omitted.

> git reset --hard HEAD story of my life

> git stash # i might need this one day And i never need it.

I've started saving my stashes to branches instead.. adding a _ on the front of the branch name to remind me to delete the branch at some point

Re: Absolute truths I unlearned as junior developer

#447
post #191

Earlier quoted context omitted.

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

Heh, at 19 she was the PL/1 expert for the Asia/Pacific region. Mum's a badass.

Re: Absolute truths I unlearned as junior developer

#448
post #327

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…

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…

Were you finally believed?

Re: Absolute truths I unlearned as junior developer

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

Nothing enforces correct variable names and descriptive types either, why would you expect those to be more consistently accurate than comments?

They're amenable to automated refactoring, and if you change a type or variable name in one place you're forced to update it everywhere else that uses the same thing.

Re: Absolute truths I unlearned as junior developer

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

Comments rot, but so does everything else such as type names, tests, variable names, field names, designs, architectures, etc.

Tests, types and field names get checked on build.
Post reply on HN