Several different friends have recently asked for advice about transitioning from their current career to a new one as a “coder,” “programmer,” “software developer” and/or “code monkey.” Here is what I would say to all of them.
Quick aside: I take the terms “coder,” “programmer”, “software developer,” and “software engineer” to mean roughly the same thing. I also acknowledge that not everyone will agree. From here on I’ll use the term “engineer” to be consistent.
There are a few core attributes that every really good engineer I have ever worked with has had. They might have been blessed with them naturally or they’ve developed them over time but they all have these qualities.
You can do it!
If you are anything like me software engineering may not feel natural. Other folks may be much better at this from experience or from being gifted but you can do it. Trust me. If I can get a job writing software for a living, so can you. The confident engineer says:
“I don’t know how I’m going to do this but I’m going to find a way.”
How easily do you give up on solving a problem?
If you can not stick with a problem long enough to find a solution or a work around you are not going to make it. Bugs will bother you for days, sometimes weeks and if are unable to muster the desire to keep hacking away at the them you will not survive. Software engineering is about solving problems. Seeing them through to completion is how you gain confidence and experience.
Interest vs Fear
Looking at a problem with wonder instead of fear makes a big difference in your day-to-day outlook as a software engineer. Fear restricts your thinking and bottles up your ability to innovate. Curiosity on the other hand can open your mind to solutions that otherwise may never have presented themselves. A curious engineer might say:
You will spend more time reading code than anything else as a software engineer and therefore you must hone this skill as quickly as you can. Read your code. Read other people’s code. Read your old code (😰). Read different kinds of code like JavaScript, Ruby, Swift, C#, Haskell or Go. Make an attempt to understand what code does and then why it does what it does. It is OK if you don’t understand everything right away.
Note: In programming there is a debugging technique called Rubber duck debugging. This is the practice of reading code out loud, line by line, to an imaginary rubber duck. This is helpful because explaining a problem to someone else can often reveal flaws in the solution.
I quickly realized very early in my career that if I couldn’t read the code I was working on and explain the problem I was having I simply didn’t understand what was going on. Developing techniques to understand code is an essential tool.
The benefits of being a software engineer are endless. Industries all across the world are clamoring for people who have these skills. The careers usually pay well. Senior level positions usually pay very, very well. (Interested in moving to San Francisco? 🙄 lulz). You can get a job in almost every major city and for some companies you may even be able to work from home.
That’s what I’m talkin’ about!!!
It will take confidence, persistence, curiousity and a willingness to read lots of code. Learning to be a software engineer is alot like eating a whale. How do you do it? One small piece at a time.