Invariant Properties

An artist does not just draw an ear on the first try. He or she will do a study drawing different ears, ears from different angles, etc., until he understands it.

Likewise a software developer should not write new code just once. He or she should play around with it a bit until he truly understands it. Few things are more scary than a magic configuration file that “works” but nobody understands. To me it’s a classic “pay me now or pay me later” situation – it’s better to invest the time to understand it when it’s convenient, not at 3 AM when the production server is down and your boss’s boss is screaming for answers.

Many of us expand these small studies into small projects as a way to self-document what we’ve learned. A small project in a github stash is often a better way to refresh your memory than a large pile of static documentation.

Two things happen over time: the small projects get larger and they get more diverse^*. At some point it’s natural to start asking how they hook up, e.g., you might know how to write a persistence layer, a business layer, and functional tests. How do you wire them to create small functional tests that pull values from the database, perform calculations, and put the results back into the database?

These integrated projects will slowly become more and more complex. At some point it dawns on you that you’re spending more time thinking about what to do than actually doing it. In other words you’re acting as a project manager. A bad project manager, but a project manager.

The answer is to go to the dark side.

Well, at least visit it and bring back souvenirs.

If we’re in an agile shop we already have good idea about what we need to do. It’s easy to get the necessary software – starter licenses for Atlassian products are only $10/year (self-hosted) or $10/month (hosted) (prices subject to change). On the Microsoft side you can get SharePoint for as little as $3/month. For one user’s perspective see http://abovethelaw.com/2014/07/why-sharepoint-is-the-most-underutilized-legal-tool-that-microsoft-has-to-offer/ – it makes upper managements fascination with that product more understandable.

Good tools are important but we still need to know how to use them. This is where study guides for the Project Management Professional (PMP) are useful. We don’t need most of the material but it gives us a good conceptual framework to understand how to manage our own small projects and to be most effective at work.

All of this takes time – in fact it’s why I’ve been light on blogging – but it’s necessary as our projects get more complex. It isn’t fun but it’s a necessary skill that many people will consider more important than mastering a fourth javascript framework.

In my case I have about seven active projects and meta-projects in JIRA. Several side projects, blog ideas, professional development ideas, even tracking the time I’m spending learning Spanish and preparing for a half-marathon this winter. All told I easily have a year’s worth of weekend projects jotted down and it’s a lot easier to prioritize them when a new idea occurs to me. This would have been impossible a few years ago when I just jotted down notes on index cards that lived in a pile on the corner of my desk.

^* I’ll discuss this further later but there’s a tension between being a specialist and being a generalist. Specialists tend to find it easier to land jobs in the short term but if they’re not careful they can hit career death tied to a dying technology. Generalists are more likely to be the unemployed “second choice” but they’re also more likely to have long careers. This may be changing as more companies look for “devops” or “full stack engineers”. Generalists should find it easy to knit different projects together and to see where they have gaps in their knowledge.