As knowledge workers and team players, we have a bunch of stuff to figure out every day that does not directly produce value.

Daily and weekly recurrent tasks.

Here are top-of-mind examples of mine:

• ⬜ Peer review

• ⬜ Review of My Tasks in Jira

• ⬜ Inboxes cleanup (emails, alerts)

• ⬜ Workspace cleanup (browser / IDE tabs)

• ⬜ Team activities such as estimations, groomings, KTs

Thus, to beat this clutter as an organized knowledge worker I argue you need to:

• 👉 Batch small tasks into one called Daily Checklist, a 15-20 min daily time block

• 👉 Schedule bigger ones, such as peer reviews up front, preferably at the exact same time in the day so your brain is prepared

• 👉 Share your calendar away so your manager knows what you are spending time on except the delivery

So that:

• ✅ You never have to remember what you need to do

• ✅ Your team knows when you are available for a meeting

• ✅ You can travel back in time to see exactly what you have been busy with

• ✅ Your manager doesn't put anything into your inbox without taking other things back

How to start?

Here are step-by-step organized ideas for structuring recurrent tasks.

1. Create a list of recurrent tasks

   Use mine as inspiration. Make your list pinned - it's just the first draft and you need to have a quick way to make changes

   

2. Batch small tasks into one

   Group items that take less than 2 (or whatever feels small) minutes into one "Daily Checklist" task.

   

3. Schedule Daily Checklist + Larger tasks

   Here is how to approach it - against each task, ask: "Can it be done every day/week/couple of days at the same time?", in other words:

   "Is there an algorithm behind the time the task should be done?".

   • 👉🏼 If yes - use your calendar's automation tool to schedule it forever.

   • 👈🏼 If not - add a respective “schedule X” task to your Daily Checklist.

Let's crack 2 examples:

• Peer Review takes approximately 1 hour every day and the best time is right after the end of the workday.

  Viola, you have an algorithm: Every day at 18:00, schedule and foget.

  Here's how it looks like in Google Calendar

  

• Grooming takes from 0 (we don’t have new task in backlog) to 1 hour (we have many) a day - no chance to get it standardized right away.

  Let’s add “Check backlog and schedule grooming if needed” to your Daily Checklist and the decision will be made every day.

  

My rule of thumb - there’s always better to schedule things upfront if possible

• 👉🏼 It reduces the number of decisions you need to make every day

• 👉🏼 It protects your calendar upfront

• 👉🏼 It exposes your workload to your manager the team

New items coming up

Now you have your tasks listed and scheduled, but no plan lasts long unchanged. Let’s crack the case if something new is coming up.

Say you have a newcomer in the team (let’s name her Jane) and your manager asks you to review her work daily. That would mean you need to get Jane on a call and make a peer review/peer coding along with her. Sounds like an hour a day you are dedicating to Jane, let’s put it on your calendar.

1. Agree with Jane on the time and duration of your peer activity (say 1 hour, 2 PM)

2. Use the p.3 of “How to Start” to place the thing on your calendar or tasks list

Now you have a predictable and structured task in your agenda. What is important, your manager now sees the new thing on your plate in terms of time and won’t expect your delivery rate to stay the same.

2 words about weekly review

It's worth mentioning besides daily some items would fit into the weekly one. I use the weekly for more high-level things:

• 📅 Follow-ups from the previous weeks' calendar events; "thank you" notes, reminders and "ask me later" items.

• 🎯 Reviewing company vs personal goals/projects to keep doing the right thing.

• 📚 Any once-a-week optional scheduling as estimations or knowledge-sharing sessions.

The rules of scheduling are pretty much the same - the more you have standardized, the less admin overhead you have on deciding when to do that.

Aim to use "Is there an algorithm behind the time the task should be done?" for everything that is coming from both outside (your manager, teammates) and inside (your own ideas and projects).

Wrapping up

I stay on the notion that having your calendar structured leads to clarity and peace of mind. As software engineers, the most value we deliver is being created in our focus time, protected from all sneaky urgent-but-not-so-important tasks, from checkups and forgotten chores.

So then:

• List all recurrent tasks you have daily and weekly

• Batch smallish to “Review” tasks

• Schedule recurrent time blocks right away for as many bigger ones as possible

• Expose your workload to your team and manager

Enjoy clarity and focus.

• 👉🏼 Plan the day according to your energy

• 👉🏼 Prioritize work items to follow your and your company’s goals

Today we are talking about planning the workday and how I approach it. Here are the steps I follow:

• 📊 How to determine your high- and low-energy periods throughout the workday.

• ⚒️ How to classify your work by the types of tasks it involves.

• 📝 How to plan your day.

• ✂️ Adjust your plan if things coming up (or down).

High and Low Energy Blocks

You aren't equally productive all day, and you know it. Some time blocks might even be better spent away from work, as you're likely to waste them due to low energy.

It took a while for me to figure out my energy blocks, but there's a simple way to do so:

1. Set a timer for every work hour and track your mood, energy, and alertness throughout the day. After a week of tracking, you'll see patterns of ups and downs.

2. For consistent results track also your sleep, physical activity, and meals. I’d elaborate on the way to do so but that's a topic for another time.

For example, this is a breakdown of my typical day (80% of workdays look like this):

• 9:00-12:00: High energy

• 12:00-15:00: Medium energy

• 15:00-16:30: Low energy (or no energy)

• 16:30-19:00: High energy, and

• 20:30-22:00: Middle or low energy depends on my workload before

Your daily energy map should guide your planning. You can maximize productivity by following it.

Understand the Types of Tasks

For most software engineers, task types are quite similar. It takes time to track them, especially after changing jobs, projects, or roles. After a month or two in the same position, you can predict up to 90% of your daily tasks.

My task blocks look like this:

• Tech design: When I get a new task and need to figure out how to approach it, including integration and object design, and data flow layout.

• High-intensity coding: Hands-on engineering tasks requiring full focus, such as algorithms, bug fixing, and refactoring.

• Low-intensity coding: Implementing tech design, writing tests, and infrastructure work that doesn't push cognitive limits and feels more routine.

• Peer review: Reading peers' code, deploying and testing locally, and reviewing documentation and tech designs.

• Team-related work: Meetings, async activities, and agenda preparation. All social aspects of work.

• Infrastructure work: Rebases, deploys, Jira ticket management, and other shallow and automatable tasks.

Once you identify your task types, set an "energy level" required for each:

• Tech design: High

• High-intensity coding: High

• Low-intensity coding: Medium

• Peer review: Medium

• Team-related work: Medium

• Infrastructure work: Low

Now, you're ready for the next step.

Steps to Plan Your Day

There's one type of work I haven't mentioned yet: the Daily Review. This is the time you spend planning your tasks. The goal is to connect your priorities with your energy levels to produce a daily plan.

I'm a big fan of time blocking and using a calendar. I argue that any task should have its place on the map of your day, otherwise, it can hardly be done.

Here are the steps:

1. Clean your inbox: Process emails, chats, Jira, and code review comments, turning them into tasks.

2. Plan recurring tasks: Schedule them in respective energy-level blocks. Examples include peer review, deployments, backlog, and Sentry alarm reviews. Plan these activities at the same time each day to build a habit.

