Tonka Truck

How do you organize miscellaneous tasks when using a task management system such as Jira?

(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:

an epic is supposed to have a well-defined end goal

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.

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.

From the article:

“Where it doesn’t work well is by asking developers to do all of that work without centralized expertise and tooling support.”

IMO, developers should be given enough enough to get themselves in trouble. However there’s a team that owns and enables those processes.

I’ve always thought of it like a team who owns an API. That API team owns the api, but if another team wants to use said API, cool, here’s some documentation for it (env configs, OAuth2.0 onboarding, distrolist, future features, etc.). Maybe, depending on the company, there’s a little more “ceremony” around how much the new team will be using the API just from a load perspective. But overall a team is allowed to digest the API with some guidance.

IMO, this is what should be happening with DevOps/DevSecOps/Operations. They enable the developers to follow some general cookie cutter guidelines with the ability to request adjustments. However, the permutations in what a person can do in operations are so much higher than just a well defined API service.

In my own career, I’ve found that “ace in my back pocket” is being able to handle a lot of my team’s DevOps and general automation of tasks. But when I’ve coached and mentored folks usually there’s a somewhat clear split between the developers who are interested in learning DevOps and those who just want to stay feature-devs.

It’s basically doing step by step print lines for you. If you have easy access to a bash prompt here’s an example (for clarity, the lines leading with $ are what I typed into the shell. The lines without are what is output’d):

$ set -x
$ echo `expr 10 + 20 `
++ expr 10 + 20
+ echo 30
30

$ set +x
$ echo `expr 10 + 20 `
30

You see how the first example broke down what happened bit by bit and the + noted the depth of interpretation for the line? This basically helps debug narly scripts … which if they’re narly enough … just rewrite them in a “proper” language.

What’s that old google adage ( https://google.github.io/styleguide/shellguide.html )

If you are writing a script that is more than 100 lines long, or that uses non-straightforward control flow logic, you should rewrite it in a more structured language now.