Turning experience into growth

When you spend hours working on something, you naturally get better at it. This is a form of passive growth.

Not every project you work on will be ground-breaking, or use the shiniest new tech. Does that mean you have to code on the weekends to keep growing as a developer? No, it can be done as part of your day-to-day job! How then can you turn the experience gained from the boring tech project into growth?

Active Growth

Just because you’re focused on shipping features doesn’t mean you can’t grow. Even on a mainstream project that uses boring tech, you can find many sources of growth if you just choose to pay attention. This is active growth. You don’t just let the hours go by and hope to come out more experienced on the other side. Instead you, you make conscious choices to interact with and mine your experience with the goal of improving yourself.

Hours spent coding don’t all count equally towards making you a better developer. You get a higher return on your time investment by taking a more mindful approach. Introspection, transformation, and creation are the name of the game. Here are some things that work for me.

Introspection

Introspection is at the heart of active growth. You pay attention to the work you do and ask yourself questions such as:

  • Why did you take a particular approach?
  • How does it compare to other times you’ve done this?
  • What did you learn today?
  • How does the thing you did today connect to other topics you’ve been thinking about?

This sort of conversation with yourself is a great way to get more value out of your work when you are solo.

Note-taking

Another great technique is note-taking. This takes introspection one step further by forcing you to write your thoughts down. There are many ways to take notes.

Quantity is better than quality. The important thing is that you are moving ideas and lessons out of your head and onto “paper”. This can be a simple as keeping a TIL document open, or compiling a daily note in your favorite note-taking software.

For the past few years, I’ve been using a note-taking approach inspired by Zettelkasten and Evergreen Notes where I create a series of hyperlinked atomic notes, each of which has a title that is a thesis statement for an idea I think is true about software, and then a paragraph of text and a diagram or code example. Short notes keep the cost of adding a new note low so it’s easy to add new ones frequently.

Some colleagues keep a file with code snippets they find inspiring or patterns they find useful.

Artifacts

On learning journeys big and small, I always look for some kind of artifact I can end up with. This helps me stay more focused, and allows me to have more concrete takeaways. Artifacts are such a powerful technique because they take you out of a more passive consuming role and put you in a more active producing role.

Artifacts come in all shapes and sizes. Notes, as described above, definitely qualify, as do other forms of prose such as reports, blog posts and even tweets. One of the earliest blog posts I wrote was attempting to create an artifact to summarize what I’d recently learned about working with I/O in Ruby.

Code is another form of artifact that can encapsulate something you learned. This could be experimental code you tried, or a “capstone” of sorts that you put together to summarize something you learned. While this could be a full on sample repo, artifacts don’t need to be huge. A gist demonstrating a concept or even a code snippet shared in a chatroom all count.

Another artifact I love creating are diagrams. These move me out of the textual world of code and into the spatial world of shapes. They are a great way to help me understand ideas, and also to help communicate concepts to others.

diagram of history implemented as a current value and two opposite-pointing stacks
A diagram illustrating how undo/redo functionality can be implemented a pair of opposite-facing stacks

Artifacts are a great way to get ideas out of your head, which in turn helps you refine them and build on them to accelerate your growth. They benefit you, even if no one else ever sees them. What’s an artifact that you’ve produced this week?

Sharing

I’ve found that sharing (and engaging) in company Slack is an activity that provides a lot of growth for little effort. Some things that make great shareable tidbits include:

  • Questions you have
  • Articles you’ve read
  • Ideas you’re thinking about
  • Any kind of artifact (e.g. diagram, code snippet, report)

Sharing artifacts with others compunds the value you get out of them. It will start conversations and get you feedback. People might have questions. Others might be interested in remixing your artifact and share it back, giving you a slightly different perspective on they original work.

I usually like to share as publicly as makes sense for the artifact in question. If it’s a report or code snippet that contains sensitive information, then you might be limited to sharing within your company or team. However, you might be able to make a generic version that is shareable. The exercise of pulling out something generic is also a great way to deepen your expertise.

Pairing

Pair-programming is another great way to grow more actively. This is because no two people think or work exactly alike. You learn from each other’s heuristics, mental models, and ways of approaching a problem. You also have to be more explicit about your assumptions and explain what you are trying to do to your pair.

Pairing with a more junior colleague can be particularly valuable because helping others learn is a big multiplier on your growth.

Dialogue

Dialogue, where two people go back and forth on an idea, is a favorite of philosophers for a reason. I have a couple people with whom I have a recurring 30 min monthly call just to explore an idea. When it’s my turn to share a topic, it commonly comes out of a recent theme in my note-taking system.

I’ll usually pitch some kind of thesis statement, heuristic, or mental model and ask for thoughts and reactions. We might then go back and forth, examining edge-cases, applications of the idea, different formulations, or how to break it. Something that feels natural or intuitive to me might not be so for my interlocutor. We usually come away from the conversation having both learned something. I often have lots of follow-up ideas!

Fitting this into a 40 hour week

The goal with all of these is to find ways to keep growing without having to put a lot of time into extracurriculars or being assigned to an exotic project. It’s easy to get carried away with ambitious dreams when looking to self-improve. Instead, find ways to either incorporate these practices directly into your day-to-day work, or start with variations that add minimal extra time to your routine such as 10 mins of introspection at the end of your day.

Do these small things regularly and mindfully and you’ll soon find yourself not just accumulating coding hours, but actually growing faster than you thought possible!