Absolute truths I unlearned as junior developer • Hacker News Board

Re: Absolute truths I unlearned as junior developer

#231

Post by giancarlostoro » Fri, Jun 07, 2019, 4:57 PM UTC

JustSomeNobody wrote: post #133

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: New tech solves old problems. > Understood as senior: New tech creates new problems. This is one all the people who push "new and shiny" need to learn.

I mean, yes and no, sometimes an old systems so bad it really needed to be killed off and replaced. Or would you rather everyone stick to coding in VB6? I rather we all use C# instead of VB6 ;) I'm not implying we only ever use C#, I know there's other languages, just illustrating a shift in the MS windows development ecosystem that was for the better.

Re: Absolute truths I unlearned as junior developer

#232

Post by AnimalMuppet » Fri, Jun 07, 2019, 4:58 PM UTC

yomly wrote: post #36

hashhar wrote: post #8

Earlier quoted context omitted.

I have a rule of thumb to assist with this. If i feel like I have to maintain some state in my mind to understand a particular piece of code then I opt to clean it up since it'll potentially save future developers that time.

The thing is, especially with juniors, cleaning up code leads to a few things: - poorly executed cleanup (aka regressions) - misunderstanding of requirements (new bugs) - "standardization" of naming (now you have two standards https://xkcd.com/927/ ) - restructuring of code/renaming of abstractions which then adds friction to original authors of code (provided they are still around) Left unchecked this can all happen…

I read once someone's estimate that the probability of introducing a bug when fixing a bug is somewhere between 20 and 50 percent. That probably also applies if it's not a bug - if you're just cleaning up something. That should make you think twice.

In particular, it might make you think about game theory. Is the expectation value of this change more bugs, or less? Will making this change have at least a 50% chance of preventing a future bug?

Re: Absolute truths I unlearned as junior developer

#233

Post by ngngngng » Fri, Jun 07, 2019, 4:59 PM UTC

tombert wrote: post #40

About two years ago, I didn't get a promotion to "senior engineer" that I thought I was going to, and I had a huge temper-tantrum to my boss about it as a result (I'm still surprised to this day that I didn't quit on the spot, to be honest). I was upset, because people that seemed to be contributing less and were less-qualified (at least from my admittedly-biased perspective at the time) were promoted to a higher lev…

I'm currently wanting "senior" in my title because of a recurring issue with interviewing for new positions. I often get stuck at talking to HR because from my years of experience they assume I'm MUCH less expensive than I am. I could use the title so that I could stop running into this as much.

Re: Absolute truths I unlearned as junior developer

#234

Post by wan23 » Fri, Jun 07, 2019, 5:00 PM UTC

vortico wrote: post #61

Perhaps the reason for "nobody writes tests" in the real-world isn't primarily because of time/cost, but because virtually no real potential bugs are testable. If you're writing a JPEG encoder or database model handler, yes, you can test that all day, but those things already exist and are well-tested for you. But if you're designing retail software or a web app, there are 2^10000 things that can go wrong, so most co…

This is all wrong. When you have enough people working on a codebase such that not everyone knows everything about it, tests are a great way to document the behavior. They're much better than something like a wiki, in fact, because nobody actually keeps that kind of documentation up to date.

Re: Absolute truths I unlearned as junior developer

#235

Post by ben_w » Fri, Jun 07, 2019, 5:00 PM UTC

Kalium wrote: post #22

agumonkey wrote: post #18

Earlier quoted context omitted.

> Understood as senior: Communication skills matter most. can you give examples ?

I once worked with a brilliant engineer. He was from Hong Kong. He struggled to express his ideas in English. We tended to let him show us in code instead. Sometimes this worked. Sometimes it really, really didn't. It also meant we had a very difficult time discussing larger architectural questions with him or giving him useful feedback on his code.

I’ve recently had a similar problem, only in my case I’m the foreigner who can’t speak the local language. It’s fine except in meetings.

Junior dev me: meetings are a waste of time.

Senior dev me: meetings are the steering wheel, the developers are the engine (https://kitsunesoftware.wordpress.com/2018/01/29/utility-fun...)

Re: Absolute truths I unlearned as junior developer

#236

Post by fendy3002 » Fri, Jun 07, 2019, 5:01 PM UTC

agumonkey wrote: post #18

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: Communication skills matter most. can you give examples ?

It's mainly used when discussing task and making architectural / design decision. Junior usually talk in techincal / implementation terms. While senior usually talk in broader / general / business term.

Moreover junior usually have hard time expressing techincal problem.

Re: Absolute truths I unlearned as junior developer

#237

Post by Scarblac » Fri, Jun 07, 2019, 5:01 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 .

There are absolutely things I was better at back then, mostly because then I spent all my time doing nothing but programming and now a lot of time goes to other activities (meetings, planning, writing, etc).

Re: Absolute truths I unlearned as junior developer

#238

Post by kbenson » Fri, Jun 07, 2019, 5:04 PM UTC

Scarblac wrote: post #237

kbenson wrote: post #206

Earlier quoted context omitted.

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

There are absolutely things I was better at back then, mostly because then I spent all my time doing nothing but programming and now a lot of time goes to other activities (meetings, planning, writing, etc).

Well, yeah, good point. I guess I should temper that with if you're still a full time professional software engineer. I wouldn't expect it to apply to someone that moves partially of fully to a different type of job or activity.

Re: Absolute truths I unlearned as junior developer

#239

Post by jpswade » Fri, Jun 07, 2019, 5:07 PM UTC

I think much of this depends what you are employed to do.

Sometimes it's about making things less complex, which means good practices, code quality, clean code and testing means you can afford a bit more risk.

Equally, sometimes you employed to just get things done, make it work, even fake it till you make it, proof of concepts, minimum viable products, etc.

I've done both, I enjoy both, but they are two different modes of working.

Ultimately the answer is "it depends" and milage may vary.

Quality is a journey not a destination.

Yes, put delivering value above anything else, sometimes that value is quality.

Re: Absolute truths I unlearned as junior developer

#240

Post by drbojingle » Fri, Jun 07, 2019, 5:10 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…

I agree with you but I can't bear to say code doesn't matter. Try not writing any and see how valuable software is without it. Better yet, delete it and see what happens :D. I expect Codeless will become a thing one day but, until that day comes you will write code, because the code is necessary and I have trouble saying that the code is needed but also doesn't matter. Least important necessity maybe?