3. Plan project work: About 70% of a developer's work involves building something. Schedule:

   • Tech design and decomposition in high-energy blocks.

   • Implementation of difficult parts in high-energy blocks.

   • Integrations and less intense tasks in medium-energy blocks.

4. Schedule remaining tasks in the appropriate time blocks - once project work is planned, fill the remaining time with smaller tasks, like handovers, deploys, clean-ups, etc.

5. Share your plan. It's not mandatory but highly recommended. Share your calendar with your team:

   • Mark the time of the deep work as “busy” to let them know when meetings aren’t possible

   • Commit to tasks are in your calendar, so they know what you are working on.

Now you have your day planned according to your energy map and can start working.

Yep, it won’t be so plain every time, and your plan often needs to change.

Adjusting Your Plan

Rescheduling is an important part of being intentional about your time. When urgent tasks arise or planned tasks become unnecessary, reassess priorities. Imagine two scenarios:

An Urgent Task is falling onto your head

Chats with urgent roll-outs, bug fixes, and requests can be disruptive. My rule is never to keep chat open during high-energy, deep work blocks. You know, regular updates look just the same as urgent, but appear 10+ times more often, and if you pull yourself to check whatever comes every time you hardly are able to focus.

Nonetheless, if an urgent task arises, don't just drop your current work. Evaluate what’s going on first:

• Urgent bug on production? Determine if you're the best person to handle it and what the timeframe you have to fix it up.

• Still no chance to avoid it? Reschedule the rest of your day. Do a mini-review and adjust today's agenda to accommodate the new priority.

Sometimes, more often than you might think, the urgent task can wait until tomorrow or be assigned to a peer with a lighter workload.

Something you are working on is no longer important

Completing a high-focus task early or it becoming irrelevant can lead to defaulting to shallow tasks or distractions.

Instead, switch to the next important and complex task to make the most of your productive time. Conduct a mini-review and focus on the next big thing.

So you get the framework when plans seem to be changed:

1. Evaluate updated priorities - it’s important to test new work against existing ones.

2. Adjust your plan following the new ones.

It takes time to master daily planning, and even after years of experimenting, I still learn new things about myself and my work. Be open-minded about your schedule. It's okay to plan hard tasks for the evening or take a nap after breakfast if it suits your biorhythms. Turn off chats during deep concentration periods to maximize productivity.

In the next deep dive, I'll focus on daily reviews with an emphasis on clarifying and prioritizing your inbox. Stay tuned!

• When Deep Work doesn’t help or even harm

• From what to start when planning your workday

• Where to pour your Pomodoros

Let’s talk about the 2 most popular, yet mutually exclusive techniques: Pomodoro timer and Deep Work + introducing another one. So we got here:

• Deep Work: Coined by Cal Newport, this method advocates for deep and uninterrupted concentration, leading to a laser focus on tasks, resulting in higher quality work in less time. The longer you engage in deep work, the higher levels of concentration you can achieve, and the better your output.

• Pomodoro: This technique, popularized by Bob Martin in his book "Clean Coder," involves working in 25-minute intervals followed by a mandatory break (typically 5 minutes).

• Background Thinking: This psychological trick involves setting aside a challenging task and allowing your subconscious mind to process it, often leading to solutions that emerge after a break or rest.

Choosing the right method for different tasks is crucial. Below, I'll break down the differences and provide insights on when and how to use each technique.

Deep Work

Deep Work, introduced by Cal Newport, involves distraction-free professional activities that push your cognitive limits to their absolute limit.

4 Principles of Deep Work

1. Work Deeply: Timebox your day with long-lasting deep work sessions and protect that time from distractions.

2. Embrace Boredom: Train your brain to resist distractions by allowing yourself to experience boredom without immediately seeking stimulation. As stated in Atomic Habits: "Not Fear the reasons for our failures, but Boredom."

3. Quit Social Media: Cal suggests the Craftsman Tools approach to evaluate your time on social media. Each media (say FB) should bring more value to your Life Goals than harms your concentration, and should be dropped otherwise.

4. Drain the Shallows: Identify and minimize "shallow work" (tasks that don't require full brain capacity). Timebox them to low-energy periods, delegate, or even eliminate them.

Benefits of Deep Work

• Rich Output: Regular deep work sessions lead to significant productivity gains.

• Maker's Mindset: Pushing your productivity limits and filtering your activities by your goals uncovers more inner potential.

Downsides

• Hard to Adopt: The deep work mindset and schedule require considerable effort to integrate into your life due to constant distractions and chores. Maintaining focus for extended periods is challenging.

• Might lead to burnout: whether it is not stated in the book directly - for one it could be even harmful to push oneself too hard.

When to Use Deep Work as a Developer

Use deep work for complex tasks with a high cognitive load that requires understanding and manipulating large data structures.

Pomodoros

The Pomodoro technique is simpler to understand and adopt. Essentially, you work in 25-minute intervals followed by a 5-minute break.

• Work Mode: Focus on the task at hand without interruption.

• Rest Mode: Take a complete break and do whatever you want.

Benefits of Pomodoros

• Simple Implementation: Just start the timer and go.

• Flexible Scheduling: Easier to fit 25-minute blocks into a busy schedule than 4-5 hour deep work sessions.

• Clear Boundaries: Knowing when your work time ends helps maintain focus until the timer goes off.

Downsides

• Disruptive Alarms: The end-of-work block alarm can interrupt your train of thought.

• Rigid Structure: Needing more time for thinking or rest can require breaking the Pomodoro structure, leading to inconsistent use.

When to Use Pomodoros as a Developer

Ideal for shallow work, such as:

• Release notes

• Tests coverage

• Code clean-up

• UI fixes and simple bug fixes

Background Thinking

It might seem straightforward to use deep work for complex projects and Pomodoros for shallow tasks, but it's not always that simple. As a developer, you might spend hours on a task without solving it, only to find the solution after a break, meal, or good night's sleep. This is known as background or subconscious thinking, where your brain continues working on a problem even when you're not actively focused on it.

Where to Use

My rule of thumb: If I spend an hour without making progress, it's time for a long break. As engineers, we often push ourselves to keep debugging or adding conditions, thinking we're just one line away from the solution. In reality, the solution often comes after taking a rest.

Personal Opinion

As a software engineer, some tasks require deep focus (like building an algorithm for data processing), where Pomodoros might be counterproductive. Deep, uninterrupted concentration works best for these tasks.

However, for other tasks, like code reviews, clean-ups, or writing release notes, Pomodoros helps prevent boredom and maintain focus.

How I structure my schedule

At the beginning of the work day, I already have 80%-90% of tasks well-defined. I might be having a peer review block, some shallow reviews/writings/groomings, and the main task I currently focus on.

So I allocate around 3-4 hours to get myself focused on the main task, and distribute the rest as peebles across the rest of the day.

There is always a lot on your plate, and the way to have your day well organized is to:

• Agree upfront on collaboration - schedule handovers to QA, peer coding, etc.

• Batch "shallow" tasks together.

• Let your team be aware of your deep work time - nobody wants you to harm your productivity due to distractions.

• It is okay to reshuffle your calendar. Not okay is to sacrifice your output for someone else's needsd

Tips to go

As the closing, let’s boil down the points you can use right away:

• Plan long, uninterrupted sessions of deep work for solving the complex task

• Plan these sessions at first

• Plan shallow work as Pomodoro blocks around the deep work block

• Switch the context if you stuck with the task for more than 1 hour

• Track your productivity throughout the day and adjust your deep work block time for the best output possible

And remember, there’s absolutely zero sense in productivity when you work on the wrong thing, but it’s a topic for another time 🙂.

However, our inboxes often become a mess, and our "wanna read" list rarely matches our "actually read" one.

Today, I'm discussing a simple trick with Gmail that helped me narrow my focus: setting up filters and labels for all incoming newsletters and updates. (For those who prefer video format, I've created one. 👇)

