How I Self-Taught Myself into a Career in Software Engineering and How You Can Too

Having weathered the journey of self-teaching myself into a career in software development, I want to offer to others who are traveling down their own path of learning, some high-level insight into the specific topics and learning resources that helped me, as well as offering some tips and pointers I picked up along the way with handling the dreaded imposter syndrome.

I originally pursued a liberal arts bachelor’s degree with the aspirations of becoming a history teacher. As you can probably imagine, I never became a teacher and I really couldn’t be happier about that. I’m glad I took the plunge into learning this material and I’m happy that I was able to learn it during my own time and on my own terms, without having to shell out even more money for any additional college education. With the right amount of determination, mental fortitude, and time, anyone thinking of seriously pursuing this goal can achieve it.

Topics to Learn

  1. Programming
  2. Algorithms and Data Structures
  3. Databases
  4. Networking
  5. Grappling with Imposter Syndrome

What Materials Are Best?

For learning materials, I strongly recommend textbooks as the preferred method for learning this sort of subject matter. The nice thing about a textbook is that you can reference it at your own pace and then write sample code to execute on your computer. Or, if you’re adventurous, you don’t even need a computer while you’re studying - just the textbook itself, a notebook, and a pencil. You can learn a lot this way through reading the material and taking notes. Once you’re done with a section, you can then reference your notes and begin reinforcing what you’ve learned at your computer, whether it’s continued research on a topic you’re still uncertain about or working with some of examples in your IDE or text editor.

After spending some time with your trusty textbooks, you’ll quickly find (or rediscover) that textbooks offer one of the better experiences as compared to other mediums, such as video, as it’s significantly easier and faster to absorb information by reading, than it is listening to someone speaking like with video courses. Of course there’s nothing wrong with reinforcing your studies with some video courses, but you’ll reward yourself a hundred times over by slogging it out with textbooks like you’re back in school – which you kind of are!


Now, before jumping down the rabbit hole that is JavaScript and whatever flavor of the month framework is currently popular — which is what a lot of self-taught and bootcamp students tend to start doing first — take a step back and ponder the following: there’s a sizable difference between learning a programming language and learning programming.

Learning a programming language will teach you the fundamentals about that particular language’s syntax and idioms and you’ll most likely be exposed to some design patterns and best practices for that language. Most modern programming languages will feature similar concepts and in most cases, if you learn one, you sort of learned them all. The first language will be the most expensive time investment and then each language will get exponentially easier to grasp as you move onto the next. Before you know it, you’ll be proficient in writing code. But, will you truly be programming?

Programming is rooted in computer science theory and is absolutely invaluable as a budding developer. Learning programming is generally language agnostic and written with pseudocode. The core concepts learned here will allow you to build much more efficient, composable, testable, and perhaps most importantly and maybe sometimes overlooked — human readable — software.

To help elaborate further on the importance of learning programming versus just learning a programming language, think of a fiction writer. Imagine if this writer just knew the English alphabet and could write sentences and formulate paragraphs — stringing many together to form some sort of story. But that this writer had no idea about plot, character development, literary devices, point of view, etc. Their story would not be well crafted and really not all that engaging nor interesting to read. This very idea applies to your programs! If you’re creating programs that are not well thought out and efficient at problem solving, will they be very effective?

I actually made this very same mistake when I started out years ago and in reality, probably a large portion of self-taught programmers make the same mistake, too. My recommendation is to learn both in tandem, but focusing twice the amount of time on learning the theories and foundations of programming itself. A text that I highly recommend is “Structure and Interpretation of Computer Programs”, by Harold Abelson, Gerald Sussman and Julie Sussman. They purposely use Lisp in this book for all examples and their reasoning is that the language doesn’t get in the way of things, being that it’s very easy to pick up and understand.

As for learning a programming language, there are countless choices available and it all depends upon the language you want to learn. What I can recommend is that you look for a text that happens to be the latest edition, as programming languages can add new features over time, and to also search for something geared toward a beginner within that language as opposed to a sort of recipe-style book for more intermediate to advanced programmers.

