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

221–230 of 534 posts

Re: Absolute truths I unlearned as junior developer

#221

Post by jjeaff »

enobrev wrote: post #170
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…

> code that I wrote myself is hard to read This has happened more times than it probably should: 1. Arrive upon some code I wrote at some point in the near or distant past. 2. Review it to get some idea of what I was trying to do 3. Laugh at my young self for being so naive 4. Refactor or Rewrite 5. Re-realize the edge-cases and difficulties 6. Remember this being a problem 7. Refactor And Rewrite 8. Either `git rese…

I usually do this same thing. But not before mentally cursing out the programmer that wrote this poorly documented spaghetti code... After which I realize it was me.

Re: Absolute truths I unlearned as junior developer

#222

Post by smacktoward »

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 would argue it's even worse than that. It's not just that the code doesn't matter, it's that code is a liability, and the more code you create the more problems you create.

Code has to be maintained, or it will eventually fail as other moving parts around it change their interfaces.

Code rots. Platform norms are always changing, so today's fresh new code becomes tomorrow's smelly old code.

Code interacts with other code. As the volume of code increases linearly, the number of these interactions increases exponentially. Eventually the complexity becomes unmanageable and the whole system has to be rebuilt. The more code you add to a system, the faster you hasten its demise.

All of which means that code is a liability, in the balance-sheet sense of the term. Throwing code at a business problem hurts the bottom line. The goal therefore becomes to throw just enough code at the problem to solve it, and not one line more than that.

This is the difference between inexperienced and experienced developers. Inexperienced developers handle code like it's spackle. Experienced ones handle it like it's uranium.

Re: Absolute truths I unlearned as junior developer

#223

Post by agumonkey »

BeetleB wrote: post #176
agumonkey wrote: post #50

Earlier quoted context omitted.

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.

bugs leaks and upgrade conflicts are not my problems but any wordpress user problems

Re: Absolute truths I unlearned as junior developer

#224

Post by esoterica »

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.

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

Re: Absolute truths I unlearned as junior developer

#225

Post by grogenaut »

snicky wrote: post #187
enobrev wrote: post #170

Earlier quoted context omitted.

> code that I wrote myself is hard to read This has happened more times than it probably should: 1. Arrive upon some code I wrote at some point in the near or distant past. 2. Review it to get some idea of what I was trying to do 3. Laugh at my young self for being so naive 4. Refactor or Rewrite 5. Re-realize the edge-cases and difficulties 6. Remember this being a problem 7. Refactor And Rewrite 8. Either `git rese…

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.

Re: Absolute truths I unlearned as junior developer

#226

Post by grogenaut »

jjeaff wrote: post #221
enobrev wrote: post #170

Earlier quoted context omitted.

> code that I wrote myself is hard to read This has happened more times than it probably should: 1. Arrive upon some code I wrote at some point in the near or distant past. 2. Review it to get some idea of what I was trying to do 3. Laugh at my young self for being so naive 4. Refactor or Rewrite 5. Re-realize the edge-cases and difficulties 6. Remember this being a problem 7. Refactor And Rewrite 8. Either `git rese…

I usually do this same thing. But not before mentally cursing out the programmer that wrote this poorly documented spaghetti code... After which I realize it was me.

Even well factored code looks like spaghetti at a casual read in a lot of frameworks/cases, and makes sense once you've swapped all that info back in.

Re: Absolute truths I unlearned as junior developer

#227

Post by tomsmeding »

taneq wrote: post #200
jiveturkey wrote: post #162

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…

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

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

Your code style can remain exactly the same, and it would still happen. The reason is not that you would write the code differently today, but that you forgot the issues and edge cases that made you write it like that then, and that at the time you focused too much on the writing, not on the reading.

Re: Absolute truths I unlearned as junior developer

#228

Post by fendy3002 »

kbenson wrote: post #206
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. As it should be. If your code from a five to ten years ago doesn't make you cringe at least a little bit, the right way to view that is not that you were doing a good job back then, but that you haven't gotten any better since then .

It isn't as simple as better skilled or not. Many times having more understanding about the problem may open your eyes to better / simpler design, or you now don't have any rushing matter that fuel bad design in the past.

Re: Absolute truths I unlearned as junior developer

#229

Post by kbenson »

toxik wrote: post #214
kbenson wrote: post #206

Earlier quoted context omitted.

> Understood as senior: Legacy code that I wrote myself is hard to read. As it should be. If your code from a five to ten years ago doesn't make you cringe at least a little bit, the right way to view that is not that you were doing a good job back then, but that you haven't gotten any better since then .

I disagree with this perspective. You of yesteryear is in many ways just another programmer you have to work with; if that makes you cringe, you may be taking a bit too much pride in your work.

> You of yesteryear is in many ways just another programmer you have to work with

Taking that idea to the extreme of not having any feeling of ownership or pride (or lack thereof) in your past work seems rather silly to me. It wasn't just some other programmer, it was you.

I'm not saying you should cringe because the code is bad, but because you should have a sense of "well, I could have saved myself some trouble or made this cleaner/more obvious if I only knew then what I know now."

Re: Absolute truths I unlearned as junior developer

#230

Post by CuriouslyC »

gamblor956 wrote: post #207
CuriouslyC wrote: post #173

Earlier quoted context omitted.

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…

I've heard these sentiments very frequently from junior programmers, and almost never from senior programmers.

I'm guessing most of the senior programmers you've interacted with are maintaining established software with low churn and high availability requirements.

I hear comment love very frequently from enterprise engineers working with 10+ year old Java codebases, but very infrequently from hackers working with young code bases in more concise languages (complex algorithms aside).

Post reply on HN