by Jennifer Lyn Parsons

Six years into my career, I wasn’t the developer I wanted to be. My non-traditional background put roadblocks in my way, my career was stagnating, and I was on the verge of leaving tech. This is the story of how I pulled myself through a year-long process where I not only leveled up my skills, but finally fell in love with writing code.

A bit of history

While the internet was growing up, I was a bookseller, barista, administrative assistant, and finally, graphic designer. As a hobby, I dabbled in web development. When the economy crashed in 2008, I found myself unemployed in a field that was never going to bounce back. I decided to swap my hobby for my career. I took a short certificate course in web database development. Bootcamps weren’t a thing yet, though I definitely would have attended one if I was in the same position now. Even before finishing the certificate I started looking for developer jobs, leveraging my experience as a designer and my hobby work to get potential employers’ attention. I began working as a developer as the economy started recovering.

Fast-forward to early 2016 and I was ready to cut and run. I was good at what I did, but didn’t love it and wasn’t even sure why. I struggled to get out of bed, regularly thinking about what else I could do for a living. I didn’t feel like a “real” developer.

The challenges

In June of 2016 I decided to take a hard look at why I was so unhappy. I had never fully embraced my career, always feeling like there was more to it, but didn’t know what that meant. I kept asking myself questions until I was able to clearly lay out my challenges.

I was self taught, with weird gaps in my knowledge and lacking a shared vocabulary. We all have gaps, but I was hyper-aware of mine. I couldn’t move forward with joy. I also couldn’t ask questions that would allow anyone to help me because I wasn’t even sure what to ask. I had misconceptions about programming as well. I also sought the same flow I find when writing prose and fiction, something not easy to find in logic-based programming.

I was my own worst enemy because I felt that my path wasn’t “legitimate” and that I was lagging behind everyone else. My lack of confidence in my skills meant that throughout my career I took whatever job was willing to “give me a shot” rather than going after jobs that were better paid or would challenge me more to improve my skills. All of these jobs centered around badly organized legacy codebases that were extremely fragile, with feature creep leaving them full of bugs. This often left me feeling like little more than a debugging machine and compounded the problem.

Working on legacy codebases is not inherently bad, in fact I learned most of what I know by doing that work. The problem was that the environments I was in were not ideal. Everyone I worked with was busy fixing bugs too, leaving little room for mentorship or feature planning. I had been a “professional developer” for over five years and should have been senior level, yet I failed tech interviews because while I could definitely fix things that were broken, writing code from scratch had rarely been part of my job.

This was daunting list of challenges, but at least I had perspective. Leaving tech was still an option, but I decided to give my career as a developer one last shot. After all, I still worked on personal projects on the side. You don’t usually do that with something you truly dislike, right?

I set a goal. I would give web development one year of solid effort, pushing myself to see if I could uncover the satisfying career I felt bubbling under the surface. At the end of that year I told myself that if I failed, I would look for a new career.

Getting Started

Acceptance

My initial step had nothing to do with writing code. I had to first accept that this was going to be incredibly difficult. Everywhere you turn, potential developers are told coding is “easy”. (Learn it in twenty-four hours!) This is a false portrayal of what meaningfully learning to code looks like and part of what kept me feeling like a failure for years. It was supposed to be so “easy” but I hadn’t learned it yet. As I discovered when I looked at the task without the hyperbole attached, it was because it was, in fact, difficult.

I needed to accept that patience was required while I was learning. Each step meant loads of work and research before I could move forward. I was good at teaching myself things, but had hit my own limits. To level up, I needed to find help wherever I could.

Finally, I had to accept the current limits of what I knew. My HTML, CSS and debugging skills were solid. I also had learned jQuery, some PHP, and some proprietary bits of tech. I had starting points, though looking back, I can honestly say I had even more skills than I thought at the time. My own perceptions of what I could do continued to be a silent barrier, even as I forged ahead.

Setting the goal

I knew where I was, had examined my emotional and mental state and my skills. Time to decide where I wanted to be in a year! The next step was to determine my vision of success would look like and what it would take to keep me in tech.

My success rested in my skills in writing JavaScript. I had failed learning it multiple times before, to the point where it became a spectre that haunted me. At the same time, the web development community had embraced it fully, even bringing it onto the backend. JavaScript had become the defining language of the web, so everything hinged on learning how to write it fluently. On a personal level, I wanted to feel comfortable joining those enthusiastic discussions I saw others having. It all seemed exciting and I wanted to be a part of that.

I also wanted to build awesome stuff. Tools, apps, things that would be fun to make and be useful to people. For example, I’m a writer and saw opportunities to build tools like word counters and submission trackers that would help writers get their stories into the world without bogging down their creative process. Anything that will help people do what they love doing more easily is exciting to me.

Gathering resources

To get started, I needed solid, dependable resources. This took the form of courses, books, people and time. I started hunting down recommendation lists and upped my participation in the Slack groups I frequented, joining technical channels I’d been nervous to even look at. Taking a look at my schedule, time was a big challenge, but I made it happen. I had every resource I could readily get my hands on at the time. I was ready to start.

I do want to note that there were some sacrifices I made in my schedule that are unfortunately still taking a toll over a year later. If I regret anything, it’s that I didn’t approach this challenge in as balanced a way as I could have. Burnout was always just around the corner and I have a novel in progress that still isn’t complete because I put it aside to work on my skills. I run a magazine and independent publishing company on top of my full-time job, and these both suffered from my absence as well. All told, I would have had a more mentally healthy experience if I had taken more measured breaks. I allowed my fear about falling behind and that lack of self-confidence drive me to push myself harder than was good for me. As a result, I started selfcare.tech in the wake of all this to help myself and others find the tools they need to tackle this challenging work in a healthier way.

Diving Into the Deep End

I was bored by the idea of a todo list, so to keep my motivation up I needed to make something I’d want to use, was a big challenge, and was something that could be broken into smaller tasks. I decided to start my capstone project right at the beginning. Many would advise starting with smaller projects and building up to them, which is generally a good idea for beginners who need to get used to the write/test/debug cycle of writing code. I had been at it long enough that I understood that aspect of development and was looking for something I could sink my teeth into for the year ahead.

What kind of project would carry me through the hurdles I knew I would be facing? I worked with a text-based game engine earlier in the year, but was frustrated with it. It didn’t shine when trying to shoehorn in RPG elements like health meters and inventories. Despite the looming size of the project, I decided to build my own game engine. I made the perfect choice for what I was trying to accomplish. It was a large project, something that would give me a variety of challenges at almost every level of the development process, and when it was finished, would also be one of those awesome tools I wanted to build to help other people express themselves.

Before I dove in though, I did some studying. I went through the basics of JavaScript again, using courses such as Codeacademy and Free Code Camp to review variables, functions, etc.fter finishing, I was still left with a huge gap: I was unsure how to get from understanding what a function is to building something useful. And not just one function, but a whole series of them that talk to each other.

I’m a hands-on learner. I learn best by making things, taking them apart and putting them back together. I felt like my best bet was to dive into the game engine and see what happened, and soon, I knew some of the features I wanted to build.

I named the engine Plastic. Its mission was to be a game engine for making interactive fiction and other text-based games. Its language is unopinionated. No “weapons” or “armor”. Instead, there are things like tools and gear. You can create a battle RPG or a game explaining spoon theory. The concept felt exciting and I started building it.

My first attempt was not a success. I built navigation elements and bits of interactivity. I was jumping from idea to idea with no real method or order to things. I was also focused far too much on creating the interactive elements, which resulted in a simplified set of functions similar to jQuery’s DOM manipulation tools. This would be very useful in later stages of the project, providing a lightweight alternative to jQuery tailored specifically to game interactions. However, it was not what I was trying to learn from writing Plastic. A friend guided me through Object Oriented principles to try to clean it up, but I didn’t have the resources to know how to carry it forward. I knew I needed more help, but had no idea where to find it.

Enter the mentor

Cue the amazing WeAllJS Slack group, one of a couple groups I’m a part of that form my network of contacts. Here “networking” looks more like being friendly, sharing fun gifs, and helping each other with technical problems. Putting in the work of being visible there was not only fun, it also led to meeting my mentor and, later on, to finding a new job. Despite being a decade younger than myself, my mentor was ahead of me, career-wise. We bonded over a similar career history and goals and she was enthusiastic about working together. With her help I got past some of my biggest obstacles and I’m grateful.

