Absolute truths I unlearned as junior developer • Hacker News Board

Re: Absolute truths I unlearned as junior developer

#451

Post by jv22222 » Sat, Jun 08, 2019, 2:11 AM UTC

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…

> Learned as junior: If you report an OS bug or some other deep problem, seniors will not believe you

Same thing happens in reverse! ;)

A few years back I told 3 devs who reported to me that there was a bug in Laravel database sub system.

The bug was: If you use the word "returning" in any Laravel insert query the system would crash (Laravel 3 & 4).

None of my guys would believe me!

I finally tracked the bug down to

> laravel/database/connection.php

> public function query($sql, $bindings = array()) > { > ... etc ... > elseif (stripos($sql, 'insert') === 0 and stripos($sql, 'returning') !== false)

I sent an email to the Laravel team and never got a response... but the bug stopped happening some time after that ;)

I think it was relate to mySQL version as well.

Re: Absolute truths I unlearned as junior developer

#452

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

esoterica wrote: post #253

lmm wrote: post #168

Earlier quoted context omitted.

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

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…

If there's an important difference (e.g. a performance requirement that a hash table wouldn't meet), I'd have a test that checks that. If not, it's probably an arbitrary choice that doesn't matter. If the decision is worth recording, it's worth recording properly.

Re: Absolute truths I unlearned as junior developer

#453

Post by lmm » Sat, Jun 08, 2019, 2:18 AM UTC

ken wrote: post #256

lmm wrote: post #168

Earlier quoted context omitted.

> 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. I've been writing Lisp off and on since late last century, so I know full well the value of declarative code. Preaching to the choir, there! But I can also report that every real program I've ever written (i.e., that had at least one user) needed significant non-declarative parts. And for those non-…

> Writing a trampoline necessitates a bunch of "why"s, and there's no way to just substitute a declaration for it (without pushing the whole mess somewhere else).

I've got a trampoline in my codebase to avoid a stack overflow. The why is the test that a certain repeated operation doesn't stack overflow.

There are a number of places where it could've been implemented with one technique or another, but there's no particular reason that the approach I've taken should be better or worse than one of the other options. If there was, I'd want to formalise that (e.g. if I'd chosen one approach because it performed better than another, I'd want a benchmark test that actually checked that).

Re: Absolute truths I unlearned as junior developer

#454

Post by dd36 » Sat, Jun 08, 2019, 2:20 AM UTC

Sharlin wrote: post #251

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…

This is probably the primary actual use case for comments. Explain why something is done the way it is; to justify to those who come after why Chesterton's Fence [1] should apply in this case. [1] https://wiki.lesswrong.com/wiki/Chesterton%27s_Fence

Same idea should apply to laws. The why gets forgotten a half century later because the problem was solved but not well documented. Because the problem is no longer happening, they think the law must no longer be necessary.

Re: Absolute truths I unlearned as junior developer

#455

Post by milesvp » Sat, Jun 08, 2019, 2:33 AM UTC

kbp wrote: post #378

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

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 something like, so and so tends to forget certain kinds of edge cases, but they never seem to screw up this kind of logic... so I bet the problem is related to... ah found the problem. But never blame someone for creating bugs, unless it’s really egregious, and then, only if you can help them with better habits going forwards.

Re: Absolute truths I unlearned as junior developer

#456

Post by JamesBarney » Sat, Jun 08, 2019, 3:05 AM UTC

lmm wrote: post #450

JamesBarney wrote: post #306

Earlier quoted context omitted.

Comments rot, but so does everything else such as type names, tests, variable names, field names, designs, architectures, etc.

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.

Re: Absolute truths I unlearned as junior developer

#457

Post by mgkimsal » Sat, Jun 08, 2019, 3:13 AM UTC

jdsully wrote: post #346

tomsmeding wrote: post #227

Earlier quoted context omitted.

> > seniors [...] complain about the low quality of junior code [...] their own code from 6 months ago. > What classes as 'senior' that their own coding style has changed that much in 6 months? O.o Your code style can remain exactly the same, and it would still happen. The reason is not that you would write the code differently today, but that you forgot the issues and edge cases that made you write it like that then…

Here we get to the real heart of the problem. Engineers of all levels seem to default into “this code is shit - I could do better” instead of having some empathy and considering they don’t have the whole picture. But the wrong lesson seems to be taken away from this. It’s not that all code is shit - it’s that you aren’t good at reading the code yet if you can’t see all the little hairs and bug fixes.

