Building personal projects to grow your software development skills

When you are first starting out to learn a programming language and software development, it’s easy to get stuck in a rut with tutorials and watching videos etc. While it’s essential that you learn the basic constructs of any programming language, the real learning comes from trying it out and actually building something.

What should you build? This is a common question online, you often see new devs asking ‘what are some good ideas for building a personal project?’. It doesn’t matter what it is or what it does, just build something. As you build an app (e.g. a web app with a backend db), you’ll run into areas that you don’t know how to do yet, so use that as a jumping off point to grow skills in that area. Rinse and repeat.

Starting out you’ll find it will be slow going because there’s too many things you haven’t had to do yet (how do you package and deploy your app, if you need to deploy your app to a server, how do you install and configure the server, or how do you deploy to the cloud?), but you’ll work it out and grow your skills in the process.

As you get more experienced, you can pick projects to work with a specific skill or technology area to grow skills in that area, for example to grow skills working with a specific nosql database or anything new tech that you want to gain some experience with.

In the process of actually building something, you’ll find you’ll learn far more that just watching an online tutorial. Try it and see!

Debugging is a key skill – spend time learning how to debug

All too often I see new developer focusing on learning how to write code, but not spending as much time learning how to debug code. Knowing approaches to help you find why code is not working is just as important as knowing how to write the code in the first place.

There a too many questions posted online that look like this:

“I’ve written this code but it’s not working and I don’t know why”

My first question is always “have you stepped through the code to understand what the code is doing?”. Many of these types of question and issues can easily be resolved just by using a debugger, stepping through the code and validating that each step does what you expect. As you are learning development skills, a lot of issues in code are from assuming the code is doing one thing but the way you’ve implemented it you have a subtle difference somewhere where you didn’t initialize something, you referred to the wrong variable, or the logic in an if statement is incorrect. Stepping through the code will help you find the point where everything’s working up to the point where there’s an issue.

Spend time learning how to use your debugger in your IDE of choice. There are of course many other complementary techniques to debugging code, like logging and trace statement, unit testing etc, but don’t overlook the usefulness of your debugger.

[Top tip series: rather than spending time writing lengthy articles over several days I’m going to try and post shorter, hopefully useful tips more frequently]

Fix the problems you have, not what you don’t have

It’s easy for new developers to get caught up spending time on things that really don’t matter. Spending time trying to work out whether approach A is using more or less memory than approach B is a common distraction, and usually the answer to whether it does or not is irrelevant (why would you be concerned if memory for a variable is stored on the heap or the stack, and try to do do ‘weird things’ to reduce memory usage).

It’s important to know if you have a problem or not, and then spend time investigating and resolving that specific problem. Don’t spend time worrying about things that are not important or irrelevant. Knowing what is important often comes with experience, but if you’re unsure then ask one of your more experienced collegues.

[Top tip series: rather than spending time writing lengthy articles over several days I’m going to try and post shorter, hopefully useful tips more frequently]

Think before you code

‘Big upfront design’ has fallen out of favor in recent years, replaced by more Agile development approaches. However, before you start coding you have to have some idea of what it is you’re building.

Paraphrasing an online discussion, this is an all too true example experienced by many new developers when first starting out:

New Dev: I don’t know where to start with this app. It’s too big to comprehend and I just don’t know how to get started

Experienced Dev: Well, what is your approach for structuring the app, have you though about how to break the app down into different pages and what each page does?

New Dev: No, I haven’t thought about that yet, I just started coding and got stuck.

Think before you code. Even if it’s some rough notes of the key features of the app, or some sketches of the different pages and what the navigation looks like between the pages, any time spent thinking about what the app does, how it should work, and how it should be structured will always make the job of actually building the app easier.

Remember, the hard part of building any app is working out what it should do and how you should build it. The actual act of writing code is always the easiest part (or should be).

[Top tip series: rather than spending time writing lengthy articles over several days I’m going to try and post shorter, hopefully useful tips more frequently]