We set goals for our time together which was key as it kept us on track rather than devolving into socializing and side tangents. Our weekly Hangouts were work meetings, and it made it easy to measure my progress and stay motivated. She helped me find that shared vocabulary I was seeking. In an early meeting, I walked her through my day-to-day tasks and she broke down what I was doing into nameable skills. This task was software architecture, another was a tech lead responsibility, over here was a bit of project management, until finally my mentor told me, you’re being a senior dev, you just didn’t know what to call it! I understood my own job for the first time. It was a revelation and I was already feeling more empowered, a little more sure of who I was and what I was doing.

Next we started tackling that gap between learning syntax and writing a program. We did some software architecture. I made design documents and formally planned Plastic, what features I wanted and how to write it as modularly as possible. This was really fun as it helped me see the bigger picture of what I was trying to build, beyond my initial idea, but also helped me see how to start breaking it down with increasing granularity into something I would be able to build. Plastic became more refined as a project and I found myself excited to tackle each new step.

All autumn I pulled my knowledge apart and put it back together again, now with proper names for things. The boost to my confidence was significant. While I still felt I had a long way to go, I was grasping programming from a wider perspective. I was starting to love it.

The scope contracted again as I started Plastic over from scratch, building up a minimum viable library of the basics. I wrote functions that created a character, an inventory, and ways for those components to interact. Every week I worked on it and then we reviewed my work, refactoring as I learned new concepts along the way. I was learning to write code from scratch for the first time. Those debugging skills definitely came in handy. I was writing new code and because it was such an unfamiliar way of thinking, with that code came plenty of bugs.

Diversity in my projects let me use my new skills repeatedly in different ways and also gave me a way of making progress elsewhere when I was stuck on something with Plastic. So, I started writing an app to organize my tea collection, using it to learn Angular. My mentor and I talked about APIs and interfacing with the back end, which led to my first exposure to MVC. I started to feel my knowledge deepen and was no longer able to break it down into a sound bite for those who asked how I was doing.

Diversification station

As I built these things, I worked through more challenging materials. I also kept one eye on what else was out there. Now that I was starting to understand how JavaScript worked, learning other languages felt possible, too.

Of all the things I could have latched onto, Clojure caught my eye. A friend is a devotee of this Lisp-based language and gradually sold me on it, showing me code samples and explaining its merits. I was intrigued, but no no, I was focused on JavaScript.

It was almost Spring when a dream job came up. It was partly in JavaScript, but mostly in Clojure. I had never written anything in Clojure and didn’t have an environment set up for it. I was totally unprepared, but wanted to go for it because the work they were doing was something that spoke to me and I understood by now that throwing myself into the deep end was good for me and my desire to get better at what I do. They were also open to folks who didn’t know Clojure, but were willing to learn.

I applied, putting in more effort than usual on that cover letter, and was asked to do the take home exercise! I had a week to get a todo app done, front and back end. This was an exciting test for my new skills.

I took on the challenge with gusto. I made a plan, outlining my approach to the app itself as well as gathering the resources I needed to get it completed. It was worth giving up my weekend and free time that week to maximize my time, so I also made that sacrifice. In one week I went from barely being able to read Clojure code snippets to getting a new dev environment set up, learning enough to make that todo app, and even deploying to Heroku for the first time. I actually did it! And it was fun! In the end, I didn’t get the job, but it hardly mattered because I was truly proud of what I had accomplished in so little time.

All the work I had done to that point was paying off. Even more than learning JavaScript, I had learned how I learn. I developed an internal Rosetta stone that helped me learn other things. Because I knew how an array worked in JavaScript, I understood an atom in Clojure. Despite mostly working in OOP, learning functional programming in Clojure felt natural. Learning both of these styles and languages simultaneously helped me understand all of it faster than if I learned them singly. It was like I had found a learning super power. It’s something I continue to rely on to this day. Whenever I run into a concept or syntax that’s unfamiliar, I look for the similarities. How is it used? Does it work like something else I understand in another language? As I learn other languages and concepts, they all feed into this translation matrix in my head and it makes learning the next thing that much easier.