Algorithms and Data Structures

Equally as important as learning programming is learning fundamental algorithms and data structures. Too often self-taught programmers and developers skip this very critical subject matter entirely. Reasons for skipping it range from “Well, I just work on the front-end so I don’t really need to learn that stuff” to “I know how to use React, I should be fine”. Wrong! This thought process is a total fallacy and couldn’t be any more wrong.

Learning about Big O notation, stacks and queues, trees and graphs, and other areas of algorithms and data structures will make writing programs more succinct, significantly more performant, and, not to mention more fun and interesting. Another key reason for learning algorithms and data structures is that they’ll help you become a more effective problem solver. Do you need to become an expert with a Master’s level of understanding? No, you really just need the fundamentals, but learning as much as you can about a subject like this really couldn’t hurt.

For algorithms and data structures, “The Algorithm Design Manual” by Steven S. Skiena is a great text for this subject matter and is very approachable for self-taught software developers. The examples are written in pseudocode and this text covers topics such as algorithm analysis, data structures, sorting and searching, graph traversal, dynamic programming, and an entire section of algorithmic problems to solve. If you’re thinking of interviewing at one of the major tech companies, you’ll need to master the fundamentals of algorithms and data structures and you’ll also need to master the line of thinking and efficient problem solving that comes with having mastered the fundamentals in algorithms and data structures.


Many software engineers need to work with databases quite frequently, especially if you’re engineering for the web. Knowing how to work with these programs to perform create, read, update and destroy (or CRUD) style activities is very important and is something almost all web applications routinely rely upon. Even if you’re looking to primarily work on the front-end, it would still benefit your skillset and overall understanding to learn about how the data is stored and retrieved for the web application you’re involved with.

Currently, databases tend to adhere to either a SQL or NoSQL data structure. In short, SQL databases are table based with clearly defined schema, whereas NoSQL databases are document based, with looser schema - if any at all. SQL itself is the language in which to deal with the data within an SQL style database.

But, has it always been this way? As computer hardware continued to evolve over time, databases did too — in their design and data structures — as well as their software that manages them. “Readings in Database Systems” by Joseph M. Hellerstein and Michael Stonebraker contains a number of papers that outline the history of database storage and their designs over the last several decades. As someone who personally loves history and the study of history, this one is a fun read.


You’re learning to program. You’re learning about algorithms and data structures and you’re learning about storing, accessing, and modifying data in a database. So how does it all “connect together” over the web or even a local network? Or, on an even smaller scale, how do various services and servers communicate at all? What even is an HTTP request? What in the world is TCP/IP? The list of acronyms in the networking space is quite large, that much is certain. An excellent text that can offer a broad overview of computer networking concepts and ease some of the confusion is “Computer Networking: A Top-Down Approach” by James Kurose and Keith Ross.

Grappling with Imposter Syndrome

And while the above are excellent recommendations for the subject matter to learn to get you started in your journey of self-teaching your way into software engineering, there is another area that needs to be recognized. Especially as you continue your studies and begin applying what you’ve been learning, or as you begin your first professional job as a software engineer. At this stage, you might begin to notice this nagging voice in the back of your head. The general theme of what this voice keeps telling you is that you’re a fraud, a phony, and that no one will hire you or that if they did hire you, they’ll soon find you out, and fire you. Good grief, what an awful voice to have droning on and on!

Or, worse, that you actually don’t know anything at all about what you’ve been studying and that you’re just pretending all along and simply have a good memory followed by a whole lot of luck. Or, even worse than that, the voice may say no “actual software developers” will take you seriously, seeing right through your “lies”.

