Software development is about building solutions to problems, not memorizing language syntax

All too often I see questions online from new developers about how they can progress from ‘tutorial hell’ or feeling that they’re not making any progress beyond a certain point. Programming languages are just tools. A programming language to a developer is the same as a hammer to a carpenter. You don’t learn how to use a hammer, you learn how to frame a house.

Beyond the few hours of learning basic concepts and syntax you should move straight to actually writing something, start with ‘Hello World’ and go from there. As you continue from that initial starting point, every new thing you read/watch/listen to should be followed by additional hours of putting it into practice. The real learning is when you write some code and run into problems and have to work out what the issue is and how to get beyond that point.

Here’s a useful insight that eventually you will discover: as you progress through your career and develop more experience, you’ll soon find out that the process of developing software is about trying something out, finding it doesn’t work, then working out how to make it work. There seems to be a misconception that becoming a better developer means you will be able magically flow code from your finger tips, but that’s not how it works. It’s an incremental process, you write some code, it doesn’t work, you work out how to fix it and you continue. The sooner you realize this and accept it I thinks to avoid some of the frustration from believing that being ‘better’ means something different.

Does a great idea matter for a personal portfolio project to demonstrate your software development experience?

New developers starting out with little to no hands on/real world experience are often encouraged to build a portfolio of personal projects that they can share with a prospective new employer. It’s a great idea too, as a technical interviewer if I’m interviewing a new developer with no experience, an example project that they share online can give a useful insight into how they build a solution to a problem, and demonstrates that they’ve at least had some hands-on experience, even if it is with a personal project.

A question that is always asked in online new developer communities, is ‘can anyone recommend some good ideas for a personal portfolio project?’. This is missing the point and the purpose of a personal project. It’s not to show you have a good idea for a project, it’s to show you can develop code in a professional way that would be comparable to other developers on a team you are applying to join.

It’s really doesn’t matter what the project is or what it does. Build anything that can demonstrate you can write code that’s easy to read, is well structured, is not overly complex, and has good unit tests. It doesn’t matter what it is. As a technical interviewer if you show me a link to a portfolio (Github or anywhere else), I’m going to quickly browse the code to get an idea if you can write code that would be acceptable to my team (meaning, meeting the above criteria).

There seems to be a misunderstanding with some new devs that if you have an awesome idea for a portfolio project that will impress an interviewer, but it really does not matter what it is or what it does. Focus on developing clean code with good unit tests and that will be far more impressive to your interviewer than the project itself.

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!

Write code for humans first, computers second

When first learning to develop software, it’s natural to focus on getting your code to work as your first priority. As development is an incremental process, between multiple changes and attempts to get your code working, it’s natural that your first working version of your code is probably, to put it bluntly, a mess.

As you progress in your career, you realize the importance of developing code that is easy to read and understand, because at the end of the day, any software developed or maintained by a team has to be read and understood by other developers, not just the original developer. If no-one else on your team and understand your code then it’s unmaintainable and that poses a long term risk; if it breaks who is going to be able to fix it?

I commonly see posts online by new developers who are first starting out questioning the point and importance of spending time to refactor code, ensuring code is clear and readable, in essence, all attributes of maintainable code. The first time you come across code that you struggle to understand and you’re faced with making updates or fixing an issue, you’ll quickly realize the importance of developing code that is easy for other humans to understand.

This is not a new concept, it’s summarized clearly by the famous quote from Donald Knuth:

“Programs are meant to be read by humans and only incidentally for computers to execute.”