Hello, Habre! My name is Andriy, and I am a programmer. Like many people, in my spare time I am engaged in the development of my Pet-projects.

For myself, I wrote mobile applications, games on Unreal Engine, tried to teach a neural network to generate quests and much more. Most of the projects brought me satisfaction, self-realization, and growth. And some I could even consider my portfolio.

But sometimes the following happened:

• it seemed to me that I was writing “on the table”;

• crisis of ideas;

• lack of strength and desire to finish a good project;

• it is “embarrassing” to show your project, “but who needs it”, “this is not a portfolio”, etc.

Recently, I decided to evaluate past experiences and formalize my approach to working with pet projects so that they bring benefits and increase motivation, rather than creating burnout. I offer it to you in the form of a list of small tips.

Advice No. 1. Your project should be necessary for you

It seems to me that lately there is a kind of “cult of usefulness”. Many believe that any action should be result-oriented and should bring benefits.

Typical advice: “Think what good you can do”

In my opinion, the very fact that you are doing something for yourself and developing is already useful.

About 7-9 years ago, when I was a Jun, I was asked a very good question several times at interviews: “Do you write programs for yourself?” You have to write to yourself. If you want to benefit society, this is no longer a hobby, but a startup (even on a voluntary basis). If the goal is to make money, then it is already a business. And in these cases, the approach to development should be different.

Tip #2. Decide what EXACTLY you want to do

If your project is not for one day, I suggest writing out in free form what you want to get. A few lines with arbitrary wording: what I am writing, why, what I want to master and what I will use. This is the rule of “5 Why” on minimalka. It helps me weed out completely delusional ideas that I would never complete. In addition, it helps not to go too far from the initial idea (after all, there is always a desire to additionally “screw” something else).

A real example. In 2019, I decided to make an English-Russian dictionary on Xamarin. How it can be issued:

I want to make an English-Russian dictionary for Android.

A specific problem

What problem of your own are you solving by doing this project:

Need to save the words I looked up for later study/revision.

Goal

What is your personal end goal:

(No wonder) Learn the words.

Topicality

Why it matters to you right now:

I’m learning a language, plus I’ve always wanted to try mobile development.

Reach

Why are you sure that you can achieve the result:

Few features, I already know the basic programming language.

measure

What would you consider a complete or partial success:

Minimum: I use my app.

Maximum: Published on Google Play.

Tip #3. Although some of your projects need to be completed

Of course, we start some projects just for learning. Some are just weekend projects. It is not necessary for every project to be designed, published, have a Readme, etc.

But at least some of your projects should be completed. Especially if you are using new technology.

The same example from advice #2, I decided to complete 100% by putting it on Google Play. Even though only 16 people downloaded it, I was very pleased. Knowing that you’ve completed something 100% is a huge motivation boost and you really feel like you’ve achieved it. And, by the way, many new ideas appear immediately.

Tip #4. Keep in mind the end goal of your project

As a continuation of the previous tip.

For example, I very often want to first make a simple prototype and only then “comb” the code and finish the most complex. And sometimes with this approach comes burnout. After seeing a quick result, you relax, and then you are just too lazy to deal with a difficult topic. The project is abandoned, motivation drops, up to depression.

Tip #5. Set working hours

Writing on a whim for a few weeks at night can feel cool. But most often after that, fatigue sets in, and you abandon the project for an even longer period. Or you just get bored with it over time.

You need to control the time you spend on the project. Even if you’re madly enjoying this process, you have to stop yourself sometimes. Very often, when I had a project or technology change at my main job, I thought:

“Oh, cool, something new, and I still have a pet project. That’s experience x2!”

Only “Good for you“, as Sharyk said. After six months of intensive work, I began to think:

“And maybe, well, this code. At all… maybe it’s better in another profession?” etc. Our moral resources are also limited, and we must let ourselves rest.

And now some tips for beginners on the topic of portfolio.

Tip #6. Don’t invent work

Only if there is something to automate and optimize in your current workplace. It is better to take a real case and analyze it (ask acquaintances, and if there are none – at least examples of orders and projects on freelance exchanges).

After talking with the beginning developers from the courses, I noticed that some invent a business scenario for the project in the portfolio. Why can this lead to?

Software development is not just about code. Almost every interviewer will ask you, what task did you solve? The discussion of your decision will also include a discussion of a fictional scenario (sometimes not real), which could be:

• complicate the interview;

• turn in a direction you are not ready for.

Tip #7. And who is your portfolio for?

Unfortunately, at the beginning of my career, I did not pay any attention to this. If you are going to collect a portfolio, it should be aimed at the field in which you want to get a job.

See, for example, how artists do it – there are many materials on this topic. If you want to draw comics, it is at least strange to add photos of oil landscapes to your portfolio.

I hope it was interesting and useful. Finally, I would like to conduct a small survey: