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

111–120 of 534 posts

Re: Absolute truths I unlearned as junior developer

#111

Post by lmm »

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.

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.

Re: Absolute truths I unlearned as junior developer

#112

Post by [deleted] »

pdpi wrote: post #89
chessturk wrote: post #70

Earlier quoted context omitted.

I knew a shop that refused to move its customer data out of an ancient MS Access instance until one day it just started shedding records. That's what I think of when I hear technical debt. What are examples that make sense and don't just explode in your face?

Whatever it is you're writing doesn't have to work for the next twenty years. If it's sufficiently simpler and cheaper, it's fine if that project only works for the next five years, and you have to start working on a rewrite in four. By then, you'll either have gone broke (in which case the extra scaling would've been useless anyhow), or you'll have four more years of experience to guide you in how to build the next…

[deleted]

Re: Absolute truths I unlearned as junior developer

#114

Post by baq »

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…

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.

Re: Absolute truths I unlearned as junior developer

#116

Post by scriptkiddy »

I don't know if I can call myself a senior. (none of the companies I've worked for have used senior/junior in their job titles), but one of the most important pieces of information I've picked up is this:

The Simplest way is usually the right way.

What I mean is that fancy algorithms, sweeping design patterns, and "clever" pieces of code are generally not the best approach to 99% of coding specific problems.

Example: Nested for-loops. Generally a bad choice. When encountering a nested for-loop, one may be tempted to try and refactor it into some sort of recursive and highly-performant function with O(n) complexity, etc. You go through all that work and then realize that the most iterations that for loop will ever see is ~10. You just wasted a ton of time writing code that is more complex, harder to debug, and generally more opaque.

In my experience, I've seen this a lot in the context of premature optimization. I've also been the perpetrator many times as well.

Re: Absolute truths I unlearned as junior developer

#117

Post by chrisfinazzo »

criley2 wrote: post #73
onion2k wrote: post #53

Earlier quoted context omitted.

Experienced developers know when to spend time making sure code is actually good and when a terrible crufty hack is fine. If you think "All code must be perfect" then you're not a pro yet.

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

I'm surprised this hasn't come up yet, but the following should be required reading. I don't want to invoke "we follow orders or people die" (or blow up), but...

https://www.fastcompany.com/28121/they-write-right-stuff

https://en.wikipedia.org/wiki/Therac-25

Re: Absolute truths I unlearned as junior developer

#118

Post by monocasa »

avip wrote: post #99
pdpi wrote: post #74

Earlier quoted context omitted.

This is why calling people "coders" annoys the hell out of me. There was a popular blog post a long way back[1] about how you shouldn't call yourself a "programmer" because that builds the expectation that programs are the key output of your work. "Coder" takes this problem even further — your job is no longer to build a program (with all the thought and design work that entails), but rather to type out code. I'm not…

And on the best of days - involves deleting code.

Classic story:

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

Re: Absolute truths I unlearned as junior developer

#119

Post by monocasa »

patagonia wrote: post #96
RussianCow wrote: post #80

Earlier quoted context omitted.

This is why I always respond to questions about what I do with "software engineer". I've noticed people seem to perceive "engineering" as more serious than "programming", and it helps to promote the idea that I build things to solve problems and don't just sit there turning designs into code.

From Wikipedia: Engineers, as practitioners of engineering, are people who invent, design, analyse, build, and test machines, systems, structures and materials to fulfill objectives and requirements while considering the limitations imposed by practicality, regulation, safety, and cost. If you’re doing that you’re an engineer. Hopefully we are all doing that.

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

Re: Absolute truths I unlearned as junior developer

#120

Post by pdpi »

cc81 wrote: post #95
pdpi wrote: post #74

Earlier quoted context omitted.

This is why calling people "coders" annoys the hell out of me. There was a popular blog post a long way back[1] about how you shouldn't call yourself a "programmer" because that builds the expectation that programs are the key output of your work. "Coder" takes this problem even further — your job is no longer to build a program (with all the thought and design work that entails), but rather to type out code. I'm not…

Problem solver can be the title of pretty much any job though. "I'm a problem solver, I fix problems by diving down and welding broken things at oil platforms" "I'm a problem solver, I make sure the books are correct at the end of the financial year" etc. I mean it is correct but if someone calls themselves a coder/programmer/software engineer (even if they are not real engineers) then I know roughly what they are do…

Yeah, I wasn't entirely clear on that bit :) There absolutely is plenty of room for a word more specific than "problem-solver". But our choice of words matters — words carry nuance.

In some ways I'd consider "software engineer" as equivalent to "novelist" or "journalist" where "programmer" maps to "writer" and "coder" corresponds to "typist". Software engineer, novelist, journalist all encapsulate a lot of responsibilities, where writer and programmer both talk just about primary means of achieving the job, and coder/typist bring it down to the mechanical skills you require to get the job done.

Post reply on HN