https://www.youtube.com/watch?v=eNIjSRlWnjQ

Step One - Collect Your Favorite Sources

You might have gone through this step many times, subscribing to feeds from Substack or newsletters from "this guy cracking honest advice in X." It could even be something unrelated to engineering – recently, I was looking for a flat in Madrid and subscribed to many alerts from real estate agencies.

Just for your inspiration - these are my favorite newsletters (no affiliates):

• Pragmatic Engineer

• Refactoring

• Tech World with Milan

• Lenny's newsletter

• One from Mozilla

Now once you have a solid portion of content in your inbox daily, let's organize it!

Step Two - Scaffolding Your Dedicated Data Streams via Labels

Each label represents one specified inbox. E.g. the one called "Realty" is specified on real estate agency alerts.

Steps to set up a new label:

1. Open Gmail and go to Settings (gear icon) > See all settings.

2. Navigate to the Labels tab and click Create a new label.

3. Name your label (e.g., "Newsletters" or "Realty").

Or just hit "+" near the labels on the sidebar.

The settings view gives more of what labels you have and which are shown, but the Gmail UI here is quite outdated.

Step Three - Organizing Messages by Your Streams

No, you don't have to organize it every day! Not anymore.

You are about to set up an organizing automation that will be doing it for you - every time you get something to your inbox the automation will redirect it under the label it should be.

Steps to set up a filter:

1. Click on the "Adjustments" icon in the search bar

   

2. Add the email to From you want to filter out, then click on "Create filter"

3. 

   Select "Skip the inbox" to not see it in your common inbox, and "Apply the label" to make it go to a specific label of yours. Then just hit "Save filter" and that's it.

You can do it from settings as well, just go to Settings > Filters and Blocked Addresses, and all your filters-related settings are over there.

Step Four - Exploit the System You Just Built

Each of the labels you set up is dedicated to a specific activity you're striving to do.

Developer newsletters are great to skim through in your spare time – now you're up to date with "this new fancy framework/tool" and can share them with your work chat to discuss with your colleagues.

For example, once a day, I go through my "realty" label and bookmark flats I like to call later.

No fancy apps are needed. No distractions from the rest of your busy inbox.

Step Five - Your Filters, Your Data

Say you built a decent filters library but suddenly need to change your email or create a new one.

Or maybe you want to share your setup with a friend/community? Fear not, all your filters are just a few clicks away from being an XML file that you can use any way ever you want.

Steps to export/import filters:

1. Go to Settings > Filters and Blocked Addresses > Export.

   

2. Save the .xml file.

3. On your new email account, go to the same settings and click Import to upload the .xmlfile.

You can create your own automations and tools based on the filters you've just got. No limits for a programmer.

Typical Workflow

Let's wrap up how you will be working with your label-filter system:

1. You've got an email in your common inbox. It's a recurrent alert or newsletter, and you want it to be organized under a specific topic.

2. You create a label for it. Say it will be "React updates."

3. You set up a filter for the sender.

All new "React updates" will go there and never to your common inbox anymore unless the sender address changes – in that case, you just need to go through the process one more time.

Bonus Step - Going Beyond

You've built a system, and it grows with you, getting populated with more sources and labels. Say you are getting tens, if not hundreds, of emails a day, but you're actually interested in maybe 10% of them. At some point, you might think – can someone else can filter those I'm not interested in? Like one more level of curation.

We're targeting exactly this problem at Feedster – we're building an AI automation that uses your learning goals against your feed and boils it down to the essence that you are most interested in.

Stay up to date with our story in that blog.

What do you think he put into the "Business problem" section of the document?

Right, TL;DR, "I feel like copy-pasting isn't a good solution so I'm willing to spend at least a day building a universal abstraction and change existing logic everywhere it is used".

If you were a business folk, what would you think reading this?

Probably something like "Why in the world do your feelings cost us hours of development and risk of changing something that's not broken?"

Never get approved.

However, being an engineer and reading it, you might feel the same as the developer writing the spec.

Maybe even you want to speak up for the guy: "It's obvious, we need to do that!"

But to make a business guy convinced by giving you time (money) and accepting risk (money again) for the "good tech design" requires going down the rabbit hole of whys behind the things that seem obvious for one who is in code.

The why

Let's use a good old 5 whys here - our goal is to turn your feelings into money

Why is copy-paste bad?

Because in case of future changes, you'll need to go across these "pasted" places to change things respectively

Why are multiple alike changes bad?

Because it multiplies the work by the number of places to change, as well as the possibility that the developer will drop a bug around there

Why does it matter?

Because the work required will grow every time we add one more scheduling and risk of failure as well

Do you feel the smell of money here?

Yep, if we don't put X hours into fixing it right now we will be ending up spending N+1 hours for every schedule-related task.

Money math

If we don't take the risk of regression when doing refactoring now - we will take more risk each time we need to change the business logic

Moreover, eventual refactoring is unavoidable and each time we postpone it becomes more complex and time-consuming in terms of both replacing work and fixing regressions. That's why it's called "debt"

Refactoring time = time for solution + (time to switch solution * implementation amount (for every copy-pasted place))

Risk not having refactoring = risk of code to fail * times it's postponed

Money loss = Refactoring time (dev hours) + Risk not having refactoring (quality-related churn and dev hours to fix bugs)

As you can see each time we copy-pasting one more time it increases the final price of refactoring and risks if refactoring isn't made. One day the maintenance price will surpass the cost of stopping and refactoring immediately.

Spiral of death.

So every "time postponed" will add an "interest" to your problematic area.

Make it sound like money

Let's get back to our guy, what would he write to make it sound lucid for a suit

"We have business logic related to scheduling <list the features business knows and don't want to get harmed>, and it has a bad tech solution in place.

The scheduling logic was used in the new code N times last month/quarter and it took X hours.

If we spend X hours to refactor this, we will spend Y hours less on future changes, and it will be paid off in Z weeks".

Sounds quite business, right?

Now let them decide how much money they want to burn for the sake of moving fast sacrificing the speed in the future.

Yes, sometimes "let debt live for X weeks more so we can finish that release faster" is more than okay. Business needs to sell, grow, and scale, not suffice your striving for beautiful software technical design.

Cheers.

The task seems to be unbearable, so complex, and you probably need to refactor "this shitty thing you wrote last month". All your jump-on attempts end with Git Rollback on the file, and the same blank screen in the commit log as well as in your head.

