Absolute truths I unlearned as junior developer • Hacker News Board

Re: Absolute truths I unlearned as junior developer

#211

Post by mbreese » Fri, Jun 07, 2019, 4:45 PM UTC

docker_up wrote: post #72

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

> For me, any code that I wrote more than 3 weeks, I forgot. That's why I comment the hell out of my code.

I couldn't agree more.

A while back I got in the habit of trying to write code for "me, six-months from now". So, if I think I can explain it to "future me", then I'm happy. Ever since I started doing that, I've been much happier with "past me"'s code.

In addition to comments (particularly around hard to grok code), I've also started trying to be as consistent as possible in code structure and naming schemes. This also helps a lot.

Re: Absolute truths I unlearned as junior developer

#212

Post by gamblor956 » Fri, Jun 07, 2019, 4:45 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…

code can be much more precise and clear than English

Agreed, code is much more precise than English. But precision is not the same thing as being meaningful and without context, precision is useless. Code generally sucks at context, which is why every programming language worth its salt has comments.

Re: Absolute truths I unlearned as junior developer

#213

Post by chrshawkes » Fri, Jun 07, 2019, 4:45 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…

I don't think anybody would argue pushing bugs is good enough or qualifies as such under any circumstance. I think good enough means that no codebase is perfect and working with nitpicky perfect types is the absolute worst IMO. Not only that, I've seen those codebases too and they are often times just as convoluted and messy, although without trailing whitespace and no missing semicolons.

Re: Absolute truths I unlearned as junior developer

#214

Post by toxik » Fri, Jun 07, 2019, 4:45 PM UTC

kbenson wrote: post #206

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: Legacy code that I wrote myself is hard to read. As it should be. If your code from a five to ten years ago doesn't make you cringe at least a little bit, the right way to view that is not that you were doing a good job back then, but that you haven't gotten any better since then .

I disagree with this perspective. You of yesteryear is in many ways just another programmer you have to work with; if that makes you cringe, you may be taking a bit too much pride in your work.

Re: Absolute truths I unlearned as junior developer

#215

Post by jschwartzi » Fri, Jun 07, 2019, 4:46 PM UTC

docker_up wrote: post #72

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

Yeah, whoever told you that has never had the sinking feeling of digging in to a 300 or 1000 LOC function with a pretty refactor in mind only to see just how much of the system relies on that one function. It's really only an issue if you try to be diligent about testing the work you produce, in which case that little refactor could cost your team a week or a month of additional testing while they verify that you didn't break anything.

Or you could sneak one more little if statement or some copy/paste in there to fix it instead, and add a little comment that says "If you modify this line, please verify that your change doesn't impact Line XXX of file FFFF as well." And then you're done in less than a day and have saved a huge amount of testing.

Re: Absolute truths I unlearned as junior developer

#216

Post by rb808 » Fri, Jun 07, 2019, 4:46 PM UTC

mceachen wrote: post #208

ltc5505 wrote: post #130

Earlier quoted context omitted.

Interestingly, I'm at that unproductive phase right now. On one hand, I could fix this fast and ugly, but then my code is going to look no different then all the code I go home and complain about. On the other hand, I can try to make my code really nice and abstracted with well thought out design patterns like 's. So, on one hand I'm a hypocrite and on the other hand I'm slow and hardly productive because I am just l…

This is surely debatable, but the best code is readable by Engineers of Tomorrow with the least amount of effort. Getting code reviews from other people that understand this, or pair programming with them, is the best way to practice empathy for those future code readers (which very well may be you). Don't focus on commenting about how . They can read the code for that, and those comments almost always drift from tru…

I think that is nice, but may not be aligned with what the company wants. If is respected, well paid and promoted then by all means try to emulate them. if is gold plating a lot of small projects that dont really help the business, and hackers are getting rewarded for delivering new functionality that the bosses want, then that route is better.

Re: Absolute truths I unlearned as junior developer

#217

Post by SamuelAdams » Fri, Jun 07, 2019, 4:46 PM UTC

cuddlecake wrote: post #129

SamuelAdams wrote: post #97

> Documentation lies This is a very true statement, especially concerning legacy codebases. I have worked on some projects that have had several developers make changes to it. The original developers were great: they commented every class, had comments for all the methods, and added comments for any complex or funky logic. Then the changes came. And the next developers hacked and slashed the existing code base to mee…

I was thinking about this and because of the book _Clean Code_ I had already decided that comments will lie at some point. So I moved towards descriptive variable and function names, but those could lie as well. So I'm thinking, how could we ensure truthful intentions at all? And I think only a combination of small pull requests, good variable and function names and a thorough review can save us here. But I don't kno…

Personally, I think the best thing is education. Now more than ever (in this agile / scrum world) devs are making small, quick changes to existing codebases. These small changes add up, and what was once a great, clean codebase is now riddled with hacks and mis-documented code.

I think educating the developer / team on the existing codebase first would be the right step. Spend a day just going through the code. Learn how it connects, learn the full scope of the project. After this, make your changes in a way that fit into the existing code.

I've had too many offshore developers re-imnplement existing functionality, like reading data from an excel spreadsheet, simply because they did not look through the code that was already there. It cost them 2 hours of work to add another library and implement it, when the code they already needed was a simple using statement away.

In theory, this is why good orgs have senior devs: they know the codebases already. Furthermore, they should be reviewing these changesets to call out devs who mis-document or scatter about the code. But senior devs are people too, and they miss things. Additionally, some codebases are enormously complex, and it's virtually impossible for a single dev to understand it completely.

Re: Absolute truths I unlearned as junior developer

#218

Post by DubiousPusher » Fri, Jun 07, 2019, 4:47 PM UTC

jmull wrote: post #42

Great post. Lot's of good stuff. Just to comment on one part at random: Code reviews would be more useful if review feedback was categorized: 1. is this a matter of personal style? 2. is this a judgement call? 3. is this something that is just wrong and has to be fixed? 4. is this in-scope or actually a separate issue? (This is off the top of my head, so this is more of an example of the kind of categorization I'm ta…

The last couple of teams I've been on have had the custom of prefixing any issue that is purely stylistic in nature with 'nit:'.

Re: Absolute truths I unlearned as junior developer

#219

Post by aardshark » Fri, Jun 07, 2019, 4:47 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…

I don't understand what sort of environment you work in where you don't encounter situations where comments could add clarity to the code.

Do you never see code that has global side effects? Or that is written a particular way to take advantage of the hardware that it is running on? Or any other of the many ways that the intention and meaning of a piece of code within the codebase it exists in can be not immediately obvious?

Re: Absolute truths I unlearned as junior developer

#220

Post by jdlshore » Fri, Jun 07, 2019, 4:49 PM UTC

enriquto wrote: post #205

dahart wrote: post #34

Earlier quoted context omitted.

Oh this is such a good comment! > Legacy code that I wrote myself is hard to read. Sometimes I don’t even recognize me as the author for a while. Realizing I’m reading something I wrote and can’t understand it without studying carefully has been rather surprising and reminds me of 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…

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

False dichotomy, anyone? I learn more from trying new ideas than debugging complex code.