Absolute truths I unlearned as junior developer (2019)
monicalent.com
Absolute truths I unlearned as junior developer (2019)
1–10 of 269 posts
Re: Absolute truths I unlearned as junior developer (2019)
#2> Good enough is good enough.
I’ve only been in my first role for about two months and this one hit the hardest for me personally.
I imagine it has a direct correlation with impostor syndrome, but I spend a lot of time writing things over and over again because in the back of my mind I’m thinking “is this the correct approach? Will they think I’m failing if it’s not how they’d do it?”
I consider myself lucky that I’m in a position with a great team that’s very helpful but I struggle to balance the line of when to ask questions - which often stems from not trusting myself to be to their standard.
Re: Absolute truths I unlearned as junior developer (2019)
#3Small piece of wisdom I received when I was an intern:
"Never get sentimental with your code"
Re: Absolute truths I unlearned as junior developer (2019)
#4The truth I had to unlearn is that coding is a solitary activity, and that coding is the most important part of a senior software engineer’s job. Now I rarely have the chance to code for a few hours straight because if I have enough information to write code then all that’s left is the easy part. The hard part is coordinating, defining the problem, planning for the future, and communicating the current status of the problem. Not to mention onboarding newer devs who haven’t learned the technologies yet.
Re: Absolute truths I unlearned as junior developer (2019)
#5> Things like indendetation, formatting, naming – god forbid you did it differently than I would have.
I agree with chilling out about this when it's a human making the changes...except now that we have autoformatters we can actually be more pedantic about this than ever before :) If the autoformatter doesn't agree with what you wrote, bam, red CI.
> Everyone writes tests
A big thing I've learned over the years is that making your code testable often takes more foresight and experience than actually writing the tests. "What's the right way to test this?" becomes an important question when starting something new. And "Can we make it easier to test this?" becomes an important question when inheriting something.
Re: Absolute truths I unlearned as junior developer (2019)
#6> Good enough is good enough. I’ve only been in my first role for about two months and this one hit the hardest for me personally. I imagine it has a direct correlation with impostor syndrome, but I spend a lot of time writing things over and over again because in the back of my mind I’m thinking “is this the correct approach? Will they think I’m failing if it’s not how they’d do it?” I consider myself lucky that I’m…
It's a hard one to learn in the first 5 or 10 years or so I think. For me the correct approach is the one that solves the problem, feels good enough for the user (with varying definitions of good enough depending on the business goals), and doesn't create a maintenance headache.
There is a large amount of room in there for correct solutions.
Re: Absolute truths I unlearned as junior developer (2019)
#7> Things like indendetation, formatting, naming – god forbid you did it differently than I would have. I agree with chilling out about this when it's a human making the changes...except now that we have autoformatters we can actually be more pedantic about this than ever before :) If the autoformatter doesn't agree with what you wrote, bam, red CI. > Everyone writes tests A big thing I've learned over the years is th…
This is why a lot of people don't test or claim that testing takes more time since "we spend half our time fixing the tests" - a lack the experience to design code that's testable.
I think it's also worth pointing out that up to a point, code that's testable tends to be more maintainable. This largely has to do with coupling and cohesion. Code that's hard to test in indicative of too much coupling and/or not enough cohesion.
This pendulum can swing too far the other way though. I hate when relatively straightforward code is made more complicated in the name of testing (often comes up when dealing with non deterministic sources of data, such as the current time). But this, in my opinion, is a comparatively small problem.
100% you should test private functions if it makes sense. Whether something is public or not has no bearing on the value you'll derive from testing. If anything, sometimes you can avoid real headache by focusing specifically on the private function (by definition, the private function has to be more focused than the public function calling it).
Also, we should probably all be fuzzing more.
Re: Absolute truths I unlearned as junior developer (2019)
#8The truth I had to unlearn is that coding is a solitary activity, and that coding is the most important part of a senior software engineer’s job. Now I rarely have the chance to code for a few hours straight because if I have enough information to write code then all that’s left is the easy part. The hard part is coordinating, defining the problem, planning for the future, and communicating the current status of the…
That's not a senior engineer's job.. that's a job that has scope creeped into many roles: project management, lead developer, project owner and a trainer. Are you doing QA and managing the production servers as well?
Re: Absolute truths I unlearned as junior developer (2019)
#9For me, it was that I thought that being a good programmer was that I write clean code with enough abstraction and indirection to make it future proof.
Boy I was wrong. Unless you’re doing the same thing you’ve done for years, you can’t tell the future. And just when your unnecessary abstraction is wrong, this the reason why we’re talking about tech debt in the first place. Because nobody wants to touch it.
Unfortunately, I didn’t have anyone to tell me this for the longest time. It wasn’t until I had to fix a bug for something I wrote in the past, and I couldn’t figure out just what I wrote.
Now I try to write dumb and simple (yet sensible) code until there’s a good reason for abstractions. I have nothing to prove at this point in my career.
Re: Absolute truths I unlearned as junior developer (2019)
#10Discussion at the time, 516 comments: