How to Become a Software Engineer Without a CS Degree: Essential Strategies for Success

Here is how I became a software engineer without a computer science degree. Let me be real with you: coding was hard. I wasted so much time fixing missing semicolons, mismatched brackets, and misspelled variables. Even when the code was compiled, it would not work as expected, and I would spend hours staring at the screen and questioning my life choices. But over time, I picked up some strategies that made coding click for me, and I'm going to share these strategies with you today.

Don’t Try To Know Everything

The first thing I learned was that as a programmer, you don't need to know everything. When I began my first programming job, I was unfamiliar with Linux commands. When I joined Amazon, I did not fully understand G. At Amazon, my first project was in Python, and I had never written a single line of code in Python. Later, when I joined Google, I could not program in C++, but most of my work was in C++. The point I'm trying to make is that you don't need to know everything; you just need to know where to find it when you need it. But when I was a beginner, I would try to do these 30-40 hour boot camps to learn a programming language, thinking that I was going to learn everything. In reality, you cannot learn everything there is to learn. So, do not wait until you have the right skills to start your project; your project will teach you the skills. Do not wait until you have the confidence to do what you want; the confidence will come when you start doing it.

Focus and Avoid Overwhelm

Well, a successful warrior is an average man with laser-like focus. The same is true for a programmer, but it's really hard for a beginner to stay focused. That's because a programmer has more choices than a buffet at an Indian wedding. First, they have to choose a programming language. After that, they need to pick a course to learn that language. If they want to learn front-end development, they have all these choices, and for back-end developers, there is a whole other set of options. The more options available to a person, the longer it takes to decide which option is best. This is also called Hick's Law. 

As a beginner, it can be tempting to learn a little bit about many different technologies. After all, there are so many exciting areas to explore. While broad exposure is good, it's important for beginners to pick one technology stack to focus on initially. Mastery takes time and repetition, so go deep and not wide. Programming concepts take time to fully click. By focusing on one technology, you can iterate on the fundamentals again and again until they become second nature. Usually, you need to know one technology stack really well to get hired. Breadth is great, but you'll be evaluated on how well you know a specific technology that the job requires.

Develop Problem-Solving Skills

Next, the lesson was not to just focus on coding ability, but also on developing a problem-solving mindset. You see, coding is ultimately about solving problems, big and small. But the issues we solve as developers don't come prepackaged as coding problems like you see on LeetCode or in coding interviews. They come disguised as open-ended product requirements, refactoring challenges, or performance bottlenecks. Learning to deconstruct these messy real-world issues into solvable chunks is a key skill that you need to build.

Example of Problem Solving

Let's say there are thousands of users on the internet browsing for a dilution ratio calculator for car detailing products. They are wondering how much water should they add to the car detailing products based on the known ratio of detailing products and water. For this purpose, you can make a dilution ratio calculator in HTML, CSS, JS, or whatever language you prefer. But we recommend Python over HTML, CSS, and JS because you will need to write fewer lines of code. It was just one example: there are hundreds and thousands of problems that need to be solved.

Techniques for Better Problem Solving

Let me tell you two techniques that helped me become better at problem-solving. The first is the Five Whys analysis. This technique was created at Toyota as a way to identify underlying reasons behind manufacturing defects. Here is how it works: when you encounter a problem, you ask "why" five times, one after the other. Each answer forms the basis of the next "why." For example, let's say your code is running slower than expected. Why is that happening? Because it's taking a long time to process a large data set. But why? Because I'm using two nested loops to search for a specific value. And why is that? Because I thought that nested loops were the easiest way to solve the problem. Why is that? Because I do not know more efficient search algorithms. But why? Because I've not taken the time to study data structures and algorithms. By the time you get to the fifth "why," you have reached the core issue.

The second technique I use is the separation of concerns. The main idea behind this is to break a complex problem down into smaller, manageable parts. For example, let's say you are building a web app with user authentication. You can break this problem down into multiple tasks, like building a user interface for login and registration, database management for storing user credentials, and authentication logic for verifying user identity. This makes the problem easier to process without getting overwhelmed. Building strong problem-solving skills will also help you in coding interviews. In coding interviews, they will ask you questions based on data structures and algorithms. These questions are designed to test your logical thinking and problem-solving. 

Stop Obsessing Over Syntax

The next thing you need to do is to stop obsessing over the syntax. As I mentioned at the beginning of this article, I would constantly get frustrated by silly syntax errors. I would spend hours just trying to get my code to run without any errors. But then I realized that obsessing over the syntax is pointless. Syntax is just the grammar of the language; it's important, but not the core of coding. As we discussed, the core is problem-solving — breaking down a complex problem into simple steps that even a computer can understand. That's why I started practicing coding with pseudocode first. Pseudocode lets you mock out your solution in plain English before trying to write proper code syntax. It forces you to truly understand the logic of your solution upfront. Once I had that down, the actual coding became much easier because I just had to translate my logic into whatever language I was using.

Here is an example of pseudocode for the fizz fizz game:

• Pascal style:
  

procedure fizzbuzz;
  for i := 1 to 100 do
    print_number := true;
    if i is divisible by 3 then begin
      print "Fizz";
      print_number := false;
    end;
    if i is divisible by 5 then begin
      print "Buzz";
      print_number := false;
    end;
    if print_number, print i;
    print a newline;
  end

• C style:

fizzbuzz() {
  for (i = 1; i <= 100; i++) {
    print_number = true;
    if (i is divisible by 3) {
      print "Fizz";
      print_number = false;
    }
    if (i is divisible by 5) {
      print "Buzz";
      print_number = false;
    }
    if (print_number) print i;
    print a newline;
  }
}

• Python style:

def fizzbuzz():
  for i in range(1,101): 
    print_number = true
    if i is divisible by 3: 
      print "Fizz"
      print_number = false
    if i is divisible by 5:
      print "Buzz"
      print_number = false
    if print_number: print i
    print a newline

Write Code for Humans, Not Computers

Another thing I wish I had learned early was to write code for humans, not computers. A study done by Chajang University found that developers spend 58% of their time just trying to understand the code they are working with. As beginners, we tend to write code that works in a way that only makes sense to us. But effective code needs to be understandable by any developer who looks at it, including your future self. I cannot tell you how many times I came back to my code from a week ago and could not understand it myself. So, writing clean, readable code with proper variable naming, code formatting, and comments can massively boost your productivity as a developer. It's a skill I worked very hard to build by studying coding best practices and getting code reviews. Trust me when I say this: your future self will thank you for writing readable code.

Master Debugging Techniques

In talking about understanding code, the next thing that made my life easier was learning debugging. I can't tell you how many hours I wasted just randomly tweaking code, compiling, running, and tweaking again in the hopes that it would magically work. I thought that was the only way to do it. But then I read this article by Devon H. O'Dell that talked about how developers spent somewhere between 35% to 50% of their time debugging. That's over a third of their time. So, I decided to get serious about learning debugging. 

I learned how to use a debugger, adding log statements systematically, and recreating issues in smaller isolated cases. Learning and applying a proper debugging process saved me a lot of time and headaches. Most code editors have built-in debugging functionality. In certain cases, you can also use a third-party extension like ReSharper. To learn more about debugging, check out Google's troubleshooting and debugging techniques course on Coursera. Enroll for free!

Focus on the Little Things

And this brings me to the most important lesson. Back in the 1980s, American Airlines was looking for ways to cut costs and improve its profit margin. Bob Crandall, who was the head of American Airlines at the time, decided to take a closer look at the airline's food service. He noticed that the salads being served on the flight included a garnish of three olives per salad. Bob did some quick math and figured out that if they removed just one olive from each salad, they could save a substantial amount of money. Keep in mind that American Airlines was serving thousands of meals every day, so even though one olive might not seem like much, the numbers added up fast. American Airlines saved around $40,000 per year in today's dollars by doing this (Ref). The lesson here is that sometimes the biggest improvements come from paying attention to the little things.

Incremental Improvements

In his book Atomic Habits, James Clear talks about the power of making small, incremental changes in life (ref). The idea is that tiny habits, when compounded over time, can lead to remarkable results. He shows that just a 1% improvement every day over one year can make you 38 times better. The key to making these improvements is starting small. So, if you want to get in shape, start by doing one push-up per day. If you want to read more, start by reading just one page every night. And if you want to learn programming, start by doing just two exercises per day. Over time, these small improvements will compound. Two exercises will become 20, and 20 exercises will become one project, and so on. Whatever you do, you cannot have anything worth having without struggle. And if you're struggling to learn programming, you are on the right track.