How about turning it upside down - test it before you even start writing a thing? Yes, I know, TDD is overhyped and freaking complex, especially when it comes to trying to squeeze all the code you write into some sort of test (is this button becomes red if I add red color to it?).

Also, you might heard about TDD like it is something from high-end engineers who never write a function without covering it with zillion edge cases and a library of comprehensive mock factories.

But it's not only "coverage" moreover, TDD as a method for coding doesn't have anything in common with coverage metrics and SonarQube alerts.

It's about the way of thinking.

It’s an overwhelming overhead for simple pieces of code, but lifesaving is necessary for others.

Consider a task - you have a tree to walk through, and you need to apply something to its leaves. Sounds not straightforward, eh? Smells like recursion or like something scary from interviews like dynamic programming.

How do you approach it?

Will you jot some if-else and run the debugger on real data back and forth, waiting for the bundler to build and hoping that other cases will work out the same?

Wrong.

You've spent all day debugging and ended up with another "re-open" because the QA guys tried something different.

But how about this:

1. Disconnect the function from the entire code completely, just a pure function with “in” and “out”.

2. Write a test, just a happy and simple case

3. Make it pass, not a big deal for the happy case, right?

4. Write one more test, a different happy, or maybe the most common unhappy one

5. Add "if" to the function to handle it

6. Repeat

You can use test cases passed by your kind QA fella as a source for case ideas and, keep running "all tests" to catch the regression.

Do you have a 300-liner with if-else hell? Who cares? You have a working piece of software that passes all the tests!

Refactoring? Not a big deal since you have all cases covered and any tweak in the function will be tested and warned if something is off.

You are happily shipping the already tested task to your peer QA who's happy to close it ASAP.

Your manager is impressed by your quality rate, and your peers by the complexity of a task you could handle.

Your tech lead is happy with the coverage that grows even if there are no "explicit coverage tasks" assigned.

Feedster is specifically targeted towards this room. With the help of it, we aim to answer the question of how to extract the most value from the daily stream of updates while significantly reducing the time spent. GPT helps out here.

In a nutshell, the idea is to filter these information streams by given learning goals, e.g. you want to stay updated on the NodeJS ecosystem, you give a prompt and Feedster tests each information item coming against your goals list, let it come to you only if resonates.

The idea sounds awesome, but we struggle to shape a product out of it.

Initially, we wanted to create a feed-based app, but as MVP we ended up building a digest machine - you get your news daily as a filtered and summarized digest.

The whole data flow behind the daily digest could be separated into 4 steps:

1. Fetching data from sources

2. Test each piece of information against user-defined goals and filter out what does not resonate

3. Summarize the rest to a set of bullet points

4. Ship the 5-min-length digest to the user

Let’s break them down one by one.

Fetching data from sources

The whole information journey starts with sources. We have introduced the 2 of them we use ourselves - RSS feeds and Gmail newsletters.

With Gmail, it's a bit tricky since you either need to introduce a separate email address or set up a separate label (like we did) to not mess up regular messages.

More sources are more than possible. The best case scenario here is to expose the universal API to connect any kind of source using No-code tools like Zapier. A lot of people would like to use more targeted marketing sources like Google Alerts, for instance, to watch over their competitors.

By default, we check the last 24-hour updates once a day from all connected sources. The hard thing to manage here is to balance the amount of information to get and to process - the less information we get, the less comprehensive digest we will have in the end, but on the other hand if we take too much, reading such a summary wouldn't be a 5-minute task as we want it to be.

We propose a win-win solution: process the entire dataset, rank it based on goal alignment, and only ship the most relevant 5-minute digest.

It would require more tokens but GPT is getting cheaper, right? :)

Filtering

The prompt engineering journey starts here.

When we get all the data in place, we need to test each piece of information against the user's goals, It sounds pretty simple, but when it comes to practice a lot of pitfalls are coming out.

Straight forward approach would be to just ask GPT whether it resonates or not against any news post, but it turned out that sometimes it gives wrong-yes and wrong-no because it doesn't understand how some topics can be connected to some information. We will elaborate on such discrepancies when we research them more, for now, one of our solutions is to ask GPT a scale (e.g. from 1 to 5) of matching, instead of just "yes" and "no", it turned out much more robust.

However, it's still missing out on good ones, and letting go of some non-relevant. The biggest problem we face right now is to give the algorithm the level of proficiency of the reader. For example, if my goal is to get updates about Javascript, and I'm a senior, I would not be happy having "how to write a for-loop" kind of articles in my inbox every day.

Summarizing

Okay, seems like fetching and filtering information aren't easy things to handle, but what could be wrong with summarization? Just ask them to cut all the water and transform the whole thing into bullet points.

Not so easy.

Once again, when attempting a straightforward approach, it begins to explain things that weren't intended. For example, our developer Kirill subscribed to Git updates, and in the summary from the last one, he has a couple of bullets explaining what Git is!

So the "proficiency" of the reader is popping out as a problem here as well. GPT is very kind to us and assumes that we need to get more context while reading about niche things as Git, but for a personalized news reader, that should know what you want to read is a bad thing.

Here's the prompt engineering comes along the way once again.

Forming the digest

Finally, we have our summary, all the backlinks, and goals that showed up as relevant, and we combine the whole thing into a digest you get in your inbox.

Here's one more pitfall I faced when setting up the thing for myself. I'm a Readwise user, and I want to process what I read and get parts that resonate in my library. With RSS the workflow is pretty easy

• Place a backlink to digest

• Go to the source

• Save it to read-it-later app

Sounds simple, but there might be questions on how to save time using the summary, like going to the specific part of the article, instead of the need of saving the whole piece of text (that could be overwhelmingly huge) and reading it later seeking for the interesting parts

With newsletters the workflow is even more clumsy - if you want to save an interesting issue to read it later you probably need to forward them to a dedicated email or put a special label on it.

Any of these options are hard to anticipate from the start. And that’s why good product design can help us out.

What’s next?

What you observe is an early-stage product forming, even before we can go out and validate it. We have several areas of improvement:

• Product design - a solution we have right now might be okay for innovators-engineers who are okay running things via CLI and experimenting to take out the best. Definitely not for everyone, that’s why we’re on a journey to turn the algorithm into a product.

• Robustness - You’re not getting your digest because of OpenAI API timeout: that shouldn’t be the case. So far, we have a bunch of engineering challenges we still need to address

• Prompt engineering - as with any GPT-based product, Feedster can be significantly improved by fine-tuning prompts based on user experience, we can see a huge room for improvement in the area

• Customer discovery - it’s a pain point for any engineer who wants to run a startup: we want to build and don’t want to go out doing marketing. But talking to experts who can help out here can be a way out.

So if you are a designer, marketeer, or engineer obsessed with AI, and you see the bright future of goals-driven news consumption, feel free to reach out, let’s have a talk!

In the second part, I will elaborate on the execution and reflection phases. I will discuss the release train we built, the challenges we faced with our architecture, and what we learned as a team. As the tech lead, I gained valuable experience from this project that is still helping me out every day in engineering.

How the first months went by

It took us approximately 2-3 months to go from the product idea to launching on the market. We acquired our first users 3 months after starting development. However, the app was not entirely ready for these initial users. To be completely honest, it was only after six months that our app became robust enough to emerge from beta.

We had been working in one-month iterations, just as our CEO had been funding the development, with the expectation that each iteration would bring a real product increment.

Eventually, we established two-week sprints, and in almost every sprint we were able to release something to the market.

The overall app life timeline for the first half-a-year

However, churn due to the lack of robustness was a significant challenge during the first few months after the MVP release. The accumulated harm caused by this issue ultimately led to the product's downfall.

As expected, most coaches were not willing to be beta testers. Therefore, we had to establish almost seamless communication between our early adopters and the CTO/Dev team. In fact, a few times we even had been delivering notifications manually when our algorithm failed to perform its job correctly!

How We Spun Out Our Release Train

Market release timeline

The first challenge we faced setting up our post-MVP processes was the difference between Mobile development and web one. When you build stuff for mobiles you should be ready for the long approvement review and potential push-backs, especially from the Apple team. We needed to plan things ahead, and never rely on a fast approvement in case of urgent hotfixes, so each feature could be easily stuck for a week - we designed our release train correspondingly.

Workaround for these “delayed releases” became Expo direct deployment (by swapping .js files right in the working app), it was an amazing way to mitigate risks, and we saved a few ongoing programs by hot-fixing scheduling issues right on time instead of going through a long and clumsy process of updating via the store.

In addition, we were making intermediate releases - mostly change request ones, copy tweaks, and so on.

Engineering the train

As a foundation, we chose the good old 2-week Scrum as we had before. The 1-month iteration pace requested by our founder was perfect to fit 2 sprints into, and eventually, we were spending about 1.5 (3 weeks) for actual feature development, and the rest 1 week for tech debts and regression run before the next release

Speaking of 1-week regression - yes, we had failed to automate our tests, since React Native didn't have (or we just didn't find) a good option of doing it seamlessly, so we established the comprehensive testing before the release and were trying to optimize it as much as possible. It was a straightforward workaround to prevent issue leaks, however, never worked fully - leaks still were happening.

Also, we’d been doing a regular backlog refinement to find and reduce ongoing defects, Our goal was a zero-known-defect state, but we never actually reached that.

Along with refinement we usually prepare the next scope from the CEO’s ideas, customer complaints, and our own technical points. That’s how we were planning our work, and it let us be on time and ship the software no matter the lack of expertise and constant pivots.

Finally, apart from the main pipeline we were working closely with our customers to reduce the delay between problem spotting and its fix. I was often debugging issues right on the users' accounts, and the ability to do that tailored to architecture was a good choice.

That’s how our release train looked like, sometimes we broke our terms but in 80% we followed the system:

And what we had as a result

As a tech lead and, eventually, Project manager I was responsible for the timeline and engineering excellence around the project, I had a lot of work, and a lot of things to learn. I felt like I got out of the 1-year venture as a new, mature engineer and tech lead.

We brought a huge pile of experience out of the whole enterprise, what we have learned from the whole enterprise is what worked and what didn’t:

What worked well

• Eventually, we were able to establish a fair delivery pipeline and robustness and could implement features within a single iteration. I have since taken many of the solutions developed for this app and applied them to my daily work.

• I learned many technical skills such as Mobile APIs, MQTT (for chats), and offline cases during this project. This experience has allowed me to become a generalist developer, capable of working on any project, language, or platform, rather than specializing in one specific area of expertise.

• Upon returning to cozy SaaS web development, we found that our processes had become much more reliable and mature. Mobile development proved to be a challenging task.

• Finally, I learned not only how to deal with mistakes, but also how to defend your decisions (even bad ones) in front of customers. I had a few tough conversations with the founder after some things went wrong.

What Didn't

• The biggest technical challenge we faced was scheduling notifications. The Notifications API wasn't intuitive, and we had to pivot three times before our notifications delivery became robust enough to avoid cringe-worthy errors every other release.

• One lesson that has been emphasized in many places is that technical design should be as simple as possible. We should leave as many decisions undone as we can afford while still shipping features. This is especially important in mobile development, where different users may have different versions and we can't afford to break backward compatibility.

• Never release a raw beta version to users who are not willing to be beta testers. The churn we faced was actually detrimental to the product's success. Although it was not our decision, it's a lesson I took away and will remember for the rest of my development career!

Conclusion

This project helped me grow from a developer to a tech lead/engineering manager. Through this experience, I learned that development is only successful when it is managed properly and when clear priorities are established in the backlog.

Following this huge project, we launched a few smaller MVPs which went much smoother. Stay tuned for more upcoming posts on the topic!

Please share your own stories of building a startup. Every story is unique, which is what makes such ventures especially interesting!

The story is divided into four chapters:

1. The product idea

2. Planning the technical design

3. Implementing the design and overcoming challenges

4. Lessons learned from the project

When it comes to assessing or estimating a new project, we often overlook important factors. Today's story highlights what we overlooked and how we dealt with it.

What needed to be done

As a startup-oriented team, we were looking for an interesting project to dive into and eventually found a very promising one - an accountability app that connects coaches and their students.

Our target audience consisted mostly of business and motivational coaches who interacted with their students online. We provided a SaaS platform for them to create programs (essentially a set of questions) and manage their student's data in a CRM. Students were provided with a mobile app to stay connected with their coaches.

Coaches were creating training or accountability programs for students with daily or weekly habits. Students should have been consistent in fulfilling the coaches' tasks to keep the streak rolling.

This is a very simple representation of the whole idea

Apart from the program's functionality, we offered live chat between students and coaches, and different additional customizations, but the main idea was to keep mentees accountable by keeping them connected to their mentor.

Speaking about the background of the whole venture - the project had been self-funded by one coach (actually he is a kinda meta-coach - a coach for coaches), and literally, we had been receiving micro-seed funding each month, hence, we needed to show progress and user-ready app every month as well.

And regarding the team, we had 1 CTO, 5 developers (3 mobile, 1 web, and 1 server-side), 2 QAs, and 1 UI designer. I was the tech lead for the mobile and web squads and worked with the backend developer and CTO to plan the architecture. Additionally, I was responsible for project management at the end.

How we had things planned

The biggest challenge we faced during the planning stage was ensuring that programs started, ran, and finished on time, without missing any notifications. This was especially important because accountability for the mentee was a core value of the app.

We first considered developing a student app and ultimately decided to create a full-scale mobile one. This was done to ensure that the app could function even without an internet connection, by storing programs on the student’s device and scheduling notifications in advance. Once again - accountability was a top priority, hence we needed a robust notification system that could handle offline cases and delayed responses sent back to the server.

Technology choice

In terms of technology, we were all web developers. When we needed to build a mobile app, React Native was a no-brainer for us. While we did consider Ionic and other web-based platforms, the feedback we received about React Native was much, much better. The resulting apps felt pretty native!

Also, we chose Expo as a development and deployment platform because almost none of us had a Mac on board to develop via Xcode. However, this choice turned out to be a mess when it came to deployments.

For the backoffice designed for coaches, we decided to use a web dashboard with all the necessary tools located in a sidebar, following a typical SaaS layout. To build this, we used the reliable Vue/NuxtJS framework that we had experience with from previous projects.

