IMO, my passion stems from helping others. Romanticizing it, it’s literally part of the first sentence in the Agile Manifesto:
We are uncovering better ways of developing software by doing it and helping others do it.
So with that, my passion is finding ways to help:
-
At university where I’d try to help by forming study groups and going over material or debug sessions for larger projects.
-
At work asking my lead/manager/seniors what pain points they’re facing and trying to figure out a way to fix/own that issue.
-
Spending time to check in with other engineers on my team and asking them how they’re doing.
-
Volunteering as a mentor for various Employee Resource Groups (or whatever your company might call them).
Maybe some of this is mental gymnastics for my brain, but by having more personal time with others it helps me feel like I’m actually driving an impact. Programming is a means to an end for me. The “drive” that stems from wanting to help has been far more powerful than any sort of “puzzle” that is some programming/architecture work.
This could also be my many years as part of the Scouting program and “helping other people at all times” …
IDK if that was what you were wanting to hear, but it might give you a slightly different perspective. Regardless if this was helpful, best of luck.
Edit:
If you really push me to give you a book of sorts …
https://quii.gitbook.io/learn-go-with-tests/
You don’t have to fully drink the Test Driven Development koolaid in your day to day life … but working through this book, it gives you an appreciation for how following good Design Patterns can make testing oh so much easier.
Plus, IMO, good code is easy to test. Easy to test code is less risky. Less risky code helps me not get called a 2am with a prod incident. Getting 8 hours a sleep is something I value very highly.
(Context about me: I’ve only worked at companies with larger engineering department and mainly in a lead engineer role)
It depends on how miscellaneous it is and how long it’s going to take to achieve.
If it’s small enough, a member of the team will just do it, no ticket (or even make a ticket after the fact, if it was a little bigger than ‘small’). Is it potentially uncaptured work, yes. Which is where the emphasis on this is small. Like a update to a dockerfile where we’re incrementing to the next major update for the base image of an application that we don’t touch that often. 99/100 there’s nothing that goes wrong and it’s 5 minutes of effort including the Merge into main.
Which if something goes wrong, we revert, make sure all’s good and then probably make a ticket. Which leads us into …
If it’s not a small task, that’s where my team figures if it has any sort of business impact. If so, we can talk to our product owner on why this task matters and the priority of it. Maybe it melds into an existing epic as a ‘rider’ feature. Which, to your point about:
Perfection, is the enemy of getting things done. However, if the task starts to get large enough then maybe it warrants its own epic. I personally think that any form of “method of getting work done” (i.e. Scrum Agile) should have an exception process for it’s normal ways of handling things. The exceptions are there to be used on occasion, but not abused. Where that line in the sand is … that takes a team with good feedback loops on how we feel about our process (i.e. retros). Then you adjust that line in the sand with the push and pull of work life.
However, I did mention business impact, because my team also keeps a separate ‘log’ of tasks that are tech-debt only. My Leadership and team value taking ~10% of our capacity and put it towards tech debt items each sprint. So that’s usually where we end up putting things where we, engineers, want to get things done without having to wait for prioritization by our product owner whether or not it has that “direct business impact”.
Regardless if this was helpful, best of luck.