The Kindling
My journey to start developing software as my livelihood took a while. Looking back, I realize that I was always sort of around computers. I grew up in the age when regular people started using the internet. I had to take a few typing and computer classes in school as a kid. I had a few classes that touched on web development with various tools. My dad also did some work with computers and we always had at least one desktop around the house, and often more than one. I even helped him take a few apart and make minor repairs and upgrades over the years.
But it never clicked for me. Code seemed esoteric and boring and I never had a clear picture of what the possibilities were. I played the emulators that my dad would download and set up for me. I used Facebook and Myspace all the time (yes, I was in middle school when Myspace launched). I loved my iPod and the ability it gave me to take all my music wherever I wanted to go. But I never connected the dots that I could be a part of making things like that in the world.
It wasn’t until much later that I would catch the bug. After I had earned a Bachelor’s degree that I had no real intention of using. After I had spent years learning and working with audio, video and lighting for live production environments (think concerts, conferences, and churches). After I had begun to pay for rent and insurance and taxes, and get a taste of what life is like as an adult.
The Spark
In my first job out of school I was the grunt worker on a team of five very capable production managers at a church of about 5,000 members. As a team we were responsible for maintaining and operating any and all equipment related to audio, video or lighting used in weekend services and auxiliary events. My main role was scheduling the twenty or so volunteers that we needed to make things run every weekend, and I would run sound or lights or direct video for various events and services. And, as the junior member of the team, I would do pretty much whatever else needed to be done.
A few months into the job I was given a task. We used Basecamp as our project management tool. Everything we needed to get done as a team was kept track of in there. But there was a problem. Occasionally there were events, scheduled by other departments in the church, that didn’t make it into our system. On more than one occasion, no one told us that they needed our support for an event until the day of that event! I don’t know if you have ever been unexpectedly asked to stay at work for an additional six hours. If you have, it probably wasn’t to manage a microphone and music in a room full of two hundred teenagers. But I’m sure you can imagine that those were not the best days.
Now when people would schedule an event they would fill out a form in another piece of software and there were even some questions on that form that asked about what AVL equipment/support they would need. But it was their responsibility to make sure we got that form if we needed it, which often meant we didn’t get it. So I was asked to find a way to bridge the gap. To find some automated way of connecting this other piece of software over there to our Basecamp over here.
I dove in on finding a solution. I started learning about a few programming languages. I learned some python and some ruby. We had access to a website called Lynda.com which had educational videos on a variety of topics, including some basic computer science and language material. I watched some of those every day and learned all sorts of things. I wrote some scripts that moved files and folders around on the computer and I felt like a god. I worked and worked on a terrible little script that would solve this problem at work, and I finally accomplished it.
After a few weeks of focused learning and a lot of trial and error I had a script I could run that would copy events over from the church’s software to Basecamp. It was very poorly organized. I’m sure it was full of bugs and security vulnerabilities. I would be embarrassed to show it to anyone today (fortunately, I don’t have it so I can’t show it to anyone even if I wanted to 😁).
My plan was to set it up as a cron job on one of the desktops that lived at the church and have it run every day or so. Since people filled out this form weeks before their event, that would get the information into our system with plenty of time for us to plan for it. But as it happened, we discovered a new web service for connecting various tools called Zapier just as I finished up my script. This was obviously a better solution with support from actual developers and it could serve as the glue between a few other services we used as well. So my script got trashed and we went with Zapier instead.
But this experience was the spark that lit the coding fire in me. I got a taste of a language that felt like magic. I could type some characters into a computer and it would do whatever I told it to. And some of the things I could tell it to do would solve actual problems that I had in my own life or that I knew other people had. I had found a new passion.
My advice for myself (or anyone else) in this stage would be to stay open. Be willing to say yes and try new things. You never know what mundane and trivial project you take at work might actually be the start of a whole new career for you.
Smouldering
I kept learning, going through courses on Lynda. I stumbled upon Stanford’s computer science courses. (They put all the material online and you have access to it all for free, so no excuses if you’re trying to get started.) I went through CS 193 which was called “Developing Apps for iOS” and I got my first few apps running in a simulator. They were ugly and not very functional and it was the Swift 2 days so the code itself was pretty ugly too. But I had written a piece of software that had a UI, and it could run on the phone in my pocket all on its own. I could hardly believe it.
It would be another four years before I decided to switch fully into software development. I kept dabbling in things over time. I went through a bunch of Free Code Camp’s material and I read some books and blogs and watched videos on YouTube, etc. But I never felt like I was qualified to get a job.
Throughout this time I learned a lot, and I do not think it was totally wasted time. I established my underlying understanding of how computers work and how programming languages generally work and the sort of logic that programmers use. I slowly saturated myself in the tech world and familiarized myself with the jargon, etc. I still draw on a lot of this base knowledge today.
But I didn’t make much actual progress because I didn’t take action, or at least I didn’t commit to the actions that I took. I built toy apps and websites. I made a “portfolio” website that I never deployed. I never learned Git. I had no stake in the game. It was fun to learn and make pomodoro timers, but if nothing came of it I didn’t lose anything but a little time.
My advice for myself (or anyone else) in this stage would be to find a way to get a stake in the game. There is infinite material out there to learn and more tutorial projects than you will ever be able to complete. Once you have a hang of the basics, find a way to give yourself something to gain (or lose). You’ll be amazed at how much faster you progress. Buy a course. Pay for a bootcamp. Get a contract for a project that is reasonably out of your comfort zone. Make a bet with your friend. Post about your goal on your social media platform of choice. Do something that will have a real cost if you don’t accomplish it. Just make sure it is a cost you can recover from.
Fanning the Flames
In the fall of 2018 I decided to quit my job and go through a pretty intense bootcamp that (at the time) was called Lambda School. The internet seems to have pretty mixed reviews on them, but my experience was exactly what I needed. They had enough structure and accountability to keep me going (it was fully remote, so I was spending all day every day alone in front of a computer). And they built in enough space that I could try things out and learn how to find answers for myself (which is a huge part of the actual job of software development). The iOS cohorts were also pretty small and I met some incredible people along the way.
I got my first job right as I was finishing up my time at Lambda. I had applied for over a hundred, interviewed for a couple, and got an offer for one. It had taken almost a year since I quit my old job, a lot of work, a lot of learning and reading and coding. But I got there. I found someone willing to pay me to write code for an iOS app, and my starting salary was 40% higher than any other job I had ever had in my life.
But that was merely the start. I still had so much to learn. I had to learn about how to work in the context of a team. I had to learn about Agile practices and what “scrum” and “sprint” and “epic” and “story” meant. I had to learn about the lifecycle of a feature in a company. How it goes from idea to plan to design to implementation to testing to release to maintenance. I had to learn about the push and pull from various parts of the organization from leadership to marketing and sales to design to engineering and how to balance the tension. I had to learn how to communicate my ideas to people who had no context or understanding of the technical constraints and to people who would be implementing the idea themselves. I had to learn how to document decisions and write tests and give demos. I had to learn how to debug CI/CD and network requests. Etc.
In short there was a whole other world of things to learn that I had no idea about before I got an actual job. Tech companies move very fast and structure their work in a very different way from anywhere else I had ever worked. It was a lot to digest while also trying to put out a decent quality and quantity of code as a junior developer. But those lessons and experience are what took me from being a junior developer to being a senior developer.
My advice for myself in this stage would be to view yourself as a student. Stay curious. Ask questions. Even (especially) if you feel like they make you look dumb. Listen to the answers and take them to heart. Take the advice that is given to you by the engineers around you. It may come across as a rude comment in a PR review but it is intended to make the code (and you) better. View bugs as opportunities to learn something. View features as opportunities to learn something. View code reviews (both given and received) as opportunities to learn something. Especially as you begin to gain seniority and get paid more it gets easier and easier to think that you have all the answers. But you don’t. You’ll do yourself a disservice by acting like you do (not to mention those around you, and your users, and your stakeholders).
The Fire Rages
Lately I feel I have hit my stride. I have a good rhythm of work and play and learning and rest. I have a job that I enjoy, working on a product that I know improves a lot of people’s lives, with people I respect and constantly learn from. I am spending more time mentoring people who a newer to this than I am, doing what I can to help people like innumerable people helped me. I am spending more time sharing what I learn in so others can (hopefully) benefit from it. I am trying to find the balance between having contentment and striving to grow and be better. I am where I wanted to be four years ago.
I don’t know that I have advice for myself in this stage because I am still in the midst of it. But maybe you do. What advice would you have for someone in this stage of their development journey? Let me know and I’ll update this post with any of the good ones.