Think You’re Good At Multitasking?

I keep hearing messages about how multitasking is inefficient, and how it harms our ability to produce.  And, like so many other people, I said to myself, “Yes, but I’m clearly the exception: multitasking works for me.”  Then I found this quiz.

This isn’t new: the New York Times posted it three years ago.  When I stumbled on it, the results surprised me.

Do you consider yourself good at multitasking?  How well do you focus and shift contexts?  Are your results what you thought they’d be?


Preparing for Dry Spells

When I started this blog, I had a plan. I was going to plan to post three times a week.  I would start by building up a backlog of posts, and schedule them to post Monday, Wednesday, and Friday, and once I was two or three weeks ahead, I would slow down, and work to keep my backlog full of new posts.  This would give me a buffer, so that when I inevitably got too busy at work to write, or got sick, or went on vacation, I would only eat into my buffer instead of having dead air time.

Of course, if you look at my post history, it’s pretty clear that my plan fell apart almost instantly.  I posted twice on June 4th, and then June 6, 7, 8, and 10.  And then radio silence.  What happened?  Well, I hit a busy spell at work.  And then I got sick.  But the real breakdown wasn’t the radio silence.  The real breakdown was the second post on June 4.

All through my career, I’ve heard a piece of advice: never work at flat-out speed.  Don’t report work as finished until a while after you’ve completed it.  Keep a buffer of progress you can turn in to management when you inevitably hit a lull.  And, just like with my blogging, I have never been able to follow this advice.  Here I am, with a document written, or a tricky piece of code cleanly executed, or a piece of functionality I can pass on to QA for testing.  The idea of gamesmanship at that point, of hiding the real nature of my achievement in order to bank it against some future stretch of inability or incompetence, seems utterly foreign to me.

Part of this is that I, at my core, yearn for recognition.  Maybe it’s the Millenial in me: I like the validation of knowing I am someone who can deliver.  I like the thank you for a job well and quickly executed.  That definitely plays a part in my desire to turn my work over right away.

But I think there is something deeper at work here.  By holding back some of my work, I am saying, “The speed and quality with which I executed this is a fluke.  I am not really this good.”  I’m setting a lower standard of excellence for myself, and I am assuming I am going to decline.  I don’t want to make that assumption.  I want to say, “I did a good job on this, and I am going to do a better job on the next task.”  If the reward for a job well done is a bigger job, then bring it on.  I want the bigger job.  I want the harder job.  I want the challenge of working on tight deadlines, and I want to keep setting the bar for my own accomplishments higher and higher.

I like to believe that by doing this, I’m banking something more than work I am holding in reserve.  I like to believe I’m banking trust, and value, and goodwill.  And I think that will carry me through more difficult times than a few pieces of code I’m withholding.

(As for the blog, I’m going to keep trying.  The queue starts growing today.)

“At the end of the day, I’m being paid to write code.”

“At the end of the day, I’m being paid to write code.”

I have heard that hundreds of times in my career, from people of all ages, genders, and nationalities.  It comes up when there’s a meeting that no one wants to attend.  “I don’t have time to waste on this; I’m being paid to write code.”  It comes up when there’s mandatory training for client audit purposes.  “They can’t expect me to find time for this; I’m being paid to write code.”  It happens when it’s time to write goals for the next fiscal year. “Goal: write more code.  Find way to avoid stupid goal-setting exercises.”  It happens when people are asked to do  routine paperwork, like timesheets, expense reports, or task board updates.

“At the end of the day, I’m being paid to write code.”  Everything else is useless garbage being imposed on you.  The code is the core of your purpose.

Have you ever said this?  If so, you’re wrong.

No matter what you may think you are being paid for, you are really being paid to support business operations in your area of specialization.

If your assignment is to develop an application, and you find one on the market that would meet all of your needs, and would cost less to buy and support than it would take to build and support it internally, you’re doing your job by bringing it to your boss’s attention, even if it means you don’t need to write any code.

When timesheets and expense reports don’t get filed on time, cost forecasting is happening off of flawed information.  Not only does it make extra work for people who need to remind their employees to file routine paperwork, but business decisions way over your head are being made based on bad data.  This happens when software engineers don’t do their job.

When task boards aren’t updated and daily records of work aren’t maintained, it takes more time and energy for everyone on the team to figure out what is going on.  Reports made to upper management take trickier calculations.  Calculations that should be simple and pulled straight from the task board are now fuzzier and harder to compute.

When training isn’t done, companies fail audits.  Sales people and CEOs have to scramble to hold onto customers.  Sometimes, revenue takes a hit.  Other times, relationships are left strained.  Other people have to cover for the people who didn’t do their training.

When people don’t attend meetings, or attend meetings and write code on their laptops, communication breaks down.  Messages have to be repeated over and over again.  People give up their chance to have input, and then don’t like the decisions that were made.  This leads to more work for management, more stress for your coworkers, and a worse working environment for you.

At the end of the day, a software engineer is being paid to do her entire job, not just the part of the job that she considers most intellectually challenging.

What’s your job?

Before You Go Agile

Agile is one of the hottest ideas in software development today, and it actually has nothing to do with software per se.  Agile is a project lifecycle methodology based on constant re-evaluation of your project and an iterative approach, where requirements, code, and testing are all being done constantly in small pieces.

Everybody wants to be agile today.  But what will it mean for you?  Here are some things to keep in mind if you want to go agile.

1. You can plan releases for dates or for functionality.  You cannot plan for both.
Agile requirements are deliberately fluid.  If you decide you are going to do A, B, C, and D for your July release, you don’t leave room to add X, Y, and Z if they’re more important.  If you want to maintain a consistent release schedule, you have to be willing to let things remain undone for now.  You’ll get to them in the next release (unless a more important M, N, and O come along…)

2. You will throw away work.
After you have designed, built, and tested a piece, a requirement may come in which requires you to rip out that piece and throw it away.  In fact, if you never throw away any code, you are probably doing agile wrong.  Get used to the idea now.

3. You need to embrace the idea of good enough.
You are not aiming for perfection on every iteration of an agile project.  If it will meet the needs of the customer, it’s good enough for a first pass.  Don’t do more than is necessary to meet the basic requirement.  If more is needed, it can be added as a new requirement with its own priority.

4. Modularity is your best friend.
If you are on a long-term enterprise-level project, I will pretty much guarantee that at some point, a new requirement will come in, and you will realize you need to change some major underlying part of your code to fix it, with implications that ripple through every line of code you’ve written.  To defend against this as much as possible, code to interfaces and keep your code as modular and pluggable as possible.

5. You must schedule work based on priority, not function.
If you have 6 major functional areas you are planning to address in a given release, it can be too easy to say, “We have three sprints, so we will focus on two areas per sprint.”  If you do this, chances are good you will completely miss one (or more) functions entirely.  Instead, do the highest-priority piece of each area first.  If you want to be able to view, edit, and print six different tables, start with building all six tables.  Then add the edit functionality to all six tables.  That way, if you run out of time, you’ll only be missing the least important functions from all tables, instead of missing some tables entirely in a way that might prevent a release from being usable at all.