Absolute truths I unlearned as junior developer • Hacker News Board

Re: Absolute truths I unlearned as junior developer

#141

Post by fengb » Fri, Jun 07, 2019, 3:43 PM 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…

A corollary to this is: the code should match the problem domain.

If the business problem is complicated, trying to further simplify the code usually makes it awkwardly abstracted and extra brittle. The fix should not be _just_ cleaning up the code, but rather trying to resolve the original usecase.

Re: Absolute truths I unlearned as junior developer

#142

Post by mevile » Fri, Jun 07, 2019, 3:43 PM UTC

AdmiralAsshat wrote: post #98

> 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. That one hits home. I felt like I was being so helpful when I, fresh-eyed after finishing some entry-level C language book, suggested that we should implement unit tests to the legacy software. The product lead, to his credit, did not chew me o…

Tests are a really important part of development. There's nothing wrong with suggesting tests. The wrong thing is to insist on it to the point it creates a conflict with you and your team. Either set an example and write tests and see if it creates value and your team is OK with it, make a convincing argument or if you think tests are needed very badly because everything is broken all the time and you can't convince anyone, get a new job. Sticking around and being bitter about it is the thing that's bad.

I usually ask upfront in an interview if the team writes tests and if they don't and I get the idea they don't want to I probably wouldn't work there.

Re: Absolute truths I unlearned as junior developer

#143

Post by ZeroMinx » Fri, Jun 07, 2019, 3:44 PM UTC

lmm wrote: post #111

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.

Early 30s here and I've realised that comments are worse than useless most of the time. Nothing enforces that the comment is correct, so a significant proportion of comments will be false, so no comments can be relied upon. Descriptive types, clear tests, and sensible variable names are much more effective strategies for making code understandable. Comments should be a last-resort stopgap.

> Comments should be a last-resort stopgap

I'd add; Comments should be saying _why_ this crazy method is here. You can always parse the code to figure out what it does. In a few months/years (depending on your memory) you will not remember _why_ this code was put in place.

Re: Absolute truths I unlearned as junior developer

#144

Post by JustSomeNobody » Fri, Jun 07, 2019, 3:44 PM UTC

scriptkiddy wrote: post #116

I don't know if I can call myself a senior. (none of the companies I've worked for have used senior/junior in their job titles), but one of the most important pieces of information I've picked up is this: The Simplest way is usually the right way. What I mean is that fancy algorithms, sweeping design patterns, and "clever" pieces of code are generally not the best approach to 99% of coding specific problems. Example:…

Properly choosing an algorithm or data structure is first knowing the nature of your data.

Re: Absolute truths I unlearned as junior developer

#145

Post by dbingham » Fri, Jun 07, 2019, 3:45 PM UTC

lmm wrote: post #111

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.

Early 30s here and I've realised that comments are worse than useless most of the time. Nothing enforces that the comment is correct, so a significant proportion of comments will be false, so no comments can be relied upon. Descriptive types, clear tests, and sensible variable names are much more effective strategies for making code understandable. Comments should be a last-resort stopgap.

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 don't have to decay. Discipline is important. Culture is important. And yes, these have to be intentionally set and upheld.

If you set a culture of discipline around maintaining the comments with the code, and ensuring they are updated, then it's really not that hard to do it. If the developer doesn't remember to do it when making changes, then the code reviewer can catch it and enforce it.

And nothing really substitutes for an english language explanation of the "why" and the intention of a particular section of code. A good comment explaining why something was done a particular way, or what the code was intended to accomplish, can save hours of walking up and down call stacks. It's also something that cannot be communicated through unit tests, or even integration tests, a lot of the time. Those communicate the "what" and the "how" - not the "why".

Re: Absolute truths I unlearned as junior developer

#146

Post by vmurthy » Fri, Jun 07, 2019, 3:45 PM 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…

Perfecto! As a programmer turned product manager, I see this first hand every single day. The end user doesn’t care what technology you use as long as it solves their problem(s). My managers don’t care what technology my team uses as long as timelines and budgets are met. I’m astonished and sometimes smile at how my old programmer self wouldn’t understand this basic fact.

Re: Absolute truths I unlearned as junior developer

#147

Post by fredsir » Fri, Jun 07, 2019, 3:47 PM UTC

patagonia wrote: post #96

RussianCow wrote: post #80

Earlier quoted context omitted.

This is why I always respond to questions about what I do with "software engineer". I've noticed people seem to perceive "engineering" as more serious than "programming", and it helps to promote the idea that I build things to solve problems and don't just sit there turning designs into code.

From Wikipedia: Engineers, as practitioners of engineering, are people who invent, design, analyse, build, and test machines, systems, structures and materials to fulfill objectives and requirements while considering the limitations imposed by practicality, regulation, safety, and cost. If you’re doing that you’re an engineer. Hopefully we are all doing that.

I feel like in areas like software, hardware, electrical, mechanical -construction, there are two descriptors of practitioners and they are at opposite ends; hackers and engineers. At least that’s how I think about myself. Sometimes what I do is hacking together a proof of concept, and sometimes I’m engineering a product.

Of course, there is something in the middle, and for software, that is probably “coders” or “programmers”.

Re: Absolute truths I unlearned as junior developer

#148

Post by [deleted] » Fri, Jun 07, 2019, 3:48 PM UTC

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…

[deleted]

Re: Absolute truths I unlearned as junior developer

#149

Post by bryanrasmussen » Fri, Jun 07, 2019, 3:49 PM UTC

archagon wrote: post #86

pdpi wrote: post #74

Earlier quoted context omitted.

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 dunno. I’m a programmer because I like solving problems through code, and I’m not really interested in solving problems outside this toolset. Some artists were exclusively painters, and we still call them that.

Picasso could paint a whole house, in one day - two days tops if you wanted multiple colors.

Re: Absolute truths I unlearned as junior developer

#150

Post by edw519 » Fri, Jun 07, 2019, 3:49 PM UTC

Excellent article! Thank you, Monica. You just put into words a whole bunch of stuff that I always "sensed" but never "said".

After spending 7 million years (it sure seems like it) cleaning up the most vile garbage code you could possibly imagine, I'd like to elaborate on this:

Architecture is more important than nitpicking. While a small line of code could be improved, the stuff that tends to cause bigger problems down the line are usually architectural. I should’ve focused more on the structure of the application than tiny bits of code early on.

Architecture = the sum of all those seemingly unimportant "tiny bits of code".

It seems like every time I have to refactor or (heaven forbid) rewrite, I have to start deep down in those tiny bits. I've worked places with all these "genius" architects, but when I dive deep down into the code, I find a sewer than couldn't possibly support software life as we know it, no matter how brilliantly it was conceived.

Fellow programmers, you probably know exactly what I'm talking about, all those cancerous tiny bits that kill even the strongest patients:

  - variables so horribly named that no one could ever interpret them
  - 800 line iterations surely destined to be broken by a maintenance programmer
  - conditionals so illogical that no one can tell if they ever worked
  - early exits to hell that can only be fixed by rewriting
  - double negative logic that could not never fail to break
  - 8 lines of code where 1 could do
  -

Great architecture comes from both directions, "above" and "below". From my experience (unlearned as a junior developer :-) ), 90% of the problems have always seemed to come from below.

Get good at the trees and the forest will flourish.