Today marks day one of my return to the land of flexible employment. That's right: as of today, I don't have a full-time job. 😬
For now, I plan to do some contract work, likely part-time, while I figure out how to fund the basic computing research work I'm looking for. This transition has little do with my employer, and far more to do with my career goals: in fact, one my first contract gig will be working with Lambda School to explore an educational program in the blockchain space.
As I've been planning this transition out of my full-time role, one of the things I've had to mourn is the loss of working with a team. When I wrote down my work values over a decade ago, I focused a section on teamwork:
Working with a team...
small and focused - No more than 10 people, focused on maintaining internal unity. The team succeeds as a group rather than as individuals.
that works closely together - Talking every day, pairing where it makes sense, and in constant communication.
respecting, encouraging, and challenging one another - Speaking the truth lovingly, reflecting constructively in order to improve, and challenging patterns that threaten the success of the project.
I've been asking myself "how can I create a team environment while working as an independent contractor?"
I'm trying a few experiments:
One experiment is a weekly update. Every Monday for the next 8 weeks, with the possible exception of holidays, I'm going to write a short update to you, dear proxy teammate. I'll talk about what I'm working on, what I'm reading and thinking about, and link to stuff I've made over the past week. Think of this like an asynchronous Monday morning standup. With that in mind, I'd love to hear from you as well! Feel free to reply to this email and share what you're up to, what you're thinking about, or anything, really.
Another experiment I'm going to try is more livestreaming. I've really enjoyed putting on my Coding With Jess livestreaming series over the past few years, but I've fallen out of the habit. I plan to get back to it, and "work with the garage door up" by letting you look over my shoulder at what I'm working on. If you'd like to be notified of my livestreams, subscribe to my channel on YouTube.
A final experiment is a private Discord server to chat about the future of computing. I started "New Pioneers of Computing" a few months ago, and I've really enjoyed the dialogue and engagement from a small group of folks who are thinking about the future of computing. I'll likely do more frequent livestreams through Discord, where the bar is lower than streaming on YouTube. If you'd like an invite, just ask. We'd be happy to have you!
I'm curious to see how these experiments work at creating a community in which work can be done apart from the structures of a traditional job.
How much of your time is spent "getting into position to do the work"? Probably more than you think.
I was intrigued by a section in Licklider's Man-Computer Symbiosis:
About 85 per cent of my "thinking" time was spent getting into a position to think, to make a decision, to learn something I needed to know. Much more time went into finding or obtaining information than into digesting it. Hours went into the plotting of graphs, and other hours into instructing an assistant how to plot. When the graphs were finished, the relations were obvious at once, but the plotting had to be done in order to make them so.
It seems that time spent "getting into position" dominates other work as well. Keep in mind this paper is from 1960. Have things changed? I doubt it.
I was reading an analysis of the construction process and came across the fascinating but simple definition of "setups":
Setups are the time it takes to set-up at the beginning of a production process.
The author goes on to describe the many setups that litter the construction industry:
Construction has an enormous number of setups. Every time a worker puts down a hammer and picks up a saw, every time a crew moves to a different part of the building, there’s a setup. Every time the superintendent has to look at a set of plans, every time the crane unhooks from one piece and hooks on to another, there’s a setup. The months architects and engineers spend producing the drawings for the building is one long setup for the actual construction process.
He summarizes with this arresting conclusion:
Setup time can dramatically exceed the actual process time.
Pay attention to your work today. How much time did you spend solving problems, actually thinking, compared to getting into position to work. Look for ways that you can reduce setup time by investing a little time up front.
Some of the best developers I know regularly invest time into improving their computing environment. They refer to it as "sharpening their tools" or "tending the garden." Currently, my process is sporadic and unfocused. I'm pondering what the ideal cadence and process would be to integrate the practice into my workflow.
If you have thoughts on this, please reply to my tweet here and share! I'm curious to hear about your process.