Pressing the Pause Button

Part 1 of 1 in the series: A Coding Career Reset


This post explains my reasoning for taking a gap in paid employment to explore new technologies and skills. It also covers how my research and learning process will be structured and highlights some of the books I drew inspiration from for this adventure.


Two weeks ago I left my job working as web developer for a university department. I had taken a temp position there in 2020 right before COVID forced the campus into lockdown and sent students and faculty home. I came in hoping a regular position would open up within a few months, but pandemic related budget cuts quickly eroded that possibility. I started applying and interviewing for new roles a few months ago, but after a brief search, I realized that the jobs I wanted didn't really match up with large portion of my previous experience.

My web development career started in 2008. My first job right out of college was working for a small agency doing Php development. After a few years of agency work, I moved on to a non-profit organization and eventually did a brief stint as a federal contractor. I have touched many different tools and technologies throughout my career, but the few constants have been Php and content management systems (Drupal, Wordpress, etc). Unfortunately, I have come to the realization that I really don't enjoy that type of work anymore.

A few years ago, I started diving into React and the modern JavaScript ecosystem and was instantly hooked (pun intended). It started out as just a side venture to add decoupling to my skill set, but the more I dove in, the more I realized that this was the direction I wanted to move my career in. Every side project I've done since has been in JavaScript or TypeScript and I've jumped at every opportunity to use React and related tools at my day job.

Even though I've picked up a ton of new skills over the past few years, I still don't feel like I've been able to break away from the path dependence I've built up over my career. When an employer looks at my resume, they see 10+ years as a Php developer with some recent modern JavaScript experience. So instead of explaining away my past experience in interviews, I've deciding to put my career search on hold and do a learning in public experiment. Over the next few months I will explore many aspects of the JavaScript ecosystem and choose a few technologies to dive deep on. This post is the first in a series that I will keep updating over the course of this adventure.


Simply put, the goal of this project is to eventually find a new job, but that's only part of the story. I am making a deliberate attempt to push back on the path dependencies of my early career and to take control of my career trajectory going forward. I will evaluate many different technologies at the start of this project to determine what core skills I would like to specialize in. Then I'll aggressively dive into those technologies. I will immediately put those skills to use building portfolio and side projects and start applying for new positions once I've built enough sample projects to show.


This project will be broken up into three core sections.

Part I: Casting A Wide Net

This section will mostly consist of research. First, I want to evaluate all of the tools and frameworks I have used over the past few years in addition to ones I've been hoping to try out. The goal here is to come up with a list of technologies that I both enjoy using and that I believe have strong future growth potential.

Next, I plan on researching individual companies and job postings. These will be limited to only jobs that I would likely take if given the opportunity. My objective here is to identify what skills and tools show up frequently for these roles that may be missing from my current skill set. Anything that shows up more than a few times across postings will be added to my list as a potential skill to learn.

The final step in this section is to reduce my list down to a few core technologies to focus on for the next phase of this project. This honestly may be the most difficult part of the process for me. I'm a generalist at heart and diving into new tools and technologies is something I greatly enjoy. Too much generalization makes mastering a skill nearly impossible though, so it's a necessary task. At the end of this step, I should have a short list of skills that both interest me personally and are highly marketable.

Part II: Becoming a Specialized Generalist

Part two will be a chance for me to really dive deep into the skills selected in the previous step. For each technology on my list, I will evaluate what resources are available for learning that skill (Courses, tutorials, docs, etc) and choose which ones to focus on.

There are four primary metrics I'll be using to evaluate learning resources.

  1. Release/Update date: Is this resource up to date with current versions, best practices, etc?
  2. Accuracy: Is the information in this resource accurate and recommended by industry leaders?
  3. Breadth: Does this resource cover enough information on the topic?
  4. Directness: Does this resource include hands-on projects and exercises that are representative of real world tasks? *This one is critical!

The amount of time spent learning each item will vary depending on the complexity of the skill, but each one will be followed up by a project. This is why directness is marked as important in the list above. Rather than just completing the learning materials and moving on, I want to immediately put the knowledge to use building projects. This should both reinforce the material learned and give me some example projects to point to for eventual job interviews.

The last item I want to look at in this section is professional certifications. This won't be applicable to all skills, but if there is a credible certification for a skill that is near my current level, then I will likely attempt the certification test.

Part III: Back Into the Fray

Part three is all about the taking the skills gained throughout this project and re-entering the job market. This will include general interview prep such as algorithm exercises and practicing common non-technical questions. There will also be elements that target specific positions such as cover letters, targeted resumes, code samples, etc.

Interviewing should also give me an opportunity to check and refine my new skills throughout the process. If there is a particular question that I struggle with in one interview, then I'll be able to spend more time researching that topic and prepare a better answer in case a similar question comes up in another interview.


There were many books, podcasts, and blog posts that gave me ideas for this project, but there were three books in particular that had an outsized impact on me.

  1. The Coding Career Handbook by: Sean Swyx Wang. This book is a goldmine of information about all of the aspects of a coding career except the code. I encountered two types of information in this book; things I really wish I knew before and things I knew, but had to learn them the hard way. If I ever transition to a manger role, I will buy this for every junior developer on my team. This book is the primary reason I decided to write this blog series instead of just learning in private.
  2. Ultralearning by: Scott H. Young. Learning complex things efficiently is a superpower for developers. It lets us quickly adapt to changing job markets and project requirements. Ultralearning analyzes the habits and techniques of several individuals who have accomplished exceptional learning feats and distills their approaches into actionable items that can be used for any educational project. This book was a huge inspiration for how to organize this project, especially in Part II above.
  3. Atomic Habits by: James Clear. Habits account for a great deal of human behavior. Many individuals set ambitious personal and career goals that they never complete, not because they lack drive or motivation, but because they focus on the end goal instead of the daily practice needed to get there. Atomic habits is all about building systems and practices. It teaches you to constantly strive for 1% better each day instead of fixating on the finish line. This book will greatly influence how I plan out my schedule each week over the course of this project.

Wrapping Up

There is no exact end date for this project since it essentially ends when I accept a job offer, but my goal is 3-6 months. I don't mind if it goes a little longer and would also wrap it up early if the perfect position came along. Each week, I will write at least one post in this series. These will highlight progress made over the past week as well as set goals for the next one.

Over the past few years I've seen plenty of articles and posts about people breaking into tech from other fields and I've heard plenty of stories about people moving from development into management or burning out and quitting altogether. One thing I have not seen much of though is developers pressing the pause button; taking some time to assess their career trajectory and intentionally trying to break away from their past experience. Beyond the obvious goal of realigning my own career path, I'm also hopeful that this series with have some useful takeaways for other developers who may be hoping for their own coding career reset.