How fast should you be able to work if you properly follow all the taro advice around code quality and velocity?
My main worry is if I’m moving too slow
but I’ve observed that once I come up with a plan of action in my project and break it down I can move at a jogging type pace and submit one individual piece every day. And still look fine to my peers and like not feel exhausted every day.
Even with the coding fluency. Since I’ve worked with off the shelf open source stuff for a bit so I’ve noticed once I know how to get stuff to work (past boilerplate land) the real edge case work usually gets straightforward (avoid npe serialization errors or index) in your single pieces of atomic work and if there’s a more complicated edge case you just handle that separately.
My main concern is if this behavior is fine if ur a mid level. Each day in my daily work I just front load my overarching plan and the one piece I am supposed to do today per my plan and just communicate that accordingly. Also sometimes I am not perfect but I find myself catching silly errors before people notice them but I just don’t tell people I’m done and do it in a safe way like test in staging.
Is it supposed to feel like I’m doing small pieces that add up over time with this practice? I might be wrongfully thinking every day with software I should be treating it like an intense workout instead of a slow jog with sprint bursts when the problem gets hard.
for example there are code changes that can be refactoring but a common use case for refactoring code is finding duplicate code
but that’s inherently easier than performance tuning concurrency or shifting focus in a unfamiliar domain which might take a extra day or two to familiarize yourself with the project.
My behavior would be to set expectations with people around me and give a plan to others so I don’t get overwhelmed thinking I need to work late to deliver on these seemingly harder projects at the same pace I deliver the easier high volume projects.
Is this the behavior you’re expecting of me at mid level?
Im sorry but I’m just feeling icky that sometimes behavior over output also means reaping spoils of doing more with less work even at the execution level
Discussion
(1 comment)- 12 months agoEng @ Taro
Is it supposed to feel like I’m doing small pieces that add up over time with this practice? I might be wrongfully thinking every day with software I should be treating it like an intense workout instead of a slow jog with sprint bursts when the problem gets hard.
You do want to work in a way that's sustainable for the long run. Something like a medium pace where you are still pushing yourself, but you aren't getting stressed out. It's okay to go for the bursts occasionally when there's a tight deadline, but you also want to avoid doing it all of the time, because you'll end up resenting your work, especially when it means sacrificing other things in your life.
My behavior would be to set expectations with people around me and give a plan to others so I don’t get overwhelmed thinking I need to work late to deliver on these seemingly harder projects at the same pace I deliver the easier high volume projects.
There's something called a spike task where the task is figuring out all of the unknowns. This makes a lot of sense when you haven't worked on something before, so you aren't sure about what the full scope is. I agree with you that you should communicate with your team that you're going to be spending x amount of days researching the issue so you can fully understand it and break it down into individual tasks.
Im sorry but I’m just feeling icky that sometimes behavior over output also means reaping spoils of doing more with less work even at the execution level
Another way to frame this is making sure you are striving for "impact" rather than "output". As you become more senior, your coding output will probably slow down because you'll be more responsible for coordinating projects and thinking about the higher level impact of different projects.
