Absolute truths I unlearned as junior developer • Hacker News Board

Re: Absolute truths I unlearned as junior developer

#371

Post by kenhwang » Fri, Jun 07, 2019, 8:44 PM UTC

chadash wrote: post #284

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: 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 just say, even if it's a bug, there's no guarantee it'll be fixed on a timeline that's agreeable to our deadlines. Find a workaround.

Re: Absolute truths I unlearned as junior developer

#372

Post by wtetzner » Fri, Jun 07, 2019, 8:48 PM UTC

nikanj wrote: post #347

enriquto wrote: post #205

Earlier quoted context omitted.

> the old Kernighan quote “Everyone knows that debugging is twice as hard as writing a program in the first place. So if you're as clever as you can be when you write it, how will you ever debug it?” This quote can be interpreted in an intelligence-positive way, to encourage you to learn by writing the cleverest possible code. Then, when you get to debug it, you will be forced to improve your skills. This interpretat…

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

I would hope at least most of the debugging happened before the code made it to production.

Re: Absolute truths I unlearned as junior developer

#373

Post by kenhwang » Fri, Jun 07, 2019, 8:50 PM UTC

justbaker wrote: post #280

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: Communication skills matter most. I can't speak enough on this one. In our craft, The better one is at communication skills, the more effective their technical skills will be.

There's also a strong correlation between strong communication skills and strong technical skills in our industry that demands frequent learning of new skills. So not only does strong communication augment technical skills, it also signals its strength which is also valuable to software developers.

Re: Absolute truths I unlearned as junior developer

#374

Post by koala_man » Fri, Jun 07, 2019, 8:51 PM UTC

chadash wrote: post #284

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

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, if you can believe it.

Re: Absolute truths I unlearned as junior developer

#375

Post by jiveturkey » Fri, Jun 07, 2019, 8:56 PM UTC

jayd16 wrote: post #63

lukejduncan wrote: post #11

"Loads of companies and startups have little or no tests" which should scare you, or at least it would scare me if I joined a team. You can definitely over test, but how can you possibly know what you built works (or still works when you change it for the 50th time) if you have no tests? There's a trade-off with testing. Early in the dev cycle, not testing can make you go super fast (supposedly, this hasn't been my p…

Tests are anti-agile. TDD is waterfall. Legacy tests add friction to making changes. Sometimes you want that friction but in a frenetic prototyping phase its detrimental. This is especially true when business goals are changing constantly (such as early prototyping). How do you know what you built works? The only thing that truly matters is that the user story is satisfied and to that end unit tests are terrible. At…

you have a lot to unlearn, young padawan. you must first forget what you know ...

Re: Absolute truths I unlearned as junior developer

#376

Post by kazinator » Fri, Jun 07, 2019, 8:58 PM UTC

lmm wrote: post #168

dbingham wrote: post #145

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…

> The whole point of coding declaratively is that the "why" is front and center and the "what"/"how" follows from that.

Declarative means that we specify the "what", and the machine deduces the "how".

There is no room for "why", because our present-day machines do not require motivating argumentation in order to do our bidding. They either need the "what" or the "how", or whatever blend of the two that we find convenient.

We need the "why" in the documentation. Such as: why is this program written in the first place? The "why" is not in the code. When code is clear, it's just easy to understand its "what" or "how", never the "why". Unclear code obscures the "how" or "what", but clear code doesn't reveal "why".

Every "how" breaks down into smaller steps. Of course, those smaller steps have a "why" related to their role in relation to the other steps; that's not the "why" that I'm talking about here. Of course we know why we increment a loop counter when walking though an array: to get to the next element. If you start commenting that kind of why, you will soon be flogged by your team mates.

Re: Absolute truths I unlearned as junior developer

#377

Post by yxhuvud » Fri, Jun 07, 2019, 9:00 PM UTC

redleggedfrog wrote: post #2

What a great article. Definitely goes under the heading of "Truths So True They Seem Obvious." As for "Disorganized or messy code isn’t the same as technical debt," I can't look at messy code without automatically cleaning it up. It's automatic as I read and understand. In the last 5 years I've probably checked in hundreds of PR's of cleanup. If this takes anymore time and/or effort on my part I don't notice it. The…

There is the debt that is localized to a singular place, and there is the debt that is all over the place and that is a death by a thousand cuts. The former is easier to fix (and will probably be fixed by some enterprising person, but then second one is the more nefarious one that a lot fewer people actually take the time to do anything about.

Re: Absolute truths I unlearned as junior developer

#378

Post by kbp » Fri, Jun 07, 2019, 9:00 PM UTC

Tade0 wrote: post #289

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…

Here's what happened to me(A) and a friend(B) from a former workplace of mine(open-source project): B: Take a look at this shit code that I found. A: Whoah, it really is shit. Blame it so that we can see what kind of genious is behind this. B: ... A: Well? B: Apparently you wrote and I reviewed/approved it.

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 very useful for seeing the change in context, which can give a lot of insight into why it's written that way, but usually the author isn't very useful to know, unless you're planning to ask them about it. Sometimes it's useful if you happen to know that the author isn't very familiar with something when you're wondering why they didn't use it, but try to keep in mind what the actual benefits of your way are, whether they're especially pressing, and that the other person might have written it differently because they were thinking about other concerns that you forgot.

Re: Absolute truths I unlearned as junior developer

#379

Post by Aeolun » Fri, Jun 07, 2019, 9:00 PM UTC

alexanderdmitri wrote: post #367

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…

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

Not really. It just ensures no really atrocious code makes it into master.

Of course you can stall any junior merge request until it looks like senior code, but at that point you might as well write it yourself.

Re: Absolute truths I unlearned as junior developer

#380

Post by tluyben2 » Fri, Jun 07, 2019, 9:10 PM UTC

chupa-chups wrote: post #322

esoterica wrote: post #253

Earlier quoted context omitted.

You are missing the point entirely. No matter how clear your code is, it is only expressing the “what”, not the why. I can see that you’re using a binary tree, but why a binary tree and not a hash table? Why a decision forest and not a linear regression? Why a regularization penalty of 0.1 and not 0.2? Why cache A but not B? Why create an object at startup instead of generating it on the fly? You need comments to exp…

For the cases you mention a combination of package name, class name and method / function name could serve as a comment with the benefit of making sure any place referencing the code also "documents" why something is happening (tests for example, or callers of your methods). This is not always possible, and in those cases I also strongly prefer well written, concise comments explaining what is going on and why, ideal…

But those method names are still hard to relate to the business cases your customer requested. So you implemented something for some reason; your code and methods tell you what you implemented but not why... Why did you use a tree? I read your top level code and think ; dude, that would have been so much simpler and faster using a Wobble instead of a Tree! Then I try that and it turns out it has to be a Tree; you went through the same process, did not tell me why and I lost a day retrying. For instance.

(assuming, which you should always assume imho, that you left the company many years ago when this event occurs)