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.”

There is no fast track to gaining experience in Software Development

It’s a common mistake in our industry that people when first starting out believe they can spend [insert any short number of days here, like 30, 60, 100] days learning a programming language and then they’ll be an expert, easily get a job and hit the ground running. The reality is that software development is not something that you can learn over night, it take time, and it takes practice (with regular feedback).

You can learn the basics of programming and a specific language in a few weeks, but to take those basics and use that knowledge to build anything larger than a simple app or contribute within a development team, you’ll rapidly discover how much you actually don’t know.

A career in software development is a continual learning process. As you work with a specific toolset in a specific functional area, you’ll continually come across new things that you haven’t seen before, you’ll see what works and what doesn’t work. You’ll gain experience as you go and become more comfortable applying your skills and experience to solve problems you’ve seen before, and also become more comfortable solving new problems as what you’ve seen before often helps understand a new problem and find an appropriate solution quicker.

When you start a new project or a new job, you’ll often find this whole process repeats, especially if you’re starting with a new framework or toolset that you haven’t used before. And this repeats throughout your career.

It takes time to gain experience, and unfortunately there is no quick or easy shortcut other than hands-on experience, practice, and continual learning.