Advice I Wish I Knew When I First Started Software Development

A guide to help developers improve their learning and avoid burnout

A little over a month ago, I began working in my first full time position as a software developer. This past weekend I was sitting in bed thinking about the first time I ever touched a piece of code 2 years ago. I realized how much I have learned since then and I began to think about all the things I would tell myself if I could go back and give advice to the 22 year old me, discovering software development for the first time. This is what inspired me to write today. I decided to create a guide for people who were like me, just getting started in the world of software development or for people who are well into their careers and want to continue to improve. I have broken my advice up into 5 sections, each discussing a lesson or piece of advice that I have learned in my first couple years of development.

And for those interested in the path that I took to get here, I started out by teaching myself game development but accelerated my learning when I attended Flatiron School, a software engineering boot-camp. And while yes, I believe the boot-camp was worth the investment for my learning style, it is not for everyone. Also, the advice I share in this article applies to anyone who is trying to learn no matter what path you take or how far along you are in your career. With that said, let’s stop talking about my journey, so I can hopefully help you on yours.

1.Learn By Building

One of the most important lessons I have learned over my first two years developing, is that programming is just as much of a physical activity as it is a mental activity. In other words, the best way to learn is by building applications and solving problems along the way.

Experience gives you the knowledge so that if someone were to ask you “how would I use *insert whatever you are learning* to solve *some problem* ?” You not only could answer by telling them where to start, but you also could talk about the challenges you ran into and explain what did and did not work for you.

Learning to develop is not like studying for an exam or test, it is much more like practicing a sport. For example, in many sports you can research ways to improve your form, study a playbook, and learn the intricacies of the sport as much as you want, but it will only get you so far as a player. At some point in order to become the best player you can, you have to actually practice and play. Development is very similar, the best learning comes from experience. The process of building out projects is how you will go from having a surface level understanding as a beginner, to having a much deeper understanding, and on your way to being an expert. So, while you are studying and taking notes, make sure you are also getting your reps in.

Photo by Jexo on Unsplash

2. Do Not Worry About Making the Perfect Project, Just Get Started

Let’s say you’re at the point where you have spent some time learning the basics of a new programming language and are ready to solve some problems and start a project. Great, but now what project do you build? If you were to ask me, I’d tell you “pretty much anything”. In fact, whatever you come up with first. Or better yet, what you would have the most fun building. As long as you think you can apply what you just learned to the project idea, then the project is a good one to do. The key is to just get started.

I cannot tell you how many times I have fallen into the trap of not starting anything by trying to find the best thing to do, putting me in somewhat of a ‘analysis paralysis’. And it’s not just me. The majority of developers that I have spoken to have had times where they found themselves stuck, not making any progress because they do not think their project ideas are good enough.

But why does this happen? Well honestly it’s one of two things. We either compare ourselves to others or it’s to meet our own expectations, goals, and ambitions. We think things like “I need to make a project that is impressive enough to get me my dream job” or “I want a project that’s as good as *so and so*’s project” or even “I want to create something that has not been done before”.

Now you’re probably thinking, what’s wrong with being goal oriented or following your ambitions? Absolutely nothing, in fact if you have your project idea already planned out or if you are learning to code in order to execute on a business idea, then you should 100% go for it. It only becomes a problem when you start to delay your learning for the sake of finding the right project. It is not worth it. It is much better to execute on a ‘simple project’ and be passionate about it, than to struggle through trying to create an ‘complex project’ that you have no desire to create. There’s a couple of reasons for this.

First of which is that, the ‘simple project’ may end up being more impressive anyway. Something that I had to learn pretty quickly is that it is often more impressive to people if you can talk about your project in detail, with passion, and enthusiasm (yes, even if it is something like a simple tic tac toe game) than it is to struggle through creating something complicated that you do not enjoy building. Even if the project does not necessarily sound impressive on the surface, expressing your passion for a project goes a long way and it is not something you can fake.

Second, is to Avoid burn out. Burn out is very common in development and most of the time it occurs when someone is working on things that they do not enjoy building. When it comes to programming at a job, working on things you do not enjoy working on can sometimes be unavoidable. However, that should give you even more reason to make your personal projects things that you are passionate about.

To make a long story, short, the majority of the most impressive projects I have seen have come from simple ideas at surface level that evolve into a beautifully built application. This happens because the people who created it were passionate and enjoyed what they were creating. So do not stress over finding the “right” project, just get started on something you like.

