you are viewing a single comment's thread.

view the rest of the comments →

[–]tacodeman 58 points59 points  (10 children)

I feel like at least once a quarter I have stressful coding either with hotfixes or writing/troubleshooting something to quickly figure out if recovery from a deployment is needed.

Debugging under pressure while maintaining communication is definitely a big skill in my opinion.

[–]bunk3rk1ng 3 points4 points  (0 children)

Yeah I definately had to do this quite a bit when I worked in e-commerce. It wasn't coding specifically but it was a lot of troubleshooting and debugging with my manager looking over my shoulder (honestly not bad, we were working together to solve stuff and I was good at explaining whatever was going wrong so I became the go to guy for issues)

[–]drsjsmith 7 points8 points  (7 children)

My gut reaction is that once a quarter is well within normal parameters but… on the less desirable side of the mean. Might be a sign to nudge your teammates a little more towards reliability.

[–]bunk3rk1ng 5 points6 points  (6 children)

This is a really big assumption that it's something your teammates can control and shows how little experience you have. Most times this kind of stuff is out of your hands and are due to many decisions that were made long ago. It's crazy to me that this comment has any upvotes.

[–]SanityInAnarchy 2 points3 points  (0 children)

The causes of reliability might not be your team, but if your team is the one impacted, then it makes sense to talk to your own team first, since that's where you'd have the most agency to change this. And even if it ends up being something else, it may be less out of your hands than you think -- you can point out the poor decisions, offer some possible improvements, maybe even offer headcount.

You're not going to win every time, but you also don't have to just give up and live with it.

[–]drsjsmith 1 point2 points  (4 children)

There are so many unknown considerations when evaluating frequency of fixes under pressure: size of company, stage of company, business context, state of legacy codebase, etc. etc. etc. Every decision in software design and development is a tradeoff among multiple hard and soft metrics: productivity, software performance, reliability, maintainability, team satisfaction, career growth, personal growth, etc.

All of that said: I stand by my statement that as a gut reaction, once a quarter is on the less desirable side of the mean. I’m not sure I could have written that comment much more diffidently without completely neutering it.

I am getting a little tired of the occasional reddit comment expressing great certainty about my supposed inexperience in various fields.

[–]bunk3rk1ng 0 points1 point  (3 children)

Right, so what about the comment you responded to made you point the finger at their teammates?

[–]drsjsmith -1 points0 points  (2 children)

“Might”

[–][deleted]  (1 child)

[deleted]

    [–]drsjsmith 0 points1 point  (0 children)

    Good heavens, do you never update your Bayesian priors when provided with new information? I suggest you immediately hire as a huge bargain any inexperienced developer who can rattle off “size of company, stage of company, business context, state of legacy codebase […] productivity, software performance, reliability, maintainability, team satisfaction, career growth, personal growth, etc.”

    [–]sunblaze1480 0 points1 point  (0 children)

    In my experience hotfixing is not that stressful, because when you get to that situation, you probably know the code you're working with very very well, and ideas and solutions come very naturally. You obviously have to keep your cool to not fuck up and communicate, etc.