5 things I learned in my first year as a 2nd Career Developer
What I learned about how to be a successful software engineer
Okay, to be honest, I am probably a 3rd or 4th career engineer, but it doesn’t have the same sound to it. After spending more than 10 years in retail management, getting my bachelor’s degree in marketing at 33 years old, and working a few years as a System Administrator, I decided to take a leap of faith and take a shot at becoming a Software Engineer at the nice, “young” age of 37 years old.
Almost a year has passed since I became a Junior Software Engineer for Dictionary.com, and I was recently promoted to a mid-level engineer. I was able to build my skills, knowledge and the respect of my peers quickly by avoiding common pitfalls and focusing on the important things. This allowed me to become a productive engineer quickly.
I would like to say that the transition was easy, but it certainly had its challenges.
You don’t need to be a genius, you just have to like building things
“I had to reject the thought that only smart people can be engineers and assume that I was smart enough”
Before I even became an engineer, I needed to get past one very important roadblock. I had to reject the thought that only smart people can be engineers and assume that I was smart enough. To me, the idea that only smart people are engineers is one of the biggest misconceptions. Too many people that would be great engineers are scared away before they even start because they think that these careers are only for “smart” people. I have also been told by friends and family that I must be really good with math to be able to do the work. I will admit, having strong math skills is helpful but I have rarely (probably never) needed to use advanced math to complete my work.
Since Computer Science is taught with so many math courses in college, it is easy to see where the idea that you have to know math comes from. The advanced math that was taught in the Computer Science program I entered when I attended college the first time is a big reason that I didn’t finish. I loved the idea of building things, but I lost my interest in the whole thing because Calculus was so boring to me (and I wasn’t very good at it). I didn’t want to learn about derivatives, integration, or any of the other math words I don’t remember the meaning of. So I dropped out of college.
The fortunate thing is that I never stopped loving the idea of building things. I found myself creating report tooling and other psuedo-applications in Excel for nearly every retail company I worked for. When I worked for a computer retailer running a repair center, I created a whole reporting dashboard that used connections to a SQL database, macros, and a bunch of conditional statements, VLOOKUPS, and other nifty Excel things to build a tool that my co-workers and I could use. What I didn’t realize at the time was that in many ways, I was programming.
As I changed companies and roles over the next 10 years, I often found myself creating tooling in Excel and other malleable applications to make the work I did easier. I never really considered this “programming”, and I often found myself doing more of this creative work than perhaps my supervisors wanted me to do. Doing those things kept the pilot light on for my creativity. I really enjoyed building things, but I didn’t think I could transition that into a career without a degree in Computer Science.
It wasn’t until I became a help desk engineer for Ask.com that the pilot light would eventually be used to light the fire that would lead me to where I am now.
Getting a job as an engineer
“I jumped on the opportunity to show my ability as a potential engineer whenever I could.”
Since my background was mostly in retail management, and my degree was in marketing, I was extremely lucky that I was able to get my first job within the tech industry. I wish I could say that I have a magic way to get a foot in the door of some tech company, but it was a friend of my wife who gave me my first job. It was an entry-level position, but it was a start. The one thing that I can say is to get into the industry any way that you can. For me, my personal network is what opened the first door. I had to do the rest.
Once I joined the help desk team at Ask.com I immediately noticed areas of work that I really did not want to do. I worked with Microsoft Exchange, Active Directory, and Windows Deployment Services. The process of using and updating these services was manual and often required repeating the exact same steps each time you needed to complete a task. This seemed very inefficient to me, but more than anything, very boring.
After taking some time to master the basics of just being a help desk engineer, I decided to fix my “boring work” problem. I began to teach myself PowerShell and started to write scripts to make my day-to-day work easier. These scripts started out small and simple, allowing me to accomplish tasks such as new user creation across all of the platforms by providing just a few pieces of information. Eventually, I was writing the automation of tasks that previously required manual intervention.
Eventually, I was promoted to a System Administrator, and became responsible for far more critical infrastructure that I managed primarily through the scripts that I wrote. Since a lot of my work was automated, I was able to spend time on side projects for the team. This is where my real journey of becoming a software engineer began, and I started to learn PHP. I spent a lot of my personal time learning PHP out of pure curiosity (more on the importance of curiosity later). I would use it to write various applications to support my work and team. These applications were noticed by a few stakeholders that were important to my early development.
Occasionally, these stakeholders would need some small development work done, but lacked the engineering resources. I jumped on the opportunity to show my ability as a potential engineer whenever I could. It didn’t matter how small or unimportant the project was, I would volunteer to do it anyway. Not only did this get me exposure for when I wanted to make the leap to being a software engineer, it also gave me the opportunity to learn.
Once I felt that my skills were enough to begin the process of becoming a engineer, I reached out to the engineering leadership of Dictionary.com, a sister company of Ask.com. I liked the technology stack that they were building (NodeJS, React, Redux, MongoDB, AWS) so I decided to try joining that team. I was worried that I wouldn’t be taken seriously since nothing about my work history said I could be an engineer. What I found when I spoke with the engineering leadership was that my reputation from all of the small projects I was part of preceded me. I was already respected enough to earn an opportunity to go through the interview process that would eventually get me hired. All of the small projects I volunteered for paid off!
The importance of communicating well
“Once I changed teams, one of the first things I realized was that there really is a diversity in backgrounds, personality types, and learning styles.”
My previous team (as a System Administrator) and I all had very similar interests. We liked beer. Okay, maybe that was just one thing, but it was an important thing! Once I changed teams, one of the first things I realized was that there really is a diversity in backgrounds, personality types, and learning styles. This may seem obvious, but for me this was a realization that came with some difficulty.
Finding ways to effectively communicate with my peers was - and still is - one of the hardest things for me to do. I spent a good amount of time working on my own when I was a System Administrator, so collaborating with a team to accomplish my work was new to me. I am a very extroverted person and I have learned that not everyone appreciates my eagerness and excitement. Being self-taught, I often find myself not having a full toolkit of ways to explain something effectively to my peers. Communication is a work in progress for me.
Communicating a point to a large audience well should be developed just like any engineering skill. I might even argue that effectively communicating may be more important than anything else! When trying to communicate, I think it is a good idea to think through the points that I want to make before I even start talking (I write them down). This helps me make sure that I have completed my thought process and can more clearly explain it. Also, I try to make sure I am listening to what people are saying. I can’t count how many times I have been thinking about what I want to say instead of listening to what someone is saying, only to come back to their point because they were right in the first place. You can save yourself a lot of time and headache just by listening!
Dealing with “Imposter Syndrome”
“The fact that I could create a long list of things that I didn’t know not only meant I was aware of my weaknesses, but it was also a list of things I could learn!”
Imposter Syndrome is something that everyone has to deal with at some point. For me, it began before I even started my new job. I had to wait a few months to start working as an engineer as I finished up my previous assignment. I was going from work that I was very comfortable doing to something that had really just been a hobby. I was terrified that I would be woefully inept once I had real code to write. I couldn’t stop thinking that everyone would find out that I couldn’t do the work.
I remember one of my first tickets after starting. I was tasked with investigating legacy database ingestion code that was written in Ruby. The problem was that all of my experience was in Javascript and PHP! I probably spent more time than I should have working on the ticket because I had to spend time deciphering the foreign syntax. I was afraid to ask questions out of fear of being found out. I also spent a lot of time second-guessing my notes because I doubted my understanding. When I completed the ticket and shared the results, I was certain that the mountain might be too steep for me to climb.
At the time, I didn’t think it was a great introductory experience but looking back, it was perfect. The lead on my team made sure that I knew that it was not an easy ticket even for a senior engineer. When we sat down afterwards, he let me know that asking questions when I am unsure of something is expected and that no one would judge me for what I didn’t know.
In fact, one of the most important things that I try to remember when I feel overwhelmed, is that being able to identify my lack of knowledge is a sign that I might actually know what I am doing (maybe). A quote from Confucius sums it up the best:
“Real knowledge is to know the extent of one’s ignorance.”
The fact that I could create a long list of things that I didn’t know not only meant I was aware of my weaknesses but it was also a list of things I could learn! How exciting! I try not to look at feeling like an imposter as a bad thing. Instead, I see my self-doubt as a challenge to learn more and dig deeper. The more that my curiosity drives me to learn, the more I realize what I don’t know. Eventually I might know enough to sorta kinda feel like I know what I am doing.
The importance of curiosity
Curiosity will help guide you throughout your journey as an engineer, whether you are just starting or have been doing it for decades.
I don’t think that I can stress enough how important curiosity has been to my success. I am passionate about the work that I do. Being curious about what new thing I can learn is what makes me excited about opening my laptop to work each day. Curiosity is what helps me reshape my relationship with imposter syndrome. It draws me into the work and challenges me to learn more.
Sometimes my curiosity sends me down the path of how I can use a certain framework or technology better for my job. Other times I may just learn something new because it is interesting. For example, playing around with new features in React such as the Context API might help me in my work while learning a functional programming language such as Elm (this is a personal favorite) is interesting to me because it is different than what I use at work. Recently, I just finished a great book called The Imposter’s Handbook written by Rob Conery. The book is perfect for me because it is geared towards self-taught engineers and it goes over a lot of Computer Science topics that I missed by not going to college to be an engineer.
Whatever you do, feed your curiosity. Curiosity will help guide you throughout your journey as an engineer, whether you are just starting or have been doing it for decades. If you are curious and you are learning then hopefully you are having fun. I know I am having fun!
Putting it all together
The path that I took to become a software engineer has been an unique one. Most days I feel like I am still walking down the path because there is always something more to learn. These five lessons continue to help guide me through my journey.
- Remember that I am capable of doing the work
- Value the relationships that I have and seize the opportunities I am given
- Always work on improving my communication skills
- Knowing what I don’t know is a good thing
- Let my curiosity guide me to new adventures!
If you are looking to make a career change, your path will be different than mine. You may have some of the same experiences that I did and certainly exciting experiences that I have yet to encounter. The important thing to remember is to enjoy all of it.
Don’t let self-doubt, fear, or any other obstacle in your path stop your journey. It may seem like just a dream (it did for me), but it can be a reality if you put the work in. Working for Dictionary.com has been a wonderful experience for me. The engineers that I work with have supported me since I started and continue to challenge me to be better each day. I am glad that I took a chance on becoming an engineer, it has allowed me to do what I enjoy most; build things!