3. Do Not Try to Learn Everything, You Can’t

The title of this section may sound pessimistic but really, it should encourage you. The reason you should not try learn to everything has nothing to do with you as an individual, it is because there are simply too many things to learn. In today’s tech world, there are thousands of different technologies and frameworks that we as developers can learn and get into, but no one person can learn them all.

A pretty good example of this is when I first started learning to program, I thought it was a great idea to take a python course, a C++ course, a game development course using C#, and a Java course all at the same time. As many of you are probably thinking right now, and as I quickly found out, programming languages do not differ all that much conceptually and the fundamentals have a lot of overlap, especially for introductory courses. In my defense, I did not know better at the time, but looking back, it seems pretty silly.

The point is, on top of the risk of spreading yourself thin trying to learn too much at once, you will actually learn a lot more by diving deep into one or two technologies at a time. In fact, there are many people who spend their entire careers working with only a handful of different technologies and are still learning new things about them every day.

4. Tech Stack Does Not Matter (kind of)

After reading the last section, you may be asking yourself how do you know which technology or technologies to choose. Well, similar to picking a project, find a tech stack that interests you. Or if you have a company/companies you want to work for, look at job postings and see what technologies they use and learn those. No matter what you choose, becoming a good developer comes down to learning and building something using what you have learned.

Nearly every type of development you can find 5 different frameworks & tech stacks that can accomplish very similar results. For instance, let’s say you want to learn frontend web development. You can choose to use just vanilla JavaScript or you can choose from a variety of JavaScript frameworks/libraries. These include React, Angular, Vue, and Svelte, just to name a few. And while they all have their differences, they have similar capabilities and serve the same purpose.

Or if you want to learn machine learning. You can learn Tensorflow with your choice of JavaScript, Python, C, or Swift. Or you could choose to focus on Python and utilize Numpy and Theano, or even learn the Spark ML model, along with Scala or Java.

Or let’s say you want to be a game developer, you have a large selection of game engines you can choose to learn. For instance, Unity, Unreal, Game Maker Studio, Godot, etc. are all good options and while they do vary in capabilities, you can become a very good, hirable, game developer using any of them. The point is you have a lot of choices and realistically if you’re learning for career purposes, choose technologies that make sense for you.

Now the reason you see ‘kind of’ next to this section is similar to the caveat about picking a project. Tech stack does matter if you are building a large scale application for a company, where efficiency, cost, scalability, etc. all matter. For 99% of people developing for their portfolio, experience, or for fun, then these details often do not matter.

5. Code Daily

When I first decided I wanted to switch careers into development and someone would say something like “you need to code everyday”, it seemed quite intimidating. Especially because I had a different job at the time that had absolutely nothing to do with coding. I remember thinking “When would I find the time?”. Little did I know I was just thinking about it the wrong way.

I used to think of it as being a chore, as another thing I had to get done, as something that I had to spend hours doing to get anything out of it. In reality, the reason people say you should code everyday is because it is a lot more maintainable if coding becomes a part of your day versus it being a task to do when you have time.

The key is to start small and be consistent. Not only is it more maintainable, you’ll learn more, it will be much more fun, and you’ll be way less likely to experience burnout. Just commit to something like 15 minutes to 1 hour a day of very intentional, focused time to code.

Just make sure that you are hitting atleast the minimum time that you commited yourself to and after a few weeks to a month, you will notice, that just like brushing your teeth, it is just an other part of your day. And now you’re probably thinking, there is no way that you will make big improvements with 15 minutes a day. I’d say, you’d be surprised. You also are going to find that many days you are going to go beyond what you committed to, because getting started is often the hardest part. But you should also remember to be equally as proud on the other days, where you are only hitting the minimum that you commited to. In fact, it is the days where you are really feeling out of it and not interested in coding but you still go out and hit your 15 minutes, that keep you in it for the long run.

I could continue to go on and on about why doing a little bit every day is better and more sustainable but that may be a topic for an other time. For now, I will just recommend James Clear’s book, Atomic Habits, as it talks about the topic in great detail, as well as share a quote from the book that sums it up best.

Changes that seem small and unimportant at first will compound into remarkable results if you’re willing to stick with them for years.

- James Clear

Software Developer | Fitness | Sports Fan | Gamer