To land a technical job, you should first complete a decent sized programming project to serve as tangible proof that you have the required skills. Unfortunately, this can be difficult and where great candidates often get stuck. Even after studying alone online or in a classroom environment, building your first programming project start to finish on your own can be daunting. It can feel like going from swimming in the shallow end with arm floaties to suddenly being dropped straight into the deep end with nothing but your swimsuit. It’s easy to find yourself drowning in a pool of programming tools, frameworks, databases, servers and options. This post will not offer any specific technical advice, but rather give you a framework for approaching the project along with some guidance and tips to keep you going until you’re swimming like a pro.
The first step to any project is figuring out what you want to build. Pick something that interests you. You are going to be spending a LOT of time working on your project, so make it something you find engaging. A good way to generate ideas for this is to think of some piece of software that you want but doesn't yet exist. Alternatively, you could think of something that exists but that you wish worked a little differently, or pick some piece of software that you use all the time and build your own version. It doesn’t need to be the most original idea ever, but it should be at least be interesting to you.
Making sure your project is something on which you will learn useful skills that can be applied to a job is key. You may be interested in building a video game in Unity, but if your goal is to get a job as a back-end software developer, those skills won't translate well. Building a game in Unity will help you learn Unity (and maybe some C#), but ultimately it won't help you become a better back-end developer. An employer will not see that project as proof that you’ll be able to contribute as a back-end dev. Identify the kind of job you want and what skills you think you need for that job. Try looking at job postings for open positions to get an idea of what skills are required if your are unsure.
The point of your project is to learn how to build something, get exposure to what professionals are doing and demonstrate that you can do the work.
Avoid picking something overly ambitious. Nobody expects a first programming project to disrupt an industry or be an amazing, original piece of new software. It is most important that it’s something that you can actually build. For example, a mobile app that automatically tracks all of a user’s food intake and gives feedback on the nutritional content of it would be AMAZING. But, the technology to automatically track food eaten without any user input just doesn't yet exist. A more realistic project would be to build an app where the user manually inputs their daily meals and then displays that food’s nutritional content. Make sure that you are trying to build something you’ll actually be able to complete. Don't worry if your project isn't super cool and fancy, that’s not the point. The point of your project is to learn how to build something, get exposure to what professionals are doing and demonstrate that you can do the work.
There are many different decisions to make when choosing which tools to use in building a project. These will vary depending on the needs of each project and your existing skillset. Still, there are some common sense advice to help you make an appropriate choice.
Try to pick something you already have some familiarity with. If you already know Java or Python, it wouldn’t be the best use of your time to go learn Ruby on Rails for your first project. Instead, pick a framework like Django (for Python) or Spring (for Java). You already have plenty to learn — no need to make it harder by having to learn an entirely new language.
Once you have done some research and picked something you are comfortable with, stick with it. You will learn about many competing frameworks or databases and how each one is so much better than its competitor. It will be tempting to try all the things. Don't. Click to tweet.
You have a lifetime to try them all. For your first project, it’s better to minimize the amount of new stuff you have to learn. If you spend all your time jumping around, it will be very difficult to make any progress.
Finally, when you do decide on what stack to use, set aside some time to learn it’s set of tools. Do a simple tutorial that takes you through the basics. Set up a dummy “Hello, World” app. You don’t have to spend months researching and reading every book on the subject, but take a little bit of time to familiarize yourself with the tools you will be using and how the pieces fit together before diving in head first.
Ok, you've picked an idea and a stack. Now you’re ready to start building! There will be a natural tendency to build your project feature by feature, but it’s more efficient to build it piece by piece (as exemplified in the Agile Process). This may sound like a distinction without a difference, but is actually the most important piece of advice here. To really explain it, we need an example.
Let’s say you are building a server side web app. Your first feature is user logins. It sounds pretty straightforward — basically every web app has this — how hard could it be? Your first step is to build a sign_in page where you can accept a username and password to login. While creating your sign_in page and adding two text fields on the screen for username and password, you realize that you actually need a page to create a new user first. There are submit buttons, form data to send, server side data to parse, passwords to encrypt and data that needs to be stored. This goes on and on, and you still haven't really made direct progress towards the original goal of signing in a user. Experienced engineers often have problems with this, it is an art, and one that will take years of practice to master. Here are some tips to help get you get a jump on it.
First, figure out which subtasks you absolutely need and which can be tabled to work on at a later date. For example, a login page also needs to have a way to create a new account in some way. You may not, however, need a place where users can edit their account and upload a nice photo. For your first project, remember YAGNI (You Ain't Gonna Need It). Professional programmers use this to help organize work on their own features when it becomes tempting to over engineer a solution or to guess at future requirements of the feature. Don't build things until you know you need them. It’s a simple way to keep your code simple and prevent stalling.
Second, when you’re working on something you know you do need, work towards the simplest implementation. There will be a thousand ways to complete your task, some more complete or better than others. It can be hard to proceed knowing there might be a better way to do things, but don't get stuck trying to build the best thing ever. In order to make progress, you just need to build something. Build the simplest thing you can that will still accomplish what you need. You can always come back and improve your app later, but for now, create your MVP (minimal viable product). This is a term startups use to talk about the simplest version of an application fit for release. When you don't have a lot of resources or money, it’s important to release your idea quickly so you can validate it. Create the simplest version of your application that you feel comfortable showing to potential employers.
Finally, remember to take a step back from your work. It is easy (and sometimes necessary) to get lost in the weeds, but it is also important to see the bigger picture. This means actually taking some time to plan out your work. You may have 4-5 features that you consider part of your MVP, but the list of subtasks to complete each feature is always going to grow and change. Try to take some time to write down the subtasks that you need to work on and check them off as you complete them. Keeping a running list of these things will help keep you on track with the larger project goal and help prevent the urge to drop your work (and context on the current problem) to add another feature. Instead, add the new problem to your running list and come back to it later.
Take all advice with a grain of salt. There are no hard and fast rules to follow, no guaranteed process templates — consider the above general guidelines. These are pieces of advice learned the hard way shared to lessen a bit of your struggle. It is still going to take hours of Googling, countless tutorials, and many many moments where you hit a brick wall and feel like you can’t proceed. But don't be intimidated. Take a break, sleep on the problem, and get back at it. Less smart and talented people than you have done this. Put in the hard work, time and perseverance, and you can do it too. It is not impossible even when it feels like it is.
By Eliot Piering
Software Engineer at LaunchCode