6 ms·
This sounds a lot like me. I do get a TON done, am always working hard, but I can’t single thread to save my soul. I have a tendency to work on 6+ tickets at t
by donatj 4y ago
This sounds a lot like me. I do get a TON done, am always working hard, but I can’t single thread to save my soul.
I have a tendency to work on 6+ tickets at the same time which has in the past clashed with what management has wanted - clean single threaded work that looks nice on a kanban board. For instance I have a project right now that in linear time has taken about a week but has taken well over a month in actuality because I am constantly jumping around.
I literally don’t even mean to, I try to stay on task but will get an idea for a difference project and switch branches without even thinking about it.
I don’t know that I would want to medicate it, I don’t have a problem with it and my net output is very good even if individual tasks take longer than “they should”. I see it as just an alternate way of thinking/working.
I just wish we’d stop trying to jam people into workflows. You’re missing out on potential.
- darkerside 4y agoThe danger is that multitasking like that can make you FEEL like you're getting a ton of things done while you're really just spinning wheels in place. I'm not saying that's what is happening to you. You may have data to back up what you're saying. But there could be a parallel in some cases to moneyball, which exposed how intuition and bias had led to suboptimal decisions through false perceptions.
- flappyeagle 4y agoThe problem with a lot of stuff in flight and nothing shipped is it’s extremely expensive. You’re basically holding onto inventory that isn’t able to be sold. It isn’t people jamming workflows, it’s economics.
- dpkirchner 4y agoAgreed. Sometimes I have multiple outstanding pull requests against the same code for features different enough to be different tasks. It rarely works out well but for whatever reason I don't notice it happening until the end. Alternatives are: overloading pull requests with multiple distinct tasks (bad), sitting on my hands (bad), updating the code for each PR as others are merged (bad, error prone), or creating pull requests that merge into other branches pending review (less bad but annoying to maintain). I tend to do the latter.
- tbrake 4y agoIf you're a small enough team, this doesn't matter. But if someone else - whether a single dev or another team - depends on your work then you run the real risk of being a bottleneck to other people and the business. At that point all the "potential" in the world means jack if we wanted to ship in June but pushed back to August.
- scruple 4y agoI often have multiple tickets in-flight but it's because some pieces are blocked and/or I'm waiting on a gate to open or I have some scheduling situation I'm dealing with. Today and tomorrow I'm working on a long running (started 2 weeks ago, will run for the coming months if not the remainder of this year) legacy system modernization project. On Monday, I have maintenance work I'm scheduling that is either going to take an hour or 2 days and I won't know til I press the proverbial button. These two are on top of all of the unplanned work that comes up, some of which I'm seeing this morning before I technically start work. For the unplanned work, I'll have to double back and make tickets to capture what was done at the end of the day, but right now that looks like 3 separate pieces of work today. So, I think its safe to say that I'll be grappling with 4 tickets today, with a fifth in the back of my mind, and making sure the product team is on top of communication around the internal outage the team will have on Monday. I also have to get my kids to daycare/preschool, get myself to physical therapy, and then pick the kids up. I feel like I probably do have undiagnosed ADHD but maybe I'm always so busy moving from task to task that it doesn't have a lot of opportunity to allow, for want of a better word, procrastination to really set in?
- gavinmckenzie 4y agoA need to multi-task is 100% ADHD. Our (inattentive) ADHD brains are like a car engine that will stall if it's allowed to idle, and so we have to keep the revs up in order for it to keep running. For us inattentive ADHD people, the meds have the effect of raising our engine's idle speed so we don't have to keep our foot on the pedal through multi-tasking just to stay engaged. It's easy to rationalize this behaviour, and it can feel amazing when you're on top of everything, but it can take a toll and end up in burn-out or disaster when all those (to mix metaphors) plates you've kept spinning eventually fall.
- alfor 4y agoI like this explanation. Lot’s of multitasking, over consumptions of information and procrastination on my side. With med it’s like I am more calm and energized at the same time. Made me see how most people see the world for the first time.
- zamnos 4y agoMissed Potential is the name of the band featuring everyone with ADHD who was called "smart but unmotivated" by their teachers, never got tested, and never derived the benefits of treatment. You're free to do whatever you want, but if someone in a wheelchair refused a simple surgery that would fix their problem, and said that people trying to help them walk were "jamming them into workflows", you'd really think that maybe the person in the wheelchair should get looked at.
- prometheus76 4y agoAs someone who was diagnosed in my 30s, used medication for about eight years, then got off of it for about three years, I'm going to offer another viewpoint. I am grateful for the clarity I got with the meds, but something always felt off and I definitely talked too much. I finally decided to get back off meds, and my anxiety really subsided. By that time, I had built a pretty effective external structure of calendar, reminders, etc. to handle the ADHD aspects of my brain, but without the anxiety to also deal with (which ramped up my ADHD exponentially), the ADHD is totally manageable and I don't feel so out of sorts and, for lack of a better term, "domesticated" into being what corporate America thinks they want. I get along just fine, and I attribute a lot of that to finding a job I enjoy and having a boss who is patient with my unpredictable, but important contributions.
- zamnos 4y agoAnxiety is really the crux of it. My psych prescribing anti-anxiety meds was life changing!
- zamnos 4y agoIf you've been on medication, and know the effects of it on you well, and you're able to put systems in place to overcome the shortcomings this legally recognized disability has afflicted you with (as well as the blessings), then absolutely be off medication as you please. Tis your life to live! But for those that haven't been on medication for extended periods, or even just tried medication at all, for whatever reason, be it fear pushed by anti-medication zealots, or an inability to access it; for those that are tired of their life failing for reasons that everybody else seems to just be able to do, medication is, sometimes literally, a lifesaver.
- skeeter2020 4y ago>> clean single threaded work that looks nice on a kanban board It's pretty unfair to characterize the demand as a desire to look nice, when in your next sentence you admit that a week task has taken you more than a month. I don't give a shit about the kanban board but I do care about work in progress. There's no value until you finish, and I mean done-done. What you consider multi-threading is micro time slicing, with significant context switching costs. The funny thing is you probably consider your approach agile, while me, an old fart in management, see a giant pile of have half-finished widgets collecting dust. Until you adopt my old-fashioned approach of single threaded work you'll never be successful with the newer approaches of continual delivery, and constant, small-scale, non-scary releases.
- LawTalkingGuy 4y ago> when in your next sentence you admit that a week task has taken you more than a month The word 'admit' suggests you had to drag it out of him, that he's hiding slow progress behind a smoke screen of busy work like opening many tickets. That month-long background task wouldn't have had any work done otherwise so it's unfair to call it delayed. > Until you adopt my old-fashioned approach of single threaded work That's the problem with people who think they're technical managing the actual workers, they always end up micromanaging and slicing things into shapes that don't fit. The world isn't single threaded and changes usually aren't entirely unrelated. You should change your management style to simply specifying the business goals you want and asking for as many to be completed as possible. Let your team do what works best. > The funny thing is you probably consider your approach agile No, because all those labels just encourage people to pick a style and do that thing regardless of circumstances. In a real project I've got to coordinate everything with someone. I can't push code without a review, I can't code to a team's API without sending them the spec for review, etc. During these times I could facebook like some others do, but instead I "multi-task" by doing other work. Also, it's not very obvious from simple metrics like number of lines of code committed which work is hard and which is simple fluff which can be fixed without a distraction. A change to a logger might percolate through every method call and appear big and complex despite having been made in seconds by the IDE. If I was implementing a new feature I'd probably want to update the logging style first rather than coding to the old standard, so I'd make the big change (probably covered by another ticket) because I'm already in there and have to test that stuff anyways. > There's no value until you finish, and I mean done-done. As I said, there are a lot of down periods in that process. It feels like you think you know some deep secret ("only delivered features count!") that you think you can't get people to acknowledge. This is actually like day-one stuff in engineering school, that you need to measure benefit of your work in delivered advantages so done isn't done until it's in use. But there's a lot of other stuff as well, such as not delivering something until it's safe to use even if it works in test scenarios. You should have a discussion with your team about your idea and brainstorm where it fits into a full product development cycle and what has to be considered. I imagine you will find they don't discount it, but they have a wider view of the process than your business focused one, and that they have to balance all of this while also managing your perceptions.