Live data from Hacker News

Absolute truths I unlearned as junior developer

monicalent.com

411–420 of 534 posts

Re: Absolute truths I unlearned as junior developer

#411
post #378
post #289

Earlier quoted context omitted.

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…

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

Re: Absolute truths I unlearned as junior developer

#412

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…

> git reset --hard HEAD story of my life

> git stash # i might need this one day And i never need it.

Re: Absolute truths I unlearned as junior developer

#413

Earlier quoted context omitted.

From a hiring perspective, the problem is, and will continue to be, the quality of each worker. Although there are a handful of similarities between how the two professions operate, I think that it is unwise to make the factory worker connotation. The entire idea of a factory worker is that they can be swapped in place by another and the output is maintained to a great extent. This just simply isn't the case in softw…

That's because our tools are not good enough so what we lack in tools we compensate by individual developer quality. I spend a lot of time within WordPress ecosystem and I've seen people coming to me with 20K products shops they've built and maintain without a single line of code written. I've seen companies operating online without having any developments either on contract or in house. Because for certain simpler s…

Perhaps we are arguing different things. If by developer you are referring specifically to a web-developer, sure they are akin to the a factory worker in that they are, by in large, on the way out. I am arguing the more broad sense of developer as being a substitute for computer programmer.

Re: Absolute truths I unlearned as junior developer

#414
> So imagine my surprise when I showed up at my first day on the job at a startup and found no tests at all. No tests in the frontend. No tests in the backend. Just, no tests. > Nada. Zip. Null. Undefined. NaN tests.

On my current project I have 100% test code coverage. Which I believe is quite unusual. But I am pretty sure that if I give a talk about how I did it, most people will be horrified.

Re: Absolute truths I unlearned as junior developer

#415

> So imagine my surprise when I showed up at my first day on the job at a startup and found no tests at all. No tests in the frontend. No tests in the backend. Just, no tests. > Nada. Zip. Null. Undefined. NaN tests. On my current project I have 100% test code coverage. Which I believe is quite unusual. But I am pretty sure that if I give a talk about how I did it, most people will be horrified.

Why would people be horrified?

Re: Absolute truths I unlearned as junior developer

#416
post #378
post #289

Earlier quoted context omitted.

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…

It’s often helpful to know who wrote a line of code, because then I can put myself into their shoes and try to figure out what was going on their mind when they wrote it.

Re: Absolute truths I unlearned as junior developer

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

> 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. If your code quality is bad, you can't do that efficiently. Your developers will hate their jobs and churn like crazy. And by "bad quality" I don't mean "not unit tested" or "not commented" or "poorly formatted". I'm talking about code that is difficult t…

And the business will feel it eventually. Developers have this magical ability to create invisible time-delayed catastrophes.

Re: Absolute truths I unlearned as junior developer

#418
post #379

Earlier quoted context omitted.

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.

I don't know if it's stalling so much as taking the time to request changes / pair up and teach.

If bad code is getting merged, that's tech debt / time someone else is going to have to spend anyway, plus the time needed to identify the issue and triage down the line. I would think it's better investment to use that time up front and help the jumior level up too.

Re: Absolute truths I unlearned as junior developer

#419
> "Not everyone will become senior during their career"

This. So much this. I didn't realise that until a little while ago but when I did it made me realise I need to understand actually what make someone a senior. It's not just an automatic progression.

Re: Absolute truths I unlearned as junior developer

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

It’s often helpful to know who wrote a line of code, because then I can put myself into their shoes and try to figure out what was going on their mind when they wrote it.

[deleted]
Post reply on HN