7 ms·
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 s
by 4pkjai 3y ago
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.
- davedx 3y agoFor 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).
- heisenbit 3y agoIt 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.
- burrish 3y agoPerson two sounds great to work with, would love to be like them
- DougBTX 3y ago> 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!
- prakhar897 3y agoIsn't this highly dependent on management too? Person 2 would get fired in a startup because he/she didn't create features fast enough.
- Arisaka1 3y agoAfaik person 2 would get fired from any company that touts its internal competitiveness and technical challenges as a benefit.
- anoplus 3y ago> 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.
- wigster 3y ago> sleep-oriented-programming nice. ;-)
- globular-toast 3y agoSounds like you and the other guy were in the wrong job then. Don't blame the rockstar. Go and find the place where you're the rockstar.
- 4pkjai 3y agoAgreed!
- Shorn 3y agoThe best "architects" are those who have been both of these people.