Scheduling for Makers

Here's a great essay by Paul Graham: Maker's Schedule, Manager's Schedule.

One of my favorite parts:

When you're operating on the maker's schedule, meetings are a disaster. A single meeting can blow a whole afternoon, by breaking it into two pieces each too small to do anything hard in. Plus you have to remember to go to the meeting. That's no problem for someone on the manager's schedule. There's always something coming on the next hour; the only question is what. But when someone on the maker's schedule has a meeting, they have to think about it.

For someone on the maker's schedule, having a meeting is like throwing an exception. It doesn't merely cause you to switch from one task to another; it changes the mode in which you work.

This shines a lot of light on some of the most frustrating parts of my previous job as a Business Systems Analyst. I was never happier than when I had a meeting-free day to work on my deliverables and help my developers with theirs. The problem was that I was also expected to attend a lot of planning, project management, and status meetings that shouldn't have been in my job description.

Meetings interrupt creative and analytical processes. They use time that would be more efficiently spent on solving problems. Sometimes they are a necessary evil, but often they are just plain evil.

I wish every manager and every scrum master would read Graham's essay, digest it, and internalize the lessons. It would make a world of difference to the people who work with and for them.

I've Got 99 Problems... and I am the Solution!

Until very recently, I was a business systems analyst (BSA) at a large financial services company. In changing career paths, I have noticed that application developers have to think very differently from BSAs.

Typically, a BSA's role is all about requirements, details, and approvals. Some problem solving is required, but a BSA's problems tend to center around people. In that position, I was always reasonably confident that the answer was out there. I was also pretty good at knowing how to find it.

As a developer, I am finding that sometimes, the answer isn't out there. My job is to create the answer, not document one that already exists. This is simultaneously my favorite and my least favorite part about my new role as a programmer.

Very little frustrates me as much as attempting something that should be simple -- such as getting my code to compile -- and running into wall after wall without any success.

And very little is more exhilarating than finding an elegant solution to a difficult problem.

Despite the occasional moments of wanting to bash my head against the wall, I think I'm going to like this job. It's a fun change to be the one creating answers instead of the one who records them.