Live data from Hacker News

Absolute truths I unlearned as junior developer

monicalent.com

301–310 of 534 posts

Re: Absolute truths I unlearned as junior developer

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

> git reset --hard HEAD

story of my life

Re: Absolute truths I unlearned as junior developer

#302
post #168

Earlier quoted context omitted.

Honestly, I would add this whole comment to the list of "absolute truths" juniors unlearn as they get more experience. And I would also point to the original post's point that types of experience matter - just because you're early 30s doesn't necessary mean you've had the right experience. If you still believe this, then - to be brutally honest - I would question the quality of the teams you've worked with. Comments…

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

> Human programmers have a limited discipline budget

You think humans are bad, try working with Lobster programmers, they get work done, but their coding style is just horrible (they use tabs).

Re: Absolute truths I unlearned as junior developer

#303

Earlier quoted context omitted.

> Learned as junior: New tech solves old problems. > Understood as senior: New tech creates new problems. This is one all the people who push "new and shiny" need to learn.

I mean, yes and no, sometimes an old systems so bad it really needed to be killed off and replaced. Or would you rather everyone stick to coding in VB6? I rather we all use C# instead of VB6 ;) I'm not implying we only ever use C#, I know there's other languages, just illustrating a shift in the MS windows development ecosystem that was for the better.

VB 6 is probably not a good example.

Even nowadays many languages don't have features that VB6 offered incl. WYSIWYG. Debugging capabilities of modern languages/environments are still often not even close to what VB6 offered 20+ years ago.

C# certainly is outstanding but I think Microsoft made a gigantic mistake by killing VB6 the way they did.

Microsoft's prevented a large amount of people to write applications, since a new ecosystem like C# or VB.net was significantly more difficult to learn and understand.

In retrospect Python or Node probably took VB6's place, so Microsoft just lost out on a huge market there. Bad management decision.

Re: Absolute truths I unlearned as junior developer

#304

Earlier quoted context omitted.

> For me, any code that I wrote more than 3 weeks, I forgot. That's why I comment the hell out of my code. I couldn't agree more. A while back I got in the habit of trying to write code for "me, six-months from now". So, if I think I can explain it to "future me", then I'm happy. Ever since I started doing that, I've been much happier with "past me"'s code. In addition to comments (particularly around hard to grok co…

I write notes to my future self all the time. Meta comment: This is bullshit and has problems with this that and the other thing. But to fix that I'd have to refactor this other module and I'm not going to do that now. And the other thing I'm drawing a blank. Meta comment2: I don't think the code needs to do this here. But I can't prove it right now. Meta comment3: We absolutely need to do this exactly as it is. Beca…

> This function name isn't correct

When dealing with articulate code I often rename the same thing multiple time while I understand it better/clarify it's purpose. Also I love how naming protects the purpose of a variable or method, mentally speaking

Re: Absolute truths I unlearned as junior developer

#306
post #111

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 rot, but so does everything else such as type names, tests, variable names, field names, designs, architectures, etc.

Re: Absolute truths I unlearned as junior developer

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

This isn't quite the same situation but it reminds me a little bit of xkcd.com/1421

Re: Absolute truths I unlearned as junior developer

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

Uh, the code does matter in almost all circumstances. That's because in most cases you're not so much solving something unsolved as providing a lower cost solution via software. The cost of the software (both in terms of initial development and ongoing maintenance) is a factor. If your problem domain is totally mapped out, maybe any solution that is quick to implement will work. If your problem domain is in any way n…

I think the parent's point (though I could be reading my own thoughts into it), is that the things you mention only matter to the user if it directly affects them. An end user couldn't care less what the maintenance costs are if they aren't passed on to them in some way. If they are, then its completely in the interests of the company to have easy to maintain software. Or if changes are time-sensitive and the company is unable to keep up which change requests. If all that's invisible to "users" (or internal stakeholders), it really doesn't matter how much the boots on the ground hate the software.

But I think also the "code doesn't matter" really means, that ideally there is no (new) code, because there is in fact an existing solution but the person asking for the solution doesn't know it. This is likely more the case with internal stakeholders that ask for something to be built that does X, not realizing that there is readily available software or libraries that does X (or something close to it). So part of our role is to know the landscape of what part of the domain really needs new (potentially bug-ridden code) to be written.

Re: Absolute truths I unlearned as junior developer

#309

Earlier quoted context omitted.

> For me, any code that I wrote more than 3 weeks, I forgot. That's why I comment the hell out of my code. I couldn't agree more. A while back I got in the habit of trying to write code for "me, six-months from now". So, if I think I can explain it to "future me", then I'm happy. Ever since I started doing that, I've been much happier with "past me"'s code. In addition to comments (particularly around hard to grok co…

I write notes to my future self all the time. Meta comment: This is bullshit and has problems with this that and the other thing. But to fix that I'd have to refactor this other module and I'm not going to do that now. And the other thing I'm drawing a blank. Meta comment2: I don't think the code needs to do this here. But I can't prove it right now. Meta comment3: We absolutely need to do this exactly as it is. Beca…

> Meta comment: This is bullshit

I used to worry about putting emotional blurbs in comments or commit messages, but I'm starting to see their value. A commit that starts "This ugly writing is to appease Roger, the editor obsessed with AP style" lets me know three things:

- Who asked for the change - The source of the content - The fact I disagree but still do it, so future me doesn't pick fights present me avoided

Of course, it could also mean "TODO: revert this commit the minute Roger retires."

Re: Absolute truths I unlearned as junior developer

#310
post #260
post #150

Excellent article! Thank you, Monica. You just put into words a whole bunch of stuff that I always "sensed" but never "said". After spending 7 million years (it sure seems like it) cleaning up the most vile garbage code you could possibly imagine, I'd like to elaborate on this: Architecture is more important than nitpicking. While a small line of code could be improved, the stuff that tends to cause bigger problems d…

> - early exits to hell that can only be fixed by rewriting What do you mean by that?

  if (a) {
    do_something();
    return;
  } else if (b) {
    do_something();
    if (something_else() == -1) {
      return;
    }
  }
  
  do_other_things();
  
  maybe_exit_here();
  
  maybe_keep_going();
it has similarity to frequent `goto label` type of coding
Post reply on HN