I worked with a guy who did 12 hour days, closed tons of tickets but his code was full of bugs. We were writing trading software and he would handle errors by silently failing.
I worked with someone else who didn’t have a computer at home. Their coding style was “write code that I don’t have to support, I don’t want to get emails while I’m sleeping”. They wrote mega defensive and very boring code. Their code never has any bugs, but they took longer to write it.
Enjoyed working with person two, despised person one.
According to management, person two was not known and person one was a rockstar.
For me that's very much been an experience thing. It's often not just motivation, but also that handling errors properly can be genuinely difficult compared to writing the happy paths of code.
It's probably a good thing to do a training/knowledge sharing on in an org (seniors show juniors different ways to handle errors).
It is a questions of taking responsibility, willingness to pay attention and learn. We all start out with the happy path which automatically leads to plenty of learning opportunities. The question is how does one deal with them. While training and mentoring can help I believe most learning occurs while reading/reflecting on other peoples code and fixing own and others mistakes.
> closer tons of tickets but his code was full of bugs
Yeah, total closed ticket count is a terrible metric. If closing one ticket in a rush opens two bug tickets, that’s one ticket opened overall. Much harder to track though!
> They wrote mega defensive and very boring code
How I love boring code, and I am getting more defensive. Good-sleep-oriented-programming.
For much of my career I took technical debt on myself because I felt uncomfortable giving generous time estimations with ample buffers. I am ashamed. But now I learn to push the breaks, ask for help and escalate unexpected problems as early as possible in the project. I don't need the trendiest tech on my resume as long as the team is happy and sleep well.
I worked with someone else who didn’t have a computer at home. Their coding style was “write code that I don’t have to support, I don’t want to get emails while I’m sleeping”. They wrote mega defensive and very boring code. Their code never has any bugs, but they took longer to write it.
Enjoyed working with person two, despised person one.
According to management, person two was not known and person one was a rockstar.