Absolute truths I unlearned as junior developer • Hacker News Board

Re: Absolute truths I unlearned as junior developer

#511

Post by eru » Sat, Jun 08, 2019, 3:28 PM UTC

munchbunny wrote: post #361

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…

These days my rule of thumb is to not try to rewrite or generalize until I or my team has tried to do more or less the same thing three times. Before that, you just don't have a good feel for what is generalizable/edge case or what is invariant/variable in the problem space. I've definitely run into this phenomenon of independently landing on the same design twice because of the same edge cases. At some point back in…

Generalizing even when you are only using your solution once can sometimes be useful.

When you know that certain information should not be used in a correct solution, a more abstract approach can make sure that information stays hidden.

A really simple example: for-loops in Python 'leak' their index variable. Stick that loop inside a local function, and then you know that you can not accidentally make use of the index variable later.

A more complicated example is deliberately coding to an interface that carefully exposes only what should be exposed. Eg using a map or filter higher-order function.

Re: Absolute truths I unlearned as junior developer

#512

Post by juanbyrge » Sat, Jun 08, 2019, 4:06 PM UTC

One thing I learned as a developer for 12+ years is that the title is meaningless and where I work, many of the highest impact developers would be considered 'junior' developers. I wonder why people have such an infatuation with the title 'junior' and 'senior'. Seems to be more prevalent in European countries.

Re: Absolute truths I unlearned as junior developer

#513

Post by spenczar5 » Sat, Jun 08, 2019, 4:13 PM UTC

enriquto wrote: post #370

nikanj wrote: post #347

Earlier quoted context omitted.

”Prod is on fire and nobody can figure out your burrito pasta” ”Isn’t this a wonderful learning opportunity for all of us” Debugging time is never a good time to start honing new skills.

Of course, Kernighan's lever is most useful on individual projects. In an industrial context there are often other constraints. Nobody is saying that you have to always write the most clever code you can. But if you never do it, you will improve your skills very slowly, if at all.

Writing simple code is difficult, more difficult than writing clever code, and is a better skill to grow.

Re: Absolute truths I unlearned as junior developer

#514

Post by gilbetron » Sat, Jun 08, 2019, 4:20 PM UTC

Sharlin wrote: post #492

mpolsz wrote: post #432

Earlier quoted context omitted.

That someone being me not knowing why in hell would I write this monstrosity... git blame + some archeology work to get jira ticket number (I put issue numbers in commit message/branch name) and from that I know why.

Yes, naturally "those who come after" often includes the future you.

Much of my life as an older dev includes balancing my relationship with my past, current, and future selves. Be kind to your future self; be compassionate of your past self. And don't forget, they really are different people ;)

Re: Absolute truths I unlearned as junior developer

#515

Post by sk0g » Sat, Jun 08, 2019, 5:10 PM UTC

sirmarksalot wrote: post #411

kbp wrote: post #378

Earlier quoted context omitted.

The "who wrote this?" mentality is a trap that's good to avoid. Get comfortable with different ways of writing something that, while they might have different tradeoffs, accomplish the same thing, and try to see past that. Understand that most code wasn't written by anybody--lines 1 and 3 were written by Alice a year ago, line 2 was written by Bob 2 years ago, and line 4 was written by Alice yesterday. `git blame` is…

While lots of legacy code emerges organically the way you describe, there are in fact many people in the industry who I'd call "legacy coders." People who saw Dijkstra's "Goto considered harmful" and scoffed, "all these 'for' loops are much less readable than my 'goto loop1' solution." People who use global variables because parameter-based implementations are "needlessly complex." Basically, not everyone works for G…

You say that, but Golang has gotos, while being a very minimal language. Not everyone at Google is an amazing developer that's fully up to date with best practices and patterns.

Not that that needs to be said, no matter the company (if it's of any decent size.)

Re: Absolute truths I unlearned as junior developer

#516

Post by decisiveness » Sat, Jun 08, 2019, 5:41 PM UTC

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…

And each time this happens, you get better about writing readable comments up front describing edge cases and difficulties so that future self can avoid steps 1 - 6 with a head start on refactor ideas / feasibility.

Re: Absolute truths I unlearned as junior developer

#517

Post by sunandshine » Sat, Jun 08, 2019, 6:22 PM UTC

prashnts wrote: post #199

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

> Am I a developer? I don’t know.

I would say the title "Research Engineer" could fit quite well based on what you describe!

Re: Absolute truths I unlearned as junior developer

#518

Post by nickda » Sat, Jun 08, 2019, 7:22 PM UTC

vortico wrote: post #61

Perhaps the reason for "nobody writes tests" in the real-world isn't primarily because of time/cost, but because virtually no real potential bugs are testable. If you're writing a JPEG encoder or database model handler, yes, you can test that all day, but those things already exist and are well-tested for you. But if you're designing retail software or a web app, there are 2^10000 things that can go wrong, so most co…

You only have 2^10000 if you have bad boundaries and overcoupling of your subsystems. Thus another benefit of unit testing is validating your architecture: bad architectures are inherently difficult to unit test.

Re: Absolute truths I unlearned as junior developer

#519

Post by koala_man » Sat, Jun 08, 2019, 10:51 PM UTC

pkolaczk wrote: post #507

koala_man wrote: post #374

Earlier quoted context omitted.

Junior programmers find an amazing amount of system-level issues. One noob came to me with a serious codegen bug in GCC, where even with `-O0` it would fail to correctly run a trivial for loop. Another found a huge security hole in `sudo` that gave everyone unrestricted access. My favorite was one who asked if the JDK standard library had any known bugs processing the letter "g". They all turned out to be user error,…

There was a junior in one of the early companies I worked at who claimed to have found a JVM bug. He insisted JVM handled comparison with null incorrectly. He had a String variable that was null, then he guarded against NPE with "if (str == null) return -1" followed by code that dereferenced str. The code looked innocent at first glance, but somehow it failed with NPE. Finally it turned out the string was "null" not…

>"I've been doing it for 20 years, and you say I'm wrong?" How to best handle such cases?

I wish I knew. I try to limit the discussion to the purely technical, or to barely acknowledge it as in "sure, but RFC123 says X and Y implements it that way as shown in Z".

Of course, that goes for when I'm the authority as well. I don't care who is correct, I care about what.

Re: Absolute truths I unlearned as junior developer

#520

Post by Gibbon1 » Sat, Jun 08, 2019, 11:31 PM UTC

cja23 wrote: post #348

Gibbon1 wrote: post #259

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. Me: 'Even a blind squirrel finds a nut once in a while'

Horses, not zebras. But yes, there are a few zebras in the world also.

Depends on what they are doing.

Oh you found a 'bug' in Mac OS, Windows, or Linux? Probably not.

Oh you found a 'bug' some open source library? Maybe.

Or in our in house developed framework? Probably.

In house framework I wrote? Certain of that.