The results are in

When the Clojure job fell through, I put the language aside. I refocused on Javascript, because the me who went into that Clojure code challenge was not the same one who came out the other side. I couldn’t have planned for the changes that would happen to me through that process, but they yielded undeniable results.

When I went back to Plastic and my other studies, my confidence had shifted. I had gone through the crucible and left behind the parts of myself that held me back. I broke the failure chain. I also had a really great time doing it and had an app I built myself to show for it at the end.

It took until the summer, but I did find an amazing new job. That interview process was almost as challenging as the Clojure one! I had to live code in React for one part and Node in another, neither of which I had learned yet. Once again, I hit the books for a weekend and managed to get enough knowledge down that I was able to enjoy the live coding, nerve-wracking though it was.

This was the real culmination of that work I started a year before. I had enough facility to do the work, but also developed the more important skill of learning how and what I need in order to learn things on my own. In the process of all this work, mostly importantly, I was doing something I now loved to do. There was a place for me in tech and tech had a place in my life.

Lessons Learned

So, besides a new job and better skills, I took some valuable wisdom from the experience. Development is not easy nor simple, but it is doable. Time, effort, the right resources, all can make the difference. It’s fluid, changing and growing. Staying flexible and learning how to learn is just as important as the latest framework. Get the foundations down and the rest will come.

I set goals and stuck to them. I made a schedule and held myself to deadlines. This was not easy. Making time was difficult. I lost some sleep. Sometimes I was pretty dang inefficient. But even when I took breaks, I pulled myself back in. It wasn’t the wasted time that mattered, it was the fact that when I did spend an evening playing video games, I got back to work the next day. Focus is a balancing act and some days you hit the net.

There were plenty of times in this process when I hit a proverbial brick wall and was afraid I would never understand whatever concept I was learning at the time. Sometimes I cried about it, but I had put so much effort into learning things and had solid evidence that I could do it if I was patient, so I never entertained the idea of giving up. Instead, I would ask a friend, read more, find a helpful video, or write some code on a different project. Something would eventually come along that would flick the light switch in my head and things made sense again. I kept reminding myself that it was all just a thing I didn’t know yet, just like all the other things I had already learned.

A lot has changed since I started out as a hobbyist all those years ago. Beyond the technology itself, which has evolved more rapidly than anyone could have anticipated, the resources available to learn how to code are both easy to access and incredibly diverse to meet different learning styles. The MDN documentation would have made a huge difference when I was learning the first time around if it had been available then. Various Slack communities and Meetups and all the courses, both free and paid, that are available to help people learn to program are almost overwhelming in numbers. What’s important is that you find the ones you need to get you where you want to be.

Where do we go from here?

So, now that I achieved my goals, you might be wondering what I’ll do next. It probably won’t surprise you that I crafted a new syllabus for myself and I’m already working towards the next level up. I love what I do now and there’s still so much to learn. There is always a hit to my confidence around the corner, but I now have solid successes to look back on each time I tackle something new. That’s vital in maintaining perspective and moving forward on the path of a career.

This is my journey, and hell, this is only a window into it, what I can sum up in a few words. If you’re struggling and feeling like maybe programming isn’t the right thing for you, I humbly suggest stepping back to take a look at where you’re at and where you want to be. What made you want to start writing code? Is there a way to use that original inspiration to make a path forward? Your journey will look completely different than mine, but I encourage you to seek out the resources you need and try again. When I started that year of hard work, I didn’t think I could do it. I surprised myself with how much I already knew and how much I learned in such a short amount of time. You can do it, too.

Software development needs people with diverse experiences. We bring different perspectives and new ways of looking at problems at all levels of the process. We can help make the programs and websites and other things we build reflect the full range of what it means to be human.

You can be part of this world, too. Set a goal, make a plan, talk to people, gather your resources, just do it. Get to work. I look forward to seeing what you build!

Jennifer “JP” Parsons has over 7 years professional experience in web development, with an additional decade of graphic design experience. JP has a goal to build tools that are useful, engaging, elegant and leave the world a better place. When not coding things, JP runs a small but vibrant publishing company, Luna Station Press. Sometimes fiction writing and sleep happen.