Has Jetbrains tried to buy your Twitter handle from you?
No, but I receive a handful of messages per year from people assuming that I’m associated with Jetbrains. I was
jbrains long before Jetbrains began operating.
What would you recommend as an approach to find our own bottlenecks?
You can make some good guesses about where your bottlenecks lie even before you learn the general technique called value-stream mapping.
I recommend looking for two things: waiting time and rework loops. Imagine yourself as the work, sitting in someone’s email inbox, as a sticky note on some team’s Kanban board, or as an item on the agenda of a meeting scheduled for next Thursday. When work waits for someone to make progress on it, it becomes a potential bottleneck. A rework loop occurs when we do something, then evaluate how well we did it in order to decide how much of that work to do again (_rework_). The risk in this loop lies in being unbounded (we can’t forecast how much rework we will need to do), having an uncertain number of iterations (we can’t forecast how many times we’ll need to iterate through the loop), or slow (it takes a long time to get feedback from evaluating our work). All these risk turning the rework loop into a potential bottleneck. While you’re reading about value-stream mapping, you can take the shortcut of paying attention to waiting time and rework loops.
I wrote extensively about dealing with rework loops in “How Test-Driven Development Works (and More!)”, in which I transform the single-pass Waterfall model into a Lighweight approach the combines XP practices with Lean Startup and even Beyond Budgeting.
Whatever you do, please remember the following very important points:
- Every system lives inside a larger system, which means that bottlenecks in a larger system might lie entirely outside of “your part” (the smaller system).
- Optimizing “your part” of the larger system might cause problems in a larger system. Try, anyway, but make yourself aware of the risk.
- In spite of these points, for most organizations, most of the time, focusing on the local bottlenecks leads to useful improvements.
How do you address estimating your work if you delay planning?
I only estimate the cost of tasks if I’ve done them many times before and I feel quite certain that I won’t encounter significant unknown delays. This very rarely happens. Most of the valuable work that I do is quite uncertain, so I don’t try to forecast the cost of those tasks; instead I focus on delivering more value sooner.
I manage costs using budgets instead of trying to guess accurately about the cost of a task. It takes more energy to argue about the accuracy of the forecast than it does to slice the task to find the most-valuable parts, which I’d try to deliver first. If someone wants estimates, then I routinely treat them like budgets, which leads to more-constructive discussions when things go wrong.
I found it much harder to follow Inbox Technique [from Getting Things Done] as soon as I moved from development-only to leadership and people management. Any advice on how to adjust mindset?
One of the primary reasons to use Inbox Technique involves managing open loops: projects that you can’t finish yet because you need to wait for other people or other things to happen. Leadership and people management work seems to involve maintaining relationships over completing tasks, so that tends towards more open loops, not fewer. This should make Inbox Technique more important and more helpful, not less!
Perhaps you feel uncomfortable writing things down while other people are watching. I understand how you feel. Here, I encourage you to act selfishly: if you write things down, then you will more-easily and more-effectively focus on the people and work around you. I found good results by simply telling people what I was doing: “Give me a moment. I just need to write this down, otherwise I’ll be trying to remember it instead of listening to you.” Most people react positively to this, since they recognize that I’m doing it for them as much as for myself.
Which question would you like to answer?
I’m not sure. I like to help people will very personal issues, so perhaps I’d like to answer a question like that. Please send such a question to me by visiting https://ask.jbrains.ca.
Isn’t TDD in conflict with evolutionary design? TDD plus Evolutionary Design sounds like maximizing the YAGNI problem.
This question surprises me and I don’t understand it. How could TDD conflict with Evolutionary Design? I would need to know more from the person who asked this question.
I see TDD as an implementation of Evolutionary Design: it is one technique that helps me safely guide the evolution of the design of a system, because the tests help me feel comfortable refactoring (reorganizing the code) over time. Without tests, I risk feeling resistance to refactor those parts of the design that need it most.
Regarding TDD and YAGNI, I can guess what the questioner means: if I could confidently refactor code without writing tests, then I would do it. I’m experimenting with this now. After two decades of practising TDD and trying to rescue legacy code, I feel comfortable refactoring without tests in many situations. I know that if I reach a situation where I don’t know how to change the code safely, I can add tests only in that area of the code and only long enough to refactor it. I feel comfortable working this way because:
- I have practised writing tests for a long time, so I know how to write useful and effective tests.
- I have practised TDD for a long time, so I know how to use tests to help me see specifically where the design needs improvement.
- I have practised writing tests for a long time, so I find them valuable, which means that I will write them when I need them, even if I don’t write them all the time.
- I have practised TDD for a long time, so I have built the habit of writing tests, which means that when I believe that I want to write tests, I feel very little resistance to writing them.
Ironically, having practised TDD for a long time makes me more comfortable not writing tests, because I’ll choose to write tests when they become especially useful.
Have you seen The Mentalist TV series?
I have. I enjoyed it. I liked it when Simon Baker’s Australian accent occasionally broke through when he tried to pronounce words that end in “r”.
What to do if you don’t have a manager that “controls” how you are slacking?
I don’t quite understand the question. Please visit https://ask.jbrains.ca to tell me more about what the situation that you have in mind. In the meantime, let me guess at what the questioner means.
I have a lot of freedom to choose what I do. I don’t have complete freedom, because I still need to earn some money to support my lifestyle, but I have significant freedom. I sometimes feel stress from this freedom, because the responsibility to decide how to “use my time and energy well” falls to me. I spent several years panicking because I didn’t feel a sense of purpose, which meant that I was probably “wasting” my slack time and energy. It took me a long time (and many conversations) to understand that I was putting that pressure on myself: I was assuming that I had a duty to “be productive”, even though I couldn’t say to whom I had this duty! After a few years I started to accept that I have no moral obligation to anyone to “use my time and energy well”. Instead of feeling guilty for not maximizing by contribution to the world, I began to focus on feeling good about the contributions I make. I began to read about Nonviolent Communication in part because I was attracted to the idea of “giving freely to others” and how good that makes me feel. When I give freely to others, I feel good, so I act selfishly in a way that helps others. Everyone wins.
I could certainly do more, but if I focused on the negative emotions associated with not doing enough, then I would miss the positive emotions associated with doing anything. That would seem to reduce my capacity to give to others and everyone would lose.
What tools do you recommend for GTD?
I currently use Todoist. It works well. I don’t know whether there exists something that works significantly better. I loved Hiveminder because it had an IMAP email interface, which meant that it worked with a very stable user interface (most email clients). I have friends who like Things and Omnifocus.
I strongly recommend Followupthen for both time-based reminders by email (and even SMS, if you pay them, and you probably should pay them) and to manage open loops in email conversations.
I consider it critical to have one key feature: minimizing friction to getting things out of my head. Whichever tool helps me do that usually gets my attention.
What would be a great place to start with TFP, TDD and/or Evolutionary Design?
I would recommend my own online training at https://tdd.training, if you want something more than “here are the rules of TDD”. Buying training is just fast-forwarding your learning. There exist good options out there that cost nothing to start.
Try visiting https://groups.io/g/testdrivendevelopment to ask questions about how to practise TFP and TDD effectively. You can trust most of the people there to provide helpful answers, but you can’t control how quickly they answer.
Most importantly, just start. Pick a small project or exercise and write the code test-first. You only need to follow one rule: no production code without a failing test. This suffices to start. You can search the web for “code katas” or visit a site like https://codewars.com to help you find simple exercises to work on. When you have questions, ask them! With that, you can easily get started.
Focus your energy on test-driving code that runs entirely in memory. Once this becomes boring, then you can comfortably move on to more-complicated situations, where doing things in a straightforward way seems too expensive to be worth the effort.
You mentioned to use Inbox method [and Monotasking or the Pomodoro Technique] to get more concentrated to work. How does it work when a co-worker comes in and needs help: should I send them away?
Sometimes, yes. You probably need to practise focusing now, so that later you will find it easier to recover from interruptions. If you recover more quickly from interruptions, then you will find it easier to help your co-workers more often while being able to perform better on your own tasks.
When I worked at IBM, I was a “lead programmer”, which meant that co-workers routinely asked me for help. I spent about 4 months practising Pomodoro Technique very diligently, which included putting a note on my door that read “I’ll be available to answer questions at 14:30”. Yes, I changed the note every time I started a working episode of 25 minutes. Gradually, my co-workers learned when they could safely ask me for help. It didn’t work perfectly, but I had enough opportunity to practise focus. Eventually, I reached the point where I could become deeply focused quite quickly, so that if I was interrupted, I could return to my state of deep focus within a few minutes, instead of needing an hour to “get into flow”.
One year after I started practising, I noticed two important things:
- When a co-worker needed help, but not urgently, they sent me email more often and they could wait more patiently for an answer.
- When a co-worker came to my office for help, it was very often something that genuinely required urgent attention.
We had some conflicts while I was building my habits, but never any serious fights. My co-workers generally understood that I was trying to do this for them as well as for myself.