Photo by Markus SpiskeUnsplash

Why should you build projects in the first place

You may be a fresh grad out of college, or just finished a coding Bootcamp, or you have been developing software for a decent number of years. Irrespective of the stage you are in, there is always a need to showcase your skill, your ability, and your thought process to the world outside. You need to be heard, and your work needs to be seen.

Why? Job/Consulting opportunities, Networking, Portraying thought leadership, it may even help you to start a company, pair up with good cofounders, give back to the tech community, fine-tuning your skills, the advantages are way too many.

There are several ways to show the world that you are a good developer, a few of which are:

1. Write solid technical blogs

2. Contribute to open-source projects

3. Help fellow developers in Stack Overflow type places by answering questions

4. Open source a project that you may be working on

5. Depending on your tech stack, join that community, and share your expertise

6. Participate in Hackathons

7. Speak in meet-ups

8. Building a portfolio of projects

My focus for this article will be the last one. We would have heard about building portfolios many a time.

As a developer, we may have these questions on our minds: where do I start, how exactly should I navigate it, what if I do not have any ideas on top of my head, will it have to be unique, should it be complex, there are already off the shelf solutions, what is the point of building it, and so on.

Fair set of questions. On a trial-and-error basis, I came up with a mental model that helped me build projects. It is a simple 5 step process.

1. Come up with use cases

2. Build the core

3. Deploy your solution in the cloud

4. Socialize with the dev community & end users

5. Add more features, and repeat Steps 3 & 4

Let's look at each step in detail.

🙋‍♀️ Step 1 - Coming up with use cases is the starting point. How do you do that, rather how do you develop the skill of identifying use cases?

• Have a problem-seeker mindset - Look around for problems, observe where you are spending time unnecessarily, and see if there is a pattern with many people too. Spend time to understand where you struggle, and where your colleagues or friends struggle. Try and see if there is a common thread between problems. That becomes a starting point.

  Hypothetical Problem Scenario: As a developer, you may read a lot of articles on the internet from your laptop, from your phone, subscribe to multiple newsletters, and listen to a lot of podcasts. Over some time, you may not remember where you read what. If you'd want to revisit the same article, it may be a humongous task. You may try to recollect about a particular feature that someone spoke on some podcast, you may not know which one.

  Probable Solution: Build a simple webapp where you can bookmark a url, add a category, a sub-category, your personal quick notes, date you added it. You can have a search feature that aids in finding a particular keyword, author, speaker, etc., You can delete a detail as you may have moved away from that tech. You can build a mobile app or a progressive web app to synch it with multiple devices.

• Develop empathy - This may seem a bit counterintuitive. But it is a very useful characteristic that one may want to cultivate, not only to build projects but to be a good human being. When we develop empathy, we tend to see what causes difficulties for other people, and what can be done to make things around us better. How does it benefit you as a developer? You start to build solutions that solve a pain point for someone around you, you have the requirement right in front of you.

  • Hypothetical Problem Scenario: If you have the experience of moving to a new city, then you would have initially struggled to figure out what's available where, whom to reach out to, where to find few specialty items, where are the parks around, where to go for a walk, how to meet people and so on.

    Probable Solution: Build a locality wikipedia with all possible details. It may help a lot of people. You need to be creative in terms of how you categorize and aggregate information. You can bring in a lot of developer skills in making it user-friendly.

• Think of personal needs - What task do you find monotonous, what task do you find boring, but you have no choice of not doing it? See if you can automate such tasks.

  • Hypothetical Problem Scenario: This may be a bit hypothetical, but still it's a common conversation that we hear in many households. "What do I make for dinner, what do I make for lunch?". Many a time we may be out of ideas, may not have the patience or find it boring to decide on what to cook.

    Probable Solution: Take a picture of what vegetables/ingredients you have and let a web app or a mobile app comprehend what's in there, and suggest recipes using those. It may be an opportunity to learn computer vision, machine learning, and web scraping to name a few.

• Check with family and friends - Observe people closer to you. Probably they are doing a few things manually which can be made easier if there is software for that. Volunteer to understand how they perform a certain task, pitch in to see if an app will be of help.

  Hypothetical Problem Scenario: You may be learning music, dance, and instruments. Your friends or someone in your family may be tutoring children on subjects. Such teachers maintain track of the number of classes a student attends in a physical notebook or a spreadsheet at the most.

  Probable solution: You can build a student management system that captures details about students, classes attended, fees cycle, sending reminders, providing proactive notification, and more.

🎨 Step 2 - Building the core is the next. Once you decide on what use case you plan to solve, your next task should be to be able to understand what's the meat of the solution, and what's ancillary. Here are a few tricks to master that:

• Decide on your tech stack. Do you want to master what you already know, or want to take this as an opportunity to learn something new?

• Write a one-liner of the solution you intend to build. That becomes the core.

  I want to build a recipe-suggesting app. The core here would be a provision to take one/multiple pictures, and I get the appropriate recipes as result. Initially, the response can simply be in the form of JSON.

• Write down the surrounding requirements. That becomes the ancillary.

  For the same recipe suggesting app, log in/ log out, adding categories like cuisine, adding ingredients manually, suggestions on the type of response recipe (should it be spicy, sweet, etc.,), one can keep adding requirements depending on the need. But these are ancillary.

