Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Absolute truths I unlearned as junior developer

monicalent.com

Post reply on HN
Print view View original

291–300 of 534 posts

Re: Absolute truths I unlearned as junior developer

#291

Post by bunderbunder »

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: New tech creates new problems.

Related: There are no new problems.

Re: Absolute truths I unlearned as junior developer

#292

Post by SkyMarshal »

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: Technical skills matter most.

>Understood as senior: Communication skills matter most.

I see this often, but it needs to be said with a caveat - the second line presupposes the first. Without the first, the second doesn't really matter (or it does but you're in the wrong career).

Re: Absolute truths I unlearned as junior developer

#293

Post by SkyMarshal »

enobrev wrote: post #170
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…

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

>but with better comments

Communication, especially with your future self, is an important skill.

Re: Absolute truths I unlearned as junior developer

#294

Post by gwbas1c »

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…

Well, it's very clear that what the developer was trying to do was not "good enough."

Re: Absolute truths I unlearned as junior developer

#295

Post by Faark »

gridlockd wrote: post #62
snazz wrote: post #48

Earlier quoted context omitted.

This is true with basically everything. Game development attracts more than its fair share of truly horrid code, to the point where success seems almost inversely correlated to code quality. If you decompile Terraria (using CIL, which preserves the object design), for instance, you'll notice that its main class is over 40kLOC and that basically all of the business logic is encoded in one great big chain of if-stateme…

> all of the business logic is encoded in one great big chain of if-statements One of the big lies of OO design is that you can manage that kind of complexity better with objects/classes, that you should factor out functionality into tiny pieces, and so on. Unless you have written (and debugged!) an actual video game, you should spare your judgement.

There are certainly disadvantages. For a start, it keeps freezing my VS code :D

But Modders also have a hard time adding features if logic for all items is in a single function. This seemed exactly what OOP / interfaces were designed for.

Also I'd love to see Terraria's actual source code. The de-compiled versions hat a ton of stuff like

> if (num1 != 109 && num1 != 110 && (num1 != 113 && num1 != 115) && (num1 != 116 && num1 != 117 && num1 != 118)) return;

or

> else if ((int) Main.tile[i, j].type == 19) Type = 94;

20x in a row, with obviously different numbers. Hope the actual code was more readable and just lost a lot in translation. But many more readable styles should be visible in IL (enums, constants, etc). There might also have been some obfuscation (can't remember), but couldn't have a strong one since names were preserved.

But yes, there are also advantages to their style of code. And in the end they delivered a product and that's all that counts.

Re: Absolute truths I unlearned as junior developer

#296

Post by RugnirViking »

jdlshore wrote: post #220
enriquto wrote: post #205

Earlier quoted context omitted.

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

I mean

When I try something new, usually what I learn is not that my assumptions were correct, but the more interesting part is where my assumptions were wrong. This usually only becomes apparent either when writing the code, or in some of the more interesting cases, when debugging.

Re: Absolute truths I unlearned as junior developer

#297

Post by camtarn »

jschwartzi wrote: post #215
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.

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

Line numbers might not stay static. Perhaps referring to a particular function or variable might be better, as well as explaining what it might impact? That way, one can jump to the location, then inspect it to see if the potentially-impacting behaviour still exists.

Definitely useful in the case where it's near-to-impossible to DRY up something, though. Sadly, the limitations of an industrial C environment have led my code to contain a lot of annoying 'If you add something here, make sure to add it to X struct and Y function' comments.

Re: Absolute truths I unlearned as junior developer

#299

Post by TheAceOfHearts »

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…

Sometimes you encounter some questionable code and you wonder: "What idiot wrote this?" So you `git blame` and you find out "Oh, I'm that idiot."

Re: Absolute truths I unlearned as junior developer

#300

Post by camtarn »

mbreese wrote: post #211
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.

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

Yes, this.

Sometimes you have a choice of a clever way to do something, which saves a few lines and uses neat language tricks that you rarely use * , or just doing things the boring way. As long as the boring way is obvious enough, it's often the better choice.

* I'm looking at you, Ruby... :)

Post reply on HN