That's not how I planned it



Wishful Planning

People say they wish they could plan better but I don't believe them. They wish they had secretaries and administrators who could organize their jobs and lives.

Some people invest in apps to help them figure out where their time is going. They point their phones trying to capture an image of time as she sprints and ducks down the alley way. See this blurry picture, that's time disappearing on me again.

In software design and in hardware engineering, where we typically have educated and smart people, I'm often shocked at the reasons for resistance to planning. It's so emotional.

Loading a Sprint Plan

When loading a sprint plan, people are afraid of appearing lazy. They grab the biggest shovel and start heaving in the tasks. Then there are the ones who fear disappointing others. They load a sprint like a novice backpacker, stuffing extra gear into pockets and pouches until they can't hike without toppling over from the excess weight. Fear is a front runner also when they omit a list of assumptions. Everything will be perfect. Don't be so negative.

Here comes fear's cousin, hubris. You might recognize hubris as the lone tech cowboy whipping the project into shape by the seat of his cargo pants. The film industry has this type, a director who storms in and tosses everyone into a frenzy. It's a way of generating his creative energy. Who cares about you, the little person who has to figure out the code and make the product actually work within some nebulous timeline.

But after fear and hubris, doggedness lifts its leg and pees on the plan. Doggedness, normally something we want to help us stick to a plan, growls at the idea of breaking down tasks. You're asking the impossible. Some things can't be broken down into 4 to 8 hour tasks.

I've struggled with that. My task is like an egg, complete. If you ask me to break it into parts, I'll just get yolk and egg white over everything. I see many tasks as eggs. 1 day tasks or 1 week tasks. And these awful things still happen when people are supposedly loaded at 80% capacity (taking into account administration, corporate life, etc.)

But why do you need to plan?


Because someone is paying you to do a job and that person needs to talk to a customer who is handing over money to the company. Someone has to explain when the product will be ready or why it will be late, and how far along the company is in meeting its commitment. (Ask Bombardier about their trains.) You don't get to be Peter or Petra Pan. Planning is for grown-ups.

Breaking Down the Work

I don't believe in reinventing the wheel so I search for planning advice.  https://blog.amazingmarvin.com/break-large-projects-tasks-bite-sized-tasks/

How do I define things?

  • Task - What does that mean to me? Is it something I can complete in a day, in a few hours?
  • Project - What does that mean to me? Does it span over two weeks? Then it's not a task. Maybe it's a milestone and I need to tell my manager that.

What are ways of dividing things?

  • Phases - For example, planning, coding, testing phases.
  • Parts - For example, thermistor, driver, inverter .
  • Categories -  Good old Aristotle always showing up with his categories.

How should I write about doing these things?

Just like on your resume, use action to describe what you've done or need to do. For example:
  • Search repository for...
  • Interview subject matter expert regarding legacy code
  • Set up test equipment

What if I can't fit my work into a phase, part, or category?

It's OK to repeat things especially if you want to go home at a reasonable hour.
Part of your day (and plan) might look like this:
  • Write code for the installer 3 hours
  • Write code for the installer 2 hours
  • Write code for the installer 2.5 hours
(I say, if you need to distinguish between these repeated tasks, append with A,B,C... You may not even work in the suggested sequence of the alphabet. It's just to differentiate them slightly.)

My paraphrasing and choice of examples, but original suggestions for breaking down the work is by .





Developer Echolocation


In addition to psychic debugging, we have developer echolocation.  
When developers emit calls out into the environment (phone system for standup meetings) and listen to the echoes of those calls that return from various objects near them (other developers quoting JIRA issues).

Reaction to anything


My colleague: What is the customary waiting period with this type of thing before turning it into a lifelong feud?

Me: Two weeks is good.





Translation Management

When my colleague tells me how it really is:

"Can you image how difficult it would be to translate our manuals if the translators were NOT free to come up with whatever UI strings they liked? People who speak these silly languages probably prefer it. I think most of those weird words mean the same thing anyway."



Email to my colleague:

Me: I still have the flu.

Colleague: When administration stopped sending status updates on your illness, I assumed you were dead. I was getting ready to put your job posting up.

Me: I almost died.

Colleague: I would prefer it if you didn’t die although I would very much like to write a combined obituary/job posting. So my feelings are very complex.

Me: My feelings are complex on this too.

On today's agenda:
Today we're making Matisse cut-outs as an adjunct to our technical documentation suite​. I need scissors and construction paper.


And heard about town:
Person in coffee shop: "I know several people at Google."
Me: "I know people who started there years ago. Years. A-go."






Overheard in the ether regarding UI design.

"I'm not asking for yesterday, but could you at least be 10 years ago."