The trickiest part of the whole design was to come up with the right backend landscape, and how to keep coaches and students synchronized even in terms of progress being offline and possible program changes from the coach side. You feel the challenge over here, right?

Our CTO had come up with a comprehensive sync protocol to ensure updates are properly managed. However, we had yet to fully implement this protocol. As a solution, we implemented an MVP that simply runs a "get updates" function. This function merges data from the server with local data in SQLite, which is used in our app.

In addition to all of that, when we later added live chat between coaches and students, it added another level of complexity to the coach-student connectivity, we used MQTT as a protocol but decided to develop the whole infrastructure around it ourselves.

TLDR; The overall solution tech design had had 3 main components and 1 additional:

• Mobile app for students: React Native, Typescript, SQLite under the Redux-persist interface

• Backoffice for coaches: NuxtJS, also Typescript

• Backend with database to actually keep things connected: Laravel and SQL.

• And one additional component - the Expo server instance to deploy new versions of the app.

Good plan but what’s next?

The planning and proof-of-concept stages took around two months, providing us with a solid foundation to launch the thing.

In the next part of the story, I will describe our experiences with the execution, including the problems we faced, what worked, and what didn't work. Most importantly, I will share a story about the release train we built and how we failed to manage quality, which became a lifelong lesson for me!

The story is a good example of how things easily can be overengineered, and how far descoping can go.

Solving the own problem

I always was keen to make software around the inbox, the incoming information seems to be endless, more and more year after year, so at some point, automated curation should start to be a thing.

So as a dedicated engineer, I want to be on the edge of techs and innovations in my niche (engineering at early-stage startups) and I faced that I need to process a lot of information.

For instance, I subscribed to newsletters about AI, SaaS, Indie Hacking, React and other web development tools updates, productivity tools updates, startups bootstrapped, and so on.

The summarization was the first, obvious solution to reduce time reading.

That was the initial idea of how it should work

Moreover, not all info given by the sources I use is applicable to what I do, e.g. newsletters about AI give not only integrations applicable in software, but also design, chatbots, and other stuff, which may be interesting, but not really relevant to my work.

For even curation my inbox (selecting what I want to read among all incomings) I spend like 5 to 15 minutes daily!

So in addition to summarization, I decided to declare a set of goals-topics (basically prompts) and use it as a filter for all incoming information, which I called a "goals-driven news reading".

Overengineering

All the development started as a pet project between friends, we just wanted to practice our tech skills on challenging tasks, but it went out of control really fast

Initially, we wanted to make a news-reader with an infinite-scroll feed and settings, AI stuff wasn't on our plate, the idea was just to build a common, "Facebook-like" newsfeed from newsletters and RSS feeds.

The summarized newsfeed we have designed in Figma

Later, when ChatGPT was released, and all the world went crazy about this we came up with the "killer feature" - what if GPT will process our feed and make it more efficient to consume?

The first solution was huge, it includes all possible trendy tech stuff, such as event-based frontend, GraphQL, caching, and even queue-based summarization/filtering on a background!

We deployed the application on VPS using the set of Docker containers, and even start talking about the build automation. The system was ridiculously complex and was given a ton of bugs!

That’s right, we had 0 customers, however, almost established a CI/CD pipeline for our application.

No matter all the fancy techs our prompts sucked, and the output wasn't really useful. This is weird how we built so much for summarization, but we left the summarization itself to the end of development.

The settings page

We have been working on the application for more than half a year, we were a team of enthusiasts, and we even hired a UI designer to make all layouts, should I say we never talk to any kind of audience about this, all the marketing was postponed to "someday". And at some point, I was not sure we even building something convenient even for us as target customers.

Eventually, we found ourselves burned out not really believing in the idea, and struggling with every tweak of the buggy and clumsy platform we've built. I decided to take a break off even to switch the idea.

Radical descope

However, after a while, I decided that the Feedster is worth trying, and I conducted a radical descope to make it happen at least somehow.

I decided to throw away all UI, queue, and newsfeed, take Notion as a frontend, and build a super simple, synchronous daily digest builder, so far I generate my digest from my local machine using dev mode. Not going to even deploy without a strong reason for doing this. no more engineering for the sake of engineering!

To make my prompts work I passed the Prompt Engineering for Developers course, and find out the best practices (at least the simplest ones), before actually implementing processing I test my prompts a lot using ChatGPT, and only when it started working fair enough I jumped on coding itself.

The Notion-based MVP I made in 3 weeks (and it works!)

The thing is I could make the algorithm of filtering-summarization in just 3 weeks. It still gives bugs and non-relevant info but the small amount of code allows me to tweak it fast, and take immediate feedback in Notion.

The main takeaway - build only the core feature before any secondary infrastructure/UI/optimization. If the core feature doesn't work nothing else matters. It sounds so obvious, but it took almost a year for me to conclude!

Long story short - if something could be cut from your MPV - it should be cut.

The next steps

I really believe that I solve my own problem with this piece of software, and I also, think that I'm not the one.

After being a hermit for the 3 weeks I went out and I have a few ideas on how to both test it for myself and show off to other people.

• My goal is to make it work at least for myself - I will tweak the algorithm, seek useful integrations (one with Reader does seem interesting!), and share how it goes under #buildinpublic and here.

• To prove it works - I will post top peaks from my daily digest, and tuning the algorithm will help me to reduce the effort of manually polishing the output.

• Finally, to let others try - I'm planning to run a “beta by providing an OpenAI API key”, the goal is to make it safe.

• Also, there’s a landing page at the top of my mind. Right now I even don’t know what link to send to a person in case of any questions.

I know that I'm not really trying to validate it so far, but once it works for me I will start to be setting up the Feedster for others who are willing to try.

I'm an engineer and love to be one, that's why building in public always leads me to building, not to marketing, selling, or promotion. But maybe this is the way for me to promote myself as an engineer, and people tend to trust good ones, especially in terms of software.

I know that because in 6 years while I’m here a lot of things have changed and I found out a way to keep up with new technologies, and don’t lose the big picture - that way is having and keeping a Personal Knowledge Base.

What is a knowledge base?

A Personal Knowledge Base is your vault and workspace. It could be a set of folders or linked documents, that you can keep and organize:

• Ideas

• Technologies

• Patterns

• Terms

• Best practices

From the roamresearch.com homepage, linked notes of a Knowledge Base

Any pieces of knowledge you encounter throughout your professional journey. It even could be ongoing projects and high-level architecture design documents. Basically, it serves as a repository of knowledge, allowing you to connect and link different concepts to build a comprehensive understanding of the whole field.

Personal Knowledge Management, in general, is a fast-growing discipline, many techniques and tools are coming up every week, and keeping up with that could be an occupation by itself, however, at some basic level it’s easy to get started.

Try out Evernote for a folder-based approach, Roam Research for a link-based, or Obsidian for a mixed. Notion can also be very handy, it’s a more collaborative workspace and can be overwhelming, but with numerous integrations and great UX, it has become a lovely personal workspace for thousands of software engineers.

Reason 1: Staying Current in a Changing Landscape

Everything new stays on the shoulders of something that already exists. Every day we encounter new technologies, frameworks, tools, or methodologies, and it might be too much to even stay up to date with them.

