I'm wondering how many times I finish a thought with a conclusion and when it's just simple whining about problems. It's never a good behavior to tell problems without pointing out the lesson or attempting to help on it. Or maybe it's like with wishes, you need to whine a lot and it will go away.
I think I'm good at productivity. I'm a huge fan of tricks and life-hacks and it's easy to adopt many into my lifestyle. The most important thing at productivity is time. You want to live a full life, having as much content as possible in it. And that's a nice goal. I'm happy to sacrifice in order to win.
I wash the dishes 1, maximum 2 times a month. Getting involved in the washing process is a long time. And you get depressed, sad by doing that awful thing. Shifting mentally between coding and dishwashing takes some time. It's exactly the mass-production problem. Small amount of production has simply higher cost per item.
And surprisingly I have the same efficiency problem with tickets. I've heard once that chaos is fine for many guys because that's exactly how they can find their way in the mental / physical world. I don't like chaos neither in life nor in code - but I like the chaotic ticket-picking way of working.
When I have some free time and feel confident that nobody else will interfere with my work I just pick up random tickets from the issue queue and solve them all together. You see which one relates to each other, which one is on the same page, which on is exported in the same feature. See what I mean? Grouping is easy - easy and effective. Think about the costs of a task. Simple things like opening your terminal or IDE. Or getting a certain structure into your head, thinking though a process. Creating fields, exporting them, creating rules, coding - many things.
Most of these costs are increasing on a logarithmic scale. Soon they reach a level where it doesn't really add much when including a new - similar item. But usually that's not how development - or even agile works. You need to start, prepare, estimate, setup, research, proceed, test, review ... just too many things.
Personally I like to solve things in a different way. In practical life when you fix or write code you inevitably spot something in the middle and want to fix it. That's also something similar - many says git commits should contain small and single purpose changes. But again it just increases time.
Or when you exporting feature you just want to add quickly couple of extra fields. Or write some tests.
Well, I think it's still subtle compare to time management. Recording time and report minutes is a real time waster. Not to talk about meetings. I mean don't get me wrong. I fully understand of the purpose of a meeting. It never works without communication and reports. I just would be happy if clients could read git log instead of Redmine/Jira reports. Or they would accept a developer working an many things at the same time.
I feel mental preparation is not respected as much as it should be. My brain is even worse. If I have to answer an email just because it's urgent it kills everything I kept in my mind and goes back and hunt down all the other thoughts I had.
So the lesson of the lesson-less thoughts: I wish issues could be merged by category or type. I wish there would be a standard email-answering hour each day (instead of the whole day). I wish devs could work freely.
---
Peter
Affirmative: I feel exactly the same way.
ReplyDeletePlus, I emphasize how separate tickets can trick you away from solving a problem effectively.
When a number of issues relate and come from a common misdesigned/faulty fundament, the best way to solve it would be to boldly rethink that whole fundament, refactor it, replug the subsystems into it, and have all those issues go away at once.
But overviewing the tickets looking for such connections takes a conscious decision, sometimes experience. Issues broken down into fixing mere sub-symptoms can trick you away from finding the effective (and I think, in the long run, the economic) above solution. (Of course, solving the second, third related issue opens your eye up, but by then a good deal of work might been put into suboptimal symptomatic treatments...)
I believe, when a project turns out good, it's only possible if someone had it all in the head, knowing, planning and following all the contexts, and building solutions, subsystems for the big picture.
Scattered issues only make this harder, much harder.
Let me include the answer I found:
Deletehttps://twitter.com/eager_hun/status/317023761138343936
Hi Levente, thanks for your words. Yeah, you're right. What I was experimenting sometimes is not looking at the issue queue at all. Your mind is not too complex when it's about chores. Whatever is closest or can be targeted with the same tool it's good to go. It's like the greedy algorithm ( http://en.wikipedia.org/wiki/Greedy_algorithm ) - and it works usually unless management wants to hunt you down :)
ReplyDeleteWow, this greedy algorythm is quite a high-profile mathematic concept... from the domain of theory (still might be useful).
DeleteWhat currently occupies my mind, however, is a system where you tag the individual tickets with tags like #Panels or #JS or #Messaging_system:
#Panels, because once you open the Panels UI (and about to recreate features), why not sort out more similar tasks at once.
#JS, because - at least for me - it means a special mindset, I sort of need to load the "JS module" in my head. So once it's loaded... you see where I am going.
#Messaging_system, because it is a complex set of highly coupled business logic, which integrates into a single competence of the website. So, when planning fixes, any related issues might be useful being observed in parallel.
(At this moment, I might should add: IMHO) :)
It's really great idea actually!
Delete