A Framework for Becoming a Better Software Engineer

Learning feels best when there’s a sense of cohesion about it. It feels good to refine a theory or build toward something clearly envisioned. It doesn’t feel good to advance in one area, only to discover that you’ve slipped in another.

In an effort to systematize my deep work sessions, I’ve started zeroing in on some organizing concepts to get a balanced sense of progression. These are the basic ingredients for planning my deep work sessions:

  1. Rotating skill domains for identifying a strength to cultivate.
  2. Work cycles for structuring deep work sessions.
  3. Weekly calendaring for determining when I’m going to pursue skill-building.

Skill Domains

There are four kinds of skills I need to exercise routinely to maintain balance in my know-how. These are:

  1. development skills
  2. problem solving skills
  3. surveying skills

Development skills involve writing different kinds of applications (how do I write a DBMS? an OS? a web server?). This about writing apps that don’t exist. Reading and doing “code as I code” exercises are activities you’ll use in preparation for writing apps that don’t exist. Execution is about choosing a problem, owning it, and writing your own code to solve it. No copy-paste.

Problem solving involves identifying the abstract properties of problems and fitting a performant solution (Should I use a hash map here? How do I measure this? How do I test for correctness?). Problem solving involves less code, more handwriting and sketching, but not necessarily less time. You may need to dust off some math you haven’t used in a while. Expect a lot of hypothesis testing and long walks for thinking. Maybe you know how to write great code, but if you can’t solve hard problems, you’re only skimming the surface.

Surveying is about comparative shopping (Which library should I use? What are the tradeoffs? What’s the community support like?). You can’t write all of the code. You can’t build all of the tools. This is where you choose a language on the basis of its fit for a project, where you choose a platform or a piece of hardware. Expect to read a lot of docs, code, and books.

These three skill domains are not wholly distinct. You’ll likely solve a lot of problems relevant to development, and your surveying is going to acquaint you with new solutions to problems. But each of these skill domains offer different enough perspectives that you can get a sense of when you’re doing one instead of the other. You can then formulate small projects — maybe twenty hour projects — to appreciably advance your skills in a well-rounded manner. Always plan your skill-building projects first. Get your environment set up. Test your tools and your approach. Set a concrete deliverable as your goal, and then execute.

Work Cycles

So you know that you want to learn how to build a DBMS. Maybe you’ve found a course or tutorial you like. How will you structure your time to maximize learning? Ultraworking Work Cycles. I love this idea so much.

The hardest part of learning is staying focused. The fundamental problem of focus is remembering what you were trying to do. Work cycles prevent you from forgetting. Journaling is great. Creating daily rituals — great. But work cycles will provide you with the kind of fine-grained, in-the-moment focus you need to press through substantial cognitive challenges.

Feel yourself getting tired, cranky, brain foggy? Work cycles will help you realize that you need to step away from the keyboard for a moment and reset. When you take a break, work cycles will make sure that you can recall what you were doing when you stepped away. (Thank you to Jason Benn for recommending Ultraworking.)

Weekly Calendaring

When I’m busy (when am I not busy?) I like the idea of pursuing one project per week. To make it easy on myself, I’ve created a Github project and written a short Python script to pump out a directory of files: one scheduling file for each day of the week, and one file to store goals for the week.

In the project root, I keep a backlog of training goals. Every week, I start with a project taken from the backlog, some goals assigned to Monday at the least, and another directory of files assigning myself a project for the next week. As I work, I update my goals for the day, I track what I’ve accomplished through my work cycles, and at the end of the day, I schedule goals for the next.


Different systems work for different people. Sometimes different systems work for the same people at different times. For me, the crucial factors are (1) knowing what categories of knowledge I need to track, (2) staying focused, and (3) being able to distinguish preparation from execution (execution always results in a deliverable that I produce, it’s never pure consumption or emulation). Ask for advice from people who are good at what they do. Experiment and adjust as you go.