But often, when you take a look at them, you might start recognizing that you already know what is this: Prisma is just an ORM, but more abstract, Vue 3 is closer to React, and Nest.js is just Angular merged with Spring.

A Knowledge Base here stands for a linkage from old technologies to new ones, from abstract simple terms like ORM and Database to specific technologies, like Mongo and Prisma. So whenever you meet anything new - most probably you will have a clear understanding of how to fit it into your picture of the world, in your technology landscape.

Imagine, how handy it might be to have answers for such questions in interviews or any other technology networking events. “Prisma? Just an ORM for the front end. I even have an example, let me show you…”

Reason 2: Expanding Your Mind

As you can see above - everything new says on something made before, isn’t it mean that even our ideas, projects, and initiatives stay on something that we already know?

Whenever you grow your knowledge base, you also will grow your mind, expand it for new ideas, and at some point, your insights will take a decent place in your own workspace, it could lead to new areas of interest, niches to explore or even new business opportunities!

The thing with continuous learning - we never know where you get to in the end. You just crack topic after topic and find yourself after a while a whole new person.

Reason 3: Freeing Up Mental Space

You might hear: “Our brain is for having ideas, not for storing them”, Dumping your mind on the page is more useful, and more inputs you have.

If you have full-time tasks at work, a couple of pet projects, and a dense backlog to learn, keep in your mind that seems like an unbearable burden, but your personal workspace can handle as much information as you can input, freeing up your mental space along the way, creating more capacity for new ideas and brain clarity.

Reason 4: Enhancing Communication and Expression Skills

“Writing is thinking”, have you heard it before? There’s much more truth in that than it sounds at first point. Often, when I have an idea, which sounds so smart in my head, becomes a dead end while I try to write it down, not losing logical connections between its components.

Writing extremely helps improve your ability to express complex concepts clearly and concisely. When you describe ideas in your own words, you may uncover gaps in your understanding or identify areas that require further exploration.

Your communication skills also grow, even if you write just for yourself in your own knowledge base - your teammates definitely will recognize the improvement of your expression skills after a while.

Reason 5: Enjoyment and Personal Growth

Building and expanding your knowledge base is a fulfilling and enjoyable experience in itself. It’s amazing to see how your knowledge base grows day by day, and what new connections between concepts are found, tools like Obsidian show graphs of your notes, and seeing it grow could be some kind of gamification.

At some point, you can’t keep yourself from starting to share some of your findings with your communities. Maybe even make some serious publications, or just blogging from time to time for personal and professional fulfillment.

Just start

Start from what you already have on your mind. What you use at work, what you are learning, or want/should/have to learn. Instead of just reading the How To article, and instantly applying a guide to your code, take a moment to jot it down to your notes. Whenever you find a good solution - add it to your notes as well.

Connect these findings to each other. For instance, if you found a good way to organize routing in React - connect it to React, Routing, and SPA conceptions in the base. At some point, you will recognize more connections between your notes, and more ideas will come to your mind.

Share your experience and the frameworks you use to keep your knowledge organized.

When it comes to the competitive landscape of interviews for an engineering position, your knowledge and experience do not always directly match the one they expect from you, hence you should learn and adapt throughout your journey, making your mind ready for whatever is asked.

I've built the Four-step Pipeline to enhance my preparation and research strategy, to learn from my failures and so far, it's been incredibly effective.

The steps are:

1. Capture everything you don’t know but seem you should.

2. Consume and distill captured information mindfully.

3. Study what you got, and turn the information into knowledge.

4. Apply it to real projects by creating your own examples.

Keep that in mind - failure is not a termination point but an opportunity for learning, this iterative method reduces the gap between you and a successful job application each time you get failed.

Step 1: Capture

Whenever you are in an interview, or scanning offers on a job board and meet any unknown term or a point of misunderstanding - take a moment to capture it in your notes. Make sure these notes are accessible and easy to review, you’ll need them when you form your Learning Backlog.

Don't just stop at capturing, engage in active research. Google each item, and surf through articles, videos, or other resources available. The goal is to capture fair and useful resources related to each point of misunderstanding. You can use web clipping tools like Instapaper or Notion Web Clipper to fill up your reading pile.

Step 2: Consume

During your dedicated reading time, go through each resource thoroughly, highlighting or bolding key points. Highlight passages whenever you feel like it resonates with you, your goal here is to get maximum from each piece of information but not overwhelm yourself at the same time.

Tools like Readwise can be incredibly useful in collecting and mastering these highlights. The result? A distilled, focused bank of information for further studying and application.

Step 3: Study

Now you're equipped with a concentrated information source, it's time to turn it into personal knowledge. The best way to accomplish this? Rephrase and rewrite the information into your Personal Knowledge Base, linking it with pre-existing notes, and illustrating it with practical examples.

This act of transforming external information into your own words aids retention and helps form a solid understanding of the topic. You can use note-taking apps or, the best, knowledge management tools like Notion, Roam, or Obsidian for that purpose.

Step 4: Apply

The culmination of this process isn't just a reservoir of knowledge but actionable skills that can be employed during interviews and your work. Nevertheless, the application shouldn't be limited to this setting.

Make use of practical platforms to test your knowledge. For instance, while studying architectural patterns, such as the abstract factory, you don't necessarily need to build an entire application. Instead, draft a high-level diagram on Miro or Draw.io using your own examples and ask for feedback from your peers.

You can even show your own examples in an interview when it comes to discussion, proactive knowledge-seeking is much more valuable than the ability to remember the term definition from the study book.

How does it work together? The example

Let's say you went through a job application or have been asked in an interview about Dynamic Programming. When you faced the unknown term, you took a note, now you know you come back to this later, no need to keep it in your mind anymore.

Later on, you met the note while doing research, you searched for this in Google and found a few simple-word articles, you can choose and save for further reading the one that resonates with you the most, which is written in the style you like. Make sure you trust the resources, if it is on the blogging platform - check the comments section.

Now you have a piece of information to review - an entry point to make it yours

When you read the article, highlight anything you think you should know. Sometimes you’ll have to do additional research on some terms, feel free to add your comments and even links to other resources which explain some particular things. You will thank me later when it comes to studying.

In the result, you got a bunch of information blocks. Now it’s time to turn them into your own knowledge. Move these blocks to your Knowledge base, but not just copy-paste but re-write them into your own words. If you come up with examples along the way - perfect! Also, when using a link-based tool (such as Roam or Obsidian) there are a bunch of linked topics you might connect, in our case topics Algorithms, Strings processing, and Graphs would be suitable - it gives you knowledge a context.

Now it is a part of your knowledge, you can claim it is your own

When you are preparing for the interview and expect Dynamic Programming to be asked from you, better to try it out, and actually solve a couple of LeetCode issues using the method you thoroughly studied during the previous steps. Solved it successfully? Copy-paste your solution to the examples section of your note. You will super appreciate this when you’re in an interview!

Learning never stops

Not only for the sake of interviews but every day there’s something you don’t know but you would like to. Keeping your learning pipeline, and constantly tuning it gives you an unfair advantage. Share your stories and methods with me in the comments I would like to learn from you as well!

