Absolute truths I unlearned as junior developer • Hacker News Board

Re: Absolute truths I unlearned as junior developer

#481

Post by C4stor » Sat, Jun 08, 2019, 8:06 AM UTC

milesvp wrote: post #455

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…

I agree that “who wrote this” is dangerous, and git blame is a terribad name. I will say though, if you can avoid value judgements, then knowing who wrote a block of code is super valuable in a legacy code base. I’ve found that every dev I’ve ever worked with has very real strengths and weaknesses. And knowing who wrote a piece of code can drastically reduce the time it takes me to find hard bugs. It often goes somet…

I really like this approach of using git blame, it's original thinking and highlights how much human components there are in developing.

Re: Absolute truths I unlearned as junior developer

#482

Post by C4stor » Sat, Jun 08, 2019, 8:10 AM UTC

tehlike wrote: post #412

polyterative wrote: post #301

Earlier quoted context omitted.

> git reset --hard HEAD story of my life

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

I don't allow myself to have more than 1 active stash at any given point on a project. You quickly learn to delete with no regret some code you wrote !

Re: Absolute truths I unlearned as junior developer

#483

Post by C4stor » Sat, Jun 08, 2019, 8:16 AM UTC

CuriouslyC wrote: post #173

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.

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…

This assumes everybody reading the code at the company have the skill to read it.

Where I work, I can expect my scalacode to be read by people who can barely write a line of it, and I routinely read typescript and go code while being totally inept at those.

I bless comments that are here to help the reader read, and I let those behind too where there's some specialists-only syntax.

Re: Absolute truths I unlearned as junior developer

#484

Post by PunksATawnyFill » Sat, Jun 08, 2019, 8:16 AM UTC

taatparya wrote: post #466

Buge wrote: post #462

Earlier quoted context omitted.

Does "Sbd" stand for something, or is that your username?

Somebody

Uh, OK. Never seen that before.

"Sby" would've made way more sense. Or heaven forbid we use one more character to make the nearly obvious "sbdy."

Re: Absolute truths I unlearned as junior developer

#485

Post by [deleted] » Sat, Jun 08, 2019, 8:31 AM UTC

[deleted]

Re: Absolute truths I unlearned as junior developer

#486

Post by tonyedgecombe » Sat, Jun 08, 2019, 8:32 AM UTC

Rapzid wrote: post #428

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…

Assuming those lines were getting out of hand, I think it would be a valid question as to why they were not tidied up during the review of the line 4 addition by Alice.

It’s Friday afternoon, you are exhausted after a busy week, the business is pushing for a fix before you leave and you have committed to be home by 6pm so your spouse can go out.

Re: Absolute truths I unlearned as junior developer

#487

Post by nurettin » Sat, Jun 08, 2019, 8:40 AM UTC

momokoko wrote: post #282

docker_up wrote: post #67

Overall a good article, but I completely disagree with the notion that "good enough is good enough". I've been in a lot of code reviews where developers push back because it's "good enough". You need to maintain a defined level of quality otherwise codebases go to shit very, very fast. I was recently told in a code review that a Cassandra read before a write (to ensure there were no duplicates) was "good enough" beca…

Codebases all go to shit pretty fast. That is really what you learn as a senior developer. The fully sustainable codebase is a myth. All codebases will inevitably get progressive more difficult to work on no matter what you or anyone else does. All software eventually gets rewritten. Either in full or in parts. So "good enough" means "will this keep it going until this software, or piece of this software, is thrown a…

I have experienced great difficulties with literal spaghetti code written in delphi which one can only follow through debugging, but I have also seen large codebases written in kotlin and python where almost everything is in layers and it is obvious where to add a new feature and how to find one that doesn't work. And I was very afraid that the project would end up an entangled mess, but luckily, it had the right mixture of individual services (for scaling), monoliths and messaging mediums to not become a mess.

Re: Absolute truths I unlearned as junior developer

#488

Post by fredmorcos » Sat, Jun 08, 2019, 8:50 AM UTC

pdpi wrote: post #74

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…

This is why calling people "coders" annoys the hell out of me. There was a popular blog post a long way back[1] about how you shouldn't call yourself a "programmer" because that builds the expectation that programs are the key output of your work. "Coder" takes this problem even further — your job is no longer to build a program (with all the thought and design work that entails), but rather to type out code. I'm not…

> I tend to specialise in the sort of software infrastructure-y problems that are usually solved through code.

So basically a coder?

Re: Absolute truths I unlearned as junior developer

#489

Post by lmm » Sat, Jun 08, 2019, 9:12 AM UTC

JamesBarney wrote: post #456

lmm wrote: post #450

Earlier quoted context omitted.

Tests, types and field names get checked on build.

If someone adds functionality to a type so the name isn't really applicable anymore I don't think the build catches that.

As soon as you form something that should conform to the type (according to its name) and find that it doesn't, you notice the problem, and then you fix it once and for all (because the type is defined in one place). So yes, you can have misleading type names in the codebase, but there's a natural pressure to correct them, in a way that there largely isn't for misleading comments.

Re: Absolute truths I unlearned as junior developer

#490

Post by z3t4 » Sat, Jun 08, 2019, 9:16 AM UTC

pfranz wrote: post #355

eitland wrote: post #324

Earlier quoted context omitted.

Which is why I am trying to get better at what I used to to: writing down and sharing problems I saw.

It drives me nuts when you find a forum post and they never reported back. Or it's a terse "I figured it out." I try really hard not to do that for internal or public forums. The odds are better than you think that you'll stumble on the same topic a few years from now.

Or it say "Google it" and thats how you ended up there.