Wow, what is up with this? Well, this is called imposter syndrome and it can take a while to conquer, if at all. For me personally, it’s always there. I can’t get rid of it. Sometimes I can tune it out a lot, but other times it can come roaring back. And I experience it not with just programming and within my professinal career, but also with some hobbies too – how strange? I really do think this is something a lot of self-taught software developers struggle with. Or really just self-taught people in general, regardless of the career or hobby. But, in the context of this field, there are a few steps I use to best cope with it and hopefully these steps can help you too:

  1. It’s ok to say “I don’t know”
  2. Programming is suppose to be fun
  3. You’re probably not landing rockets on the moon
  4. Use imposter syndrome to your benefit

It’s ok to say “I don’t know”

Yes. It’s true. You’re not expected to know everything and looking at the docs for syntax or to remind yourself how something works should be encouraged by your professional peers as far as I’m concerned. Software developers very, very much, need to be the “read the manual” types. The measure twice, cut once, sort of people. This means you’re constantly striving to learn more, as often as you can. And if you’re constantly learning more, then you cannot possible know everything. Therefore by this logic alone, it’s then perfectly acceptable to say “I don’t know”!

Programming is suppose to be fun

Software developers can be a weird bunch. We obsess over details. We geek out over command line interfaces. We often have side projects that we pursue at odd hours, burning the midnight oil, of which might never see the light of day. But, we have fun doing these things. When that inner critic is raining on your parade, telling you you’re a fraud, just remind yourself about all the fun activities about this craft that give you pleasure and joy and you’ll soon snap right out of it.

You’re probably not landing rockets on the moon

You’re probably not writing the code that lands rockets on the moon. Or re-lands a rocket on a floating barge in the middle of the ocean. Or does anything with rockets and millions of dollars of equipment. And what I mean by this, is that if you find yourself at your day job totally overwhelmed and your imposter voice starts chiding you about how the company made a mistake hiring you and that you’re a complete fraud, know that what you’re doing is actually not that serious. Yes, it’s serious in a professional, business acumen sense, sure. But is it really that serious overall? Is writing a class that parses data from a database that serious? Is a web UI that lets a person click a button, that serious? No, not at all. Just remind yourself, when the pressure is high, that you’re not landing rockets on the moon and that you’re more than equipped to handle the challenges laid out before you.

Use imposter syndrome to your benefit

Believe it or not, you can actually redirect all of that negative imposter syndrome energy toward something that can yield a positive outcome. What I mean by this is, is that most people who cope with imposter syndrome tend to teeter on a sort of “type A personality” in some regards. Maybe not in all aspects of their lives. But most certainly do when it comes to that person’s professional career or a skill that they care deeply about. When imposter syndrome strikes, and its voice is picking apart every little thing that you’re working on or going to be working toward, take whatever that voice is saying and remove the negative barbs from it. Then, treat it as almost a list of things to possibly work on. Maybe that inner voice does have a shred of truth to it? Perhaps you’re not as well versed in relational databases as you’d want to be. Maybe you need to brush up on class inheritance after-all. You’re now no stranger to teaching yourself, so perhaps it’s a good opportunity to reinforce some subject matter?

This is all great, but how do I get a job?

At this stage, you’ve read a ton of books. You’ve written a few programs. You’ve coped with imposter syndrome. You even read this article! Great, now how the hell do I get a job, you might ask? Well, now the hard part has finally arrived: you take all of your skills you acquired and you apply, apply, apply, and apply.

Unfortunately, there isn’t an easy solution for this one. And interviewing is a strange concoction of art, skill, and luck. As someone who has been both and interviewer and an interviewee, be prepared for challenging live coding assignments with people watching you in real time — whether it’s in person, or at a whiteboard, or through some screen sharing app. Be prepared for take home assignments that will cut into your free-time that have little-to-no clear instructions or desired outcomes. And, definitely be prepared for all sorts of tough, “gotcha” style questions. You may fail, a lot. You might even get ghosted. You will probably get more rejections than you’d care to talk about.

But then, suddenly, you’ll hit. And when you hit, you’ll hit big and you’ll finally cash out of the job lottery and collect your winnings: a shiny new career as a software engineer with a very excellent salary, before you even know it.

The key takeaway here is you’re so close now to the finish line: don’t give up until you reach your goal.

Like what you've read?