Balancing deadlines VS quality work at job

Software Engineer at Taro Community3 months ago

Was going through the code quality course where Alex talks about handling edge cases and self-commenting PR's to encourage healthy discussions etc. These are all great for quality work, but I remember in my past internships in these "tricky" implementation parts, instead of self-commenting I would secretly hope no one brings that up so that I could land the PR fast and move on to the next task in the current sprint. This behavior originated from the pressure of completing all tasks assigned in the current sprint.

Rn i am at a fast paced company. its a lot of work to just complete my own work within the current sprint. i know i should be offering thorough code reviews and even propose potential collaborations on fixes or encourage discussion. but i dont propose these collaboration/discussions bcoz i know these are not NECESSITY? these are kinda nice to haves right? what if i fail to deliver my bare minimum (ie completing all current sprint tickets) while trying to do these 'nice to haves'?

What's a sweet spot between balancing quality and deadlines? I also enjoy having discussions with other engineers, but the fear of not being able to complete other tasks within the deadline keeps me from pursuing these healthy conversations.

I also have another question (this is my first full time job so i don't really know) - my company offers unlimited sick days off. If I call a day off due to sickness, will I still be expected to complete all my sprint tasks within that sprint? by let's say working extra hours later.

5252 Views

33 Comments

Discussion

(3 comments)

2
Jay Vercellone
•Software Engineer
3 months ago
In my experience, it depends on how experienced/technical your manager is. But to be honest, it is my opinion that quality is non-negotiable. Moving fast by delivering a low quality change will make the next person (which might be yourself) move slower. If there are important discussions to have, merging the PR should not be the top priority, and in practice everyone’s drawn to these discussions so I don’t think your teammates will be upset about that. Now, if you think that in order to meet a deadline you have to sacrifice quality, then the estimation/prediction is almost certainly wrong and you need to start pushing back on those estimates because they clearly didn’t factor quality into the necessary efforts.
0
Jonathan C
•I just work here @ Robinhood
3 months ago
A sprint is just an arbritrary construct to ensure some level of consistency. I'd focus less on completing the sprint and more on proactively calling out if the corners you're cutting should be cut or not. In the end, business impact is what matters the most if you want to judge the value of your work.
0
Charlie Vuong
•Eng @ Taro
3 months ago
I remember in my past internships in these "tricky" implementation parts

There are a few ways to handle the tricky implementation:

Try to find out how necessary it is in the overall product. Is it something that only affects a small percentage of users. Is it even necessary to implement?

Try to brainstorm ideas, usually with a PM, to see if you can think of out of the box, novel solutions to get a similar result with less work

Split up the task into smaller tasks so you can fast follow in the next sprint

Sometimes, you just have to deal with the problem. Make sure you can articulate why the edge case is a pain to handle and flag it to your team, so they know, and maybe they can offer some insight

I will say that, given enough users using your product, if you try to merge in a change knowing about an edge case, someone else is probably going to discover it, too. So, it's better to flag it or deal with it now rather than in a production outage where there is more visibility and pressure on the line.