• Keep one type of end user in mind when you start. Then bring in another type of end user.

  Millennials can be the first type of users. Whereas fitness freaks can be another type of users. Parents of school-going children can be another. Keep the different types of users in mind and design your application, but start with one.

• Follow the usual approach of test-driven development. There are a lot of phenomenal books and materials available on these. Depending on your tech stack, a quick search on the internet should point you to the right set.

• Make sure to use a git repository to check in your code. Github, gitlab, bitbucket are the most common ones. If you feel comfortable, make your repo a public one.

☁ Step 3 - Once you build a workable application, you should definitely deploy it on the cloud. Choose a pocket friendly cloud provider. There are a lot of options available, cloud providers like Heroku, render, Digital Ocean, vultr, linode, vercel are easy for beginners. AWS, GCP, Azure have a lot of options, and it may be an overkill when you are deploying an application in the cloud for the first time or a novice.

Most of these cloud providers have brilliant documentation to deploy applications for most of the commonly used tech stack. Even if you do not find on their website, there are numerous articles in sites like hashnode, dev.to on deploying applications.

This step is mandatory. Unless you deploy it, you will be unable to share it with anyone. When we work in enterprises, there will be a devops team who take care of deployment. If you come from such a background, deployment may look a bit intimidating at first. Once you perform it a couple of times, it will become a lot easier. Especially, since such projects don't need to scale, will not need CDN when they start.

🥳 Step 4 - So you identified a viable use case, developed it, and deployed it for the world to see. The next step is to socialize what you built. Here are a few things to keep in mind:

• Never imagine that what you built is preliminary, and may not be of use. The idea here is not to build a million-dollar startup, but an avenue to show the world what you are capable of. Right from taking an idea, giving shape to it, and bringing it to life itself is an arduous task.

• Identify the right set of mediums to share. It can be a post on LinkedIn, a blog in Hashnode, an article in dev.to, or in slack communities that you are part of.

• Keep your code in a public repo.

• Ask for feedback. Find mentors who are willing to do code reviews. Make your code better.

• On the other end, make sure your app is being used by your target segment. Even if it's just a handful, you get real feedback in terms of requirements and problems. Such requirements only help you unearth a new concept/feature in a framework. Unless you apply a concept, you can never remember it, leave alone master it.

• You can tell stories only when your app is being used by someone, a real human. And stories are what strike a chord with many.

• If you simply build a solution and keep it aside, it will be yet another tutorial. There will be no scope for growth for you as a developer.

• Inherently, you will be developing your soft skills too when you start socializing. Be it starting to blog, improving your spoken communication, working on your articulation skills, networking skills, or tapping your prioritization skills, it's a lot of good.

🏆 Step 5 - Just keep iterating your solution with more and more features. You can as well pick up another use case/project to build if the one you built loses steam. Follow the above 4 steps, and boom, you can keep adding projects to your portfolio.

My closing thoughts

The process of building projects and displaying them as part of your portfolio brings out a lot of skills. Primarily, it sharpens your development skills. It helps you learn new concepts, and features in the framework of your choice. Unless we create a need to apply what we learn, we will never apply it. If we do not apply, it slowly withers out of our minds. When there is a need at work, you explore a concept at that point in time which delays the development process.

Secondarily, it builds the business aspect of what we develop. As a developer, you may feel the kick for solving a technical problem, but if you do not inculcate the habit of viewing what you build from a customer angle, you may never be able to grow beyond a point. End of the day, if what we build does not solve a problem, then it will soon be invalidated. Thus, developing business acumen will go a long way. It may become one of the differentiators when compared to your fellow developers.

Lastly, it works a lot on your soft skills, your design skills, and your creative skills. These are untold mandates expected of a developer. Gone are the days when one does what has been told and contributes to development only, the expectation now is to be a thinker, one who can foresee problems, one who can contribute towards building the product roadmap, one who can question choices made, all these on top of writing good code.

Here are some tips for making this "building of projects" a habit;

• Set aside an hour every day to work on such projects. Rather, set aside the same hour to work on these. That makes a lot of difference.

  Every evening between 4-5 PM, I will work on my portfolio projects

• If every day is not possible, set aside a few hours twice a week. The key is to stick to that same day/hour to work. Only then it becomes a habit.

  Every Monday and Wednesday between 8-10 PM, I will work on my portfolio projects

• Keep an approximate end date as a target and work backward

• Do not plan to build anything complex when you start. Keep it simple, grow it iteratively. Else, what you build will never leave your laptop. Divide and conquer works best.

• Make sure you have at least a handful end users, or you as a user have a pressing need to use the solution. That indirectly is the motivation factor.

• Never think that there is already a solution out there for this problem. There will always be solutions for everything. As I mentioned earlier, the intent is not to build a profitable startup, but to make you an all-rounded developer. Be clear with the end objective of doing this exercise.

Hope this post convinced you to build projects as part of your portfolio. Happy building!

Feel free to share what you built outside of work, how did it help you as a developer in the comments section, it may inspire many!