> Engineers of all levels seem to default into “this code is shit - I could do better” instead of having some empathy and considering they don’t have the whole picture.

several projects I've come in to - yeah, the code what shit, and yeah, I could do better. And I've done better. By asking questions, documenting the answers, writing sample data, and writing tests.

I get that code can be sloppy, have edge cases, etc. Took over a project that was halfway migrated from CI to Laravel. The migrator had close to a year on this 'migration'. We had not one unit test case, no migrations, no seeders, no integration tests when we took over. What we had was piles of half-baked uncommented model code, over-reliance on magic methods, Laravel/CI models with the same names and method names often being used in the same request but with unintentionally dissimilar behavior.

The 'code' isn't the (whole) problem. All the other stuff around the code that provides the context is the problem. We had ~ 20 tickets in a tracking system with vague notes, and were given 5 email threads of discussion about functionality questions, none with actual resolution.

> it’s that you aren’t good at reading the code yet if you can’t see all the little hairs and bug fixes.

Or... the person writing it before you simply didn't know how to write/document.

Sometimes - really, honestly - you can actually "do it better" because... really, honestly, sometimes you are actually better - more competent, more experienced, more diligent, more professional - than the person who left the code you're working on. Not always, but not never.

Re: Absolute truths I unlearned as junior developer

#458

Post by mr_toad » Sat, Jun 08, 2019, 3:23 AM UTC

dd36 wrote: post #454

Sharlin wrote: post #251

Earlier quoted context omitted.

This is probably the primary actual use case for comments. Explain why something is done the way it is; to justify to those who come after why Chesterton's Fence [1] should apply in this case. [1] https://wiki.lesswrong.com/wiki/Chesterton%27s_Fence

Same idea should apply to laws. The why gets forgotten a half century later because the problem was solved but not well documented. Because the problem is no longer happening, they think the law must no longer be necessary.

As a counterpoint, we often end up with laws, traditions, and social mores that long outlive whatever rationale they had for them in the first place. (Assuming they had a rationale, and weren’t just based on fear and superstition).

Re: Absolute truths I unlearned as junior developer

#459

Post by AnimalMuppet » Sat, Jun 08, 2019, 3:39 AM UTC

jayd16 wrote: post #434

AnimalMuppet wrote: post #390

Earlier quoted context omitted.

I see absolutely nothing in the Agile Manifesto that precludes tests. Nor do I see any basis for saying that tests attempt to predict needs. They are for the future, true, but they're also for the present - as is every line of code you write.

>Nor do I see any basis for saying that tests attempt to predict needs The prediction is that the next time you revisit this code your original assumptions will still be valid. In games, which is my background, game rules (our business logic) are constantly changing during development to the point that you're fighting tests constantly for no benefit. Games are an extreme case but you can extrapolate the experience. Y…

> The prediction is that the next time you revisit this code your original assumptions will still be valid.

No. The tests will encode the previous assumptions. When you run them, and they fail, either you broke something or one of the previous assumptions is no longer valid. But the tests give you an automated way of recognizing which assumptions you'd better think about, to see if they are still valid.

> Games are an extreme case but you can extrapolate the experience.

No - no more than you can extrapolate my experience, which is having core logic that is (mostly) valid a decade later.

> I'm arguing against code coverage and test enforcement.

Or at least against those things in areas that are constantly changing. Even in your world, though, are there areas that change more slowly than the game rules? Would it make sense to have tests for those areas, and not for the game rules?

Re: Absolute truths I unlearned as junior developer

#460

Post by seer » Sat, Jun 08, 2019, 3:40 AM UTC

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…

Hah I got the exact opposite realization actually.

Yes if you boil it down to it’s essentials you are right the customer is the one with the money, so satisfying his needs/desires is what matters.

But, and thats a big but, we as devs are also humans, we also have desires and needs, and in the long run companies that successfully balance the needs of its users with the needs of its workforce get the best workers, which solve the problems of their users better/cheaper/faster.

So it’s more of an equilibrium kinda thing. If you stray too much in any direction the organization tanks - either the users loose faith, or the people satisfying theirs needs do, which leads to failure just as much.

The complexity with balancing this usually stems from the fact that both of those variables are subjective to their respective environment - users can tolerate bad solutions if there are no alternatives available, same with devs.

And that is also a subject to information availability - devs can be ok with their situation because they don’t know what salaries are at that other place for example.