_{Also available in 🇪🇸Spanish and 🇵🇱 Polish}

We all sometimes try taking on more significant tasks than we can deliver on—it stems directly from our human inability to evaluate complex tasks correctly. Let’s look at how you can address this in your IT journey.

Iterate

Moving in small, manageable steps is a cornerstone in many common methodologies in our industry:

• agile – is all about iterating with the changes to the product to discover what customers need, whereas
• minimum viable product (MVP) – aims to create the first version that can be checked against the market, and then it’s iterated from there.

Let’s see how to use a similar approach in your day-to-day life.

While learning

The best idea would be to:

• learn a piece of material, and then
• use it.

The working material will regularly present you with challenges to apply and test your knowledge in a well-organized course or book. If you learn without such a luxury, you will need to create those exercises for yourself. In both cases, the best feedback you can get is your code is working as expected—so you should either use what you’re learning from your side project or start a new one.

While working on a ticket

Do you often get stuck on a ticket? Chances are, you are trying to do too many things simultaneously. Usually, you can break a task into:

• refactoring the code you’re about to work on
• adding code infrastructure—helper methods, updating types, etc.
• making the changes to the application logic
• adding end-to-end tests for the new feature

In most cases, it’s better to do each part in a separate commit: you don’t want to review or revert refactorings with a new implementation. Splitting things into separate commits, and maybe even pull requests, allows you to get a review on your code quicker, thus speeding up your progress.

What should you do if you don’t know the code well enough to plan your actions ahead of time, or you simply forgot and have all changes done simultaneously? No worries, the knowledge you gained during the first attempt won’t go to waste—now, you can take a step back, start a new branch, and apply or redo some part of the big commit you started.

While doing projects

No matter if you work on commercial projects or on open source—you hear the same mantra everywhere:

• “Release early, release often.”
• “Move fast and break things.”

Even if you’re working on some personal learning project, you can apply this mindset. Instead of planning a big, final version of your project, try simplifying what you are building to a complete minimum. You can find some examples in my article about learning with personal projects.

Avoid falling down a rabbit hole

Your main goal with doing things in iterations is to avoid falling into a rabbit hole. It’s good to spend time investigating stuff; and as a developer, you need to be resilient to the frustration of not knowing how something works or how to fix a bug. The bad thing is that the same strength in the face of frustration sometimes works against you. At some point, the returns on investment of spending more time diminish to the point where you’re only wasting your time. You will be deep in the issue and already invested in fixing it when it happens, so letting it go will not be easy. Let’s see how you can avoid these traps!

You are not alone

In most cases, you are not working alone: there are other people around who can help you out. As a beginner, you have two potential modes of failure:

• seeking help too fast
• seeking help too late

What is too late or too fast, you ask? Well, that depends on the situation your team is in. I can easily imagine two extremes:

• your team is under a lot of pressure—an emergency of some sort, so no experienced developer is available to help out
• you are taking over from a developer who’s leaving in 2 weeks,so the priority is to get the most knowledge from them as possible

My advice is to figure out explicit rules with your team and then stick to them So, if you agree that four hours of hitting your head against a wall on a ticket is too much, then after four hours, you look for help.

Learn how to call it quits

It's not any better of an idea just because you spent so many hours implementing it. If anything, you proved the approach is not feasible or not as easy as expected. Avoid the sunk cost fallacy: the excellent strategy is to estimate before starting how long you want to spend on a task before leaving it behind, and then sticking to that estimate. Depending on the ticket, dropping it can mean letting another developer pick it up or not doing it all together, at least right now.

Always look for feedback

Every step of the interaction is a point where we can and should get feedback. It will allow us to make some course corrections and make sure we’re on the right track. There are plenty of feedback types we could look for:

• automated tests passing locally or on CI
• more experienced colleague or your mentor reviewing the code
• presenting our product externally and collecting feedback

Want to learn more? Check out my other article about feedback loops.