The way programmers program programs are not always obvious when first starting out. When I was young and would see special effects in movies and TV shows, I would ask my dad “How do they make special effects?” And he would respond “With computers”.
Despite being the most generic answer you could possibly give, I could barely pronounce the word breakfast at the time so who was I to question such a reasonable and well thought out explanation.
And so with a solid foundation I went on to attempt to program several times throughout my middle and high school career. You’d think that after trying and failing hopelessly to learn something new several times over the course of years I’d get the point and try something else.
Lucky for, well, somebody probably, that part of my brain that’s supposed to say “This is bad for your health and you need to stop” burnt out a long time ago. So now I get to share with you all how to think like a software engineer.
There are a few things that I’ve found to be universal when learning how to write software:
All of the languages listed here can be used to accomplish any of the listed objectives. I grouped them as such because these languages are most commonly used to accomplish these objectives and thus have a thriving and supportive community of users built around them which will make the process so much easier for you.
You’ll find that despite programming having a reputation of being a very solitary occupation, it is in fact very collaborative and you will come to rely on those around you for support and teamwork. For everyone else though that just wants to learn how to program, the tout de suite explanation for which language is the best to learn is the one that you can find a tutorial for.
While a language’s documentation will contain the knowledge you seek, it is often buried under mountains of other irrelevant information which will take practice to learn how to efficiently sift through. Your goal at this point is to do something – anything. Establishing a habit of technical thinking is more important right now than getting everything 100% correct. Do not get caught up trying to do something the best way.
Most projects beginners will work on are so general they can be accomplished with just about any language. There are two main reasons why this seems to be the case. The first is that at some point some person somewhere on the internet was too stubborn to learn the language that was already designed to accomplish the task. The other, probably more common reason, is the general “because I can” mentality.
Many programs software engineers make are a result of the maker attitude. These programs aren’t built for any particular reason other than to exist. It exists because someone wanted it to and for no ulterior reason.
The programmers proceeded to bodge a solution based on the language that they already knew (shout out to Tom Scott). As a result, it’s a rare case when there is only a single programming language that can accomplish any individual goal. This brings us to our second point.
I’ll admit it’s kind of a chicken and egg situation. You don’t know enough about programming at this point to start a project and you don’t have any projects you’re working on because you don’t know what to do because you don’t know how to program.
At this point in your journey it’s common to get stuck in what’s known as Tutorial Hell. You’ll watch tutorial after tutorial for programming language after programming language; the rational being that before you start to program you have to know how to program in any given language. While this might make sense with something like using a power tool, with programming this simply isn’t true. You’ll never know everything a given language has to offer and you will always be learning. It is an evolutionary process rather than a singular moment where you just know how to program.
Your best chance to learn how to program is to pick an idea that sounds cool, and yes, without knowing how to program at all, figure out how to make it. It may sound daunting and out of order, but I can assure you this is the best way to learn.
When you first start out, it will be difficult. Every other keystroke you’ll be trying to google how to accomplish even the simplest of tasks. Keyword here being “trying”. Often times you won’t even know the name of what you’re trying to accomplish so you’ll be stuck with googling random phrases in a vain attempt to describe what you’re looking for. Over time you’ll learn that just like a hammer is a tool for a carpenter, search engines are a tool for software engineers. Just like a carpenter you too will learn the best way to use your tool. You’ll eventually start to remember solutions to problems instead of having to look them up every single time. It gets easier, I promise, just stick with it.
While every program is unique in its own design and application, the solutions to most programs can often be discovered by a series of common strategies. The first and probably the most significant of which is to solve problems and then write the code. This is a strategy that I still use to this day years later to solve complex problems.
For example, if you want to create your own tic-tac-toe program, it’s much easier to write down the steps to accomplish such a thing on a physical piece of paper in normal human words and only then try to translate the steps into a functioning program. Doing it this way stops you from being bogged down with all sorts of programming errors when all you want to do is solve your problem and build your project.
You may be thinking, “Wait, so I have to write down everything I do twice? That seems… excessive. Why not just solve the problem in my head or solve it as I go along?” Fear not, you can do this and the programming police aren’t going to come and arrest you. Over time as you become a better problem solver you will need to do this less and less. This is mainly an effective strategy for solving problems which are complicated or which you haven’t come across before – which as a beginner is nearly everything .
When you come across a problem you don’t know how to solve just break it down until you have a list of problems that you do know how to solve. This is a process you will become very familiar with and it applies across languages, applications, and skill levels. Just like how you might not know how to make a rocket, but you know how to use a screwdriver to screw metal plates together, you might not know how to build your own website but you do know how to open up notepad and watch a YouTube video.
This one is a little more subjective than the others, but I wanted to include it in here because it can be very helpful in between the grind of learning to take a moment to be amazed at what other people have created. While I was over here trying to figure out why my program won’t run for the fifth time in the last 20 minutes just to find out I had unintentionally uninstalled the programming language, I would look online in awe and amazement at what others were creating.
It inspired me. It served as a reminder of why I was putting myself through this mind numbing and sometimes infuriating process. It gave me a goal, something to work towards. If I wanted even a chance at a future where I could be the one to build artificial intelligence, virtual worlds or the next Google I knew I had to put in the work.
I hope this article helps give you a mental kickstart on how to approach learning to write software. With any luck, one day you will become the teacher to others, giving back to the community just as they did for you, thereby inspiring the next generation of software engineers.