One day, during our work on a mobile app, we formulated a workflow that was an extension of the traditional one (based on it 90%) but became simple enough to adopt right away. While we used it specifically for our app development, this workflow can be easily adapted for any project that is based on agile development (however, I believe not only).

Three Main Components of the Workflow

Our Git workflow consists of three main parts:

1. Production: This is the sustainable part of the application, represented by the master branch.

2. In Release: This comprises several branches, each associated with features or bug fixes targeted for the next release. These branches are eventually merged into a 'release branch', which is a comprehensive version of the upcoming release, ready for testing, and then, shipping.

3. Hotfix Branches: These branches are a bit unique as they fall outside the main process but follow a strict and specific workflow of their own.

Types of Branches

Here's a more detailed look at the different types of branches within the workflow:

1. Master Branch: This is the branch that's life in production. It represents the most recent, stable version of the application. The main rules to use the Master branch:

   1. Any other branch always begins its journey from Master.

   2. Only Hotfix and release branches could be merged into Master.

2. Feature Branch: Each feature branch is created from the Master branch. Developers work on this branch to build new features from the sprint. To maintain clarity, we try to establish a one-to-one mapping between Feature branches and User Stories. The main rules:

   1. All Feature branches start their journey from the Master.

   2. All defects that occur while testing the release branch should be committed to the Feature branch.

3. Bug-fix Branch: These branches function similarly to Feature branches, created for addressing non-urgent bugs. They are typically part of the sprint, just like User Stories. All the rules are the same as with Feature branches.

4. Release Branch: This is where things get interesting. All tested and production-ready Feature or Bug-fix branches are merged into the Release branch. This branch undergoes a final round of testing before the release. If any fixes are required, they are made in their respective feature branches and then committed back. The key rule here is to avoid direct commits to the Release branch. If a feature needs to be excluded from the release, we can simply reassemble the Release branch without that feature. Rules to keep:

   1. A new Release branch is always made from the Master.

   2. Never commit anything to the release branch - it should be a matter of minutes to destroy the Release branch and assemble a new one.

   3. Release branches are merged into Master when the actual release is performed.

5. Hotfix Branch: Hotfix branches are created directly from the Master branch and merged back once the fix is implemented. These branches handle urgent fixes and are not typically part of the sprint. The rules once again:

   1. We create a Hotfix branch only from the Master

   2. We can merge it back directly when it is tested to not wait until the next release to add a patch.

One case study

A list of branches might not give a full picture of what’s going on, so let's brainstorm some cases and how our workflow is handle them:

Let's say we are working on Release 1.0.1 while Master is 1.0, we have a list of three features, and one bug. Then in the middle of the Sprint, we have the following picture:

• master

• feature/one

• feature/two

• feature/three

• bug/one

We assured the quality of our features independently and start forming a Release branch for integration testing, then we have this picture in Git:

• master

• release/1.0.1

  • merged feature/one

  • merged feature/two

  • merged feature/three

  • merged bug/one

However, we faced something unexpected while testing Feature One, and seems like we can’t make it to the end of the Sprint. All we need here is to cut the feature from the release branch, so if we never commit anything directly we can just

1. Delete our Release branch

2. Create a fresh one from Master

3. Merge everything except our problem-causing Feature One.

Then, at the end of the Sprint, we have something like:

• master

• feature/one - will end it up in the next Sprint.

• release/1.0.1 - polished and ready for shipping.

  • merged feature/two

  • merged feature/three

  • merged bug/one

Not a perfect flow

None of Git flows is perfect, and neither is this one. Here are some drawbacks I can pop up before advice to use it in your project tomorrow:

• Non-linear history - as with any other merge-based Git flow the history here will be a mess. I usually mitigate it via tags in Master if I need to have the ability to travel back in time. We needed it for the mobile app

• Flow with hotfixes is still a mess - whenever you do a hotfix, don't forget to merge the new, fixed master everywhere. If we have many ongoing features or bugs, we will face endless merges if even one is not done, resulting in conflicts.

Let me know what you think! And share your favorite best practices of using Git, no matter if the concept is so simple I still constantly learn and fail.

Whenever you’re asked about Redux, such as "What is Redux?" or "Why use Redux?", you can provide a structured “3 things” answer that includes the main facts about Redux that highlight its three most important features.

These functions make Redux a must-have technology for any application that is more complex than a single-page feedback form:

1️⃣ - There is only one state

2️⃣ - All changes have an explicit interface

3️⃣ - The state is immutable

Let’s go through them one by one.

1. There is only one state

One of the key features of Redux (that comes from Flux) is its centralized state management. Redux provides a central store that holds the entire state of an application. This makes it easier to manage and manipulate the state in a predictable and consistent way.

All components can access the state from the store and dispatch actions to update the state. This also helps to keep the application organized and reduces the risk of the state being scattered throughout the application.

In a nutshell, the Redux store instance is sitting in the React Context on the application level, so if you request the same piece of data from 2 different parts of your application you will get the same result:

const ComponentA = () => {
    // ...
    const user = useSelector(state => state.user)
    // ...
}

const ComponentB = () => {
    // ...
    const user = useSelector(state => state.user)
    // ...
}

These 2 components will get the same user as long as they are nested inside the same context.

2. All changes have an explicit interface

Another important feature of Redux is the way it enforces a predictable data flow. In Redux, all state changes are made through actions that have an explicit interface consisting of a type and a payload.

This means that we can't randomly change our state, and always follow a predictable and lucid flow. By using this interface, we can ensure that state changes are clear and easy to understand.

Let’s break down the flow into steps:

1. To dispatch the action we run a dispatch instance in our React component. Keep in mind that the instance comes from the same React context wrapper as our state.

    const SubmitFormButton = () => {
        // ...
        const handleSubmit = () => {
            dispatch({ 
                type: SUBMIT_FORM
                payload: formData
            })
        }
        // ...
    }
   

2. Under the Store’s hood, all middleware functions are being run. For example, Redux DevTools sees changes and updates its dashboard inside your browser. The same with any other middleware, such as Redux-Thunk or Saga.

3. Then all reducers are being run, that’s how changes are actually being applied.

4. Finally, all listeners are notified that the state has been changed. This is the way how React understands when it should re-render pieces of the interface that depend on the particular slices of data from the Redux.

3. State is immutable

Redux (as a part of the Flux philosophy) follows the principle of immutability, which means that the state is never directly modified.

Why it is important? At the first point, that unlocks an ability to time travel through our application history (using Redux DevTools), and see how data is being changed on each step, it’s never achievable with direct mutation, since middleware won’t be run without a dispatch, exactly the same with notifying listeners after the change was performed.

Also, if you use Redux actions for asynchronous operations (with Thunk or Saga), you want to make sure that your Thunks are being run, as well as DevTools middleware.

In summary, immutability helps us to:

• Do a proper, step-by-step debugging

• Make sure that any connected middleware (such as Redux-Thunk) will be run

• All listeners (such as React components) will be notified

My goal is to help developers understand and embrace programming concepts, so they can apply them in both interviews and day-to-day work. If you know the basics and want to grow further, hop on a train that's headed from developer productivity to high-level solution architecture.