Absolute truths I unlearned as junior developer • Hacker News Board

Re: Absolute truths I unlearned as junior developer

#531

Post by xsmasher » Tue, Jun 11, 2019, 10:33 PM UTC

Gibbon1 wrote: post #257

mbreese wrote: post #211

Earlier quoted context omitted.

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

I write notes to my future self all the time. Meta comment: This is bullshit and has problems with this that and the other thing. But to fix that I'd have to refactor this other module and I'm not going to do that now. And the other thing I'm drawing a blank. Meta comment2: I don't think the code needs to do this here. But I can't prove it right now. Meta comment3: We absolutely need to do this exactly as it is. Beca…

> Meta comment3: We absolutely need to do this exactly as it is. Because otherwise bad thing happens, which you probably won't see until it hits production.

This is the highest purpose that a comment can fulfill - telling why you are doing something that looks stupid.

Re: Absolute truths I unlearned as junior developer

#532

Post by vmurthy » Wed, Jun 12, 2019, 10:54 AM UTC

world32 wrote: post #477

vmurthy wrote: post #146

Earlier quoted context omitted.

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.

You're right that the end user doesn't care about what technology you use, but do they care about things not working? Do they care that a new feature takes 3 months to develop when it could have taken 1 month if the code had been better architected? Its funny to see management types dismiss the programmers as being "airy-fairy" when they talk about things like code quality and technology stacks but then they wonder w…

My bad if I gave you the wrong impression about management types. You're right that things should work. What I meant was this: assume you have technology stack A and B each with its own pros and cons (whether tech maturity, programmer skills or what have you). Then, higher management expects the lead programmer/engineering manager to review the pros and cons and take the decision and deliver keeping the end user in mind. Whether stack A has xyz features which will do blah-blah-blah to the team is less relevant than the deliverable. Hope it is clear :-)

Re: Absolute truths I unlearned as junior developer

#533

Post by appleflaxen » Tue, Jun 18, 2019, 8:24 AM UTC

gambiting wrote: post #524

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.

I'm sad that I cannot share my experiences the same way :-( 99% of my "interesting" bugs are almost all Xbox One/PS4 related, so I can't write a blog post about "how I found out that Sony's implementation of file read is not compatible with regular stdio" - it's hugely interesting but this stuff is NDA'd to such an extent that I wouldn't risk writing openly about it - but I'd love to.

.

Re: Absolute truths I unlearned as junior developer

#534

Post by bmon » Wed, Jun 19, 2019, 7:03 AM UTC

alexhutcheson wrote: post #132

Multiple of these points could be grouped under the general belief that "Everything is equally important". The #1 change required for growing into a senior role is to form a habit of ruthless prioritization of how you spend your time (and your team's time, if applicable). Often you end up in situations where all of the following are true: 1. Your teammate or colleague is designing or implementing something. 2. You ha…

This really hits home to me. I worked on a project where I encountered an almost identical situation to the one you described. I stuck my foot down, and insisted we build the objectively better solution. We did, and only much later did I realise the damage I had done to my coworker's morale.

Looking back, I completely regret it. If I had my time again, I would stop after explaining the alternate solution. The time we would have had to spend fixing the problems with the original approach would have been worth it.

I've heard this repeated a lot, but I'm really only just starting to understand: Often the best leaders speak up less, rather than more.