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.

The Pragmatic Programmer: Craftsmen and Cathedrals

I'm still only in the preface to Andrew Hunt's and David Thomas's The Pragmatic Programmer, but I can already tell it's going to be a favorite.

Hunt and Thomas have this to say about about the importance of craftsmanship in software development:

Think about the large cathedrals built in Europe during the Middle Ages. Each took thousands of person-years of effort, spread over many decades. Lessons learned were passed down to the next set of builders, who advanced the state of structural engineering with their accomplishments. But the carpenters, stonecutters, carvers, and glass workers were all craftspeople, interpreting the engineering requirements to produce a whole that transcended the purely mechanical side of their construction. It was their belief in their individual contributions that sustained the projects.

We who cut mere stones must always be envisioning cathedrals.

-Quarry Worker's Creed  

 (p. xx of The Pragmatic Programmer, Boston: Addison-Wesley, 2000 )

Good stuff -- makes me want to do more than just sling code that compiles. It's an excellent reminder that there is always room for beauty and elegance, even in the seemingly mundane.

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.

Best MOOC for Beginning Programmers

I took An Introduction to Interactive Programming in Python on Coursera.org this fall, and I was amazed by how well it was designed.

This course provides a nice first look at programming in general, and Python specifically.¹ While it gives many step-by-step instructions to help beginners through the tasks, it also leaves some intentional small gaps for students to fill in on their own.

Overall, the design and content are the best I've seen in a MOOC. Big-time kudos to Scott Rixner and Joe Warren, the masterminds behind this course. (They had help from a couple of other Rice faculty members, as well.)

I was especially impressed with the fully cloud-based Python Integrated Development Environment, CodeSkulptor, which Dr. Rixner designed for the course. This tool allows you to enter and run Python code using nothing more than an Internet connection and a Web browser.

If you want to poke CodeSkulptor around on your own, you can feel free to. You don't have to be enrolled in the class to use it. It also includes a Graphical User Interface module called SimpleGUI, which allows you to code visual elements without too much fuss.

Coursera is a great MOOC platform, and this course really showcases its flexibility and power. I would love to see more offerings like this in the future, as well as some more advanced courses in Python.

You can read Rixner's and Warren's reflections on creating the course here: MOOCs: Lessons from the front lines.

You can also watch them discuss MOOCs with the president of Rice in this video: The professors behind the first massive online open course at Rice University.


¹ If you're a complete novice and you find this course overwhelming, you might try Introduction to Systematic Program Design - Part 1 or Computer Science 101 first. They are both quite good as well, and they provide content tailored for those with little prior exposure to programming.