Engineering concepts to improve your personal life pt. 2

Ashcir
7 min readJun 3, 2022
Dizzee and F-8 working together to present this post

Hello there again internet. Thank you for the kind reception of my previous post.

Your gracious feedback inspired me to create a series on this topic. Strap in, and let’s go on this adventure together.

In the previous post, I spoke about how life reflects engineering and vice versa. Let’s continue along this theme, and I will share with you another concept I apply in my life that I learnt from practicing software engineering: Incremental changes.

Incremental Changes

Dizzee and F-8 playing Jenga

“There is only one way to eat an elephant: a bite at a time.” — Desmond Tutu

Recall the last time you marveled at an impressive work of digital art. How was the experience? More than likely you admired its holistic form. From a regular perspective it appears to be one continuous piece, but look when you zoom into it you’ll see that it’s discretized. It’s a union of individual pixels working in conjunction to produce a greater goal. Despite each pixel being assigned one color, their integration convinces our brains the artwork is one contiguous display. The whole is the sum of their individual contributions.

The same concept applies to engineering, and systems at an abstract level. Normally this is where I would get on my soap box and begin my rant about how life is an amalgamation of systems, but I’ll save that tirade for a future post.

I speak about software engineering on a frequent basis. Most people I talk to outside of the field envision software as a rigid and static box. They think that software is coded up by magic, then delivered to a customer and never touched again. The reality is quite opposite, I compare software to a garden. You have to plan how you’re going to organize your code, plant your code seeds, water them, and, when it’s done, maintain them by plucking for bugs (pun intended). If you don’t maintain your garden, it will eventually die.

A part of software engineering is designing for enhancements and new features. This aspect of the field is what makes it is a fluid process. With changes comes a risk of failure. “If it’s not broken, don’t fix it” is not applicable in our industry. As engineers we must not fear failure, we must embrace and account for it. Whether it is design failures or misinterpreted requirements, it will happen. When it does we have our contingency plans ready. We introduce changes to our systems in small batches. An effective methodology we use to mitigate the effects of failure is incremental change.

Here’s an example: Medium has a feature that allows writers to see the stats for their stories. I imagine the original ask was “As a writer, I want the ability to see the statistics for the posts that I publish”. The engineers have to implement this new request without breaking the existing functionality of the website. Can you imagine the chaos that would ensue if users could not access the website until the new feature was added?

Here’s a proposed solution for incremental change:

  1. Retrieve a single statistic for one story.
  2. Display a single statistic for one story.
  3. Retrieve multiple statistics for one story.
  4. Display multiple statistics for one story.
  5. Retrieve multiple statistics for many stories.
  6. Display multiple statistics for many stories.

There would be more technical detail for the above tasks, but my point is illustrated. By breaking the ask into smaller parts, the scope of change is also divided, and so is the overall risk associated with the change. This division of the work is often partnered with an agile project management process. This is the process in a nutshell:

Agile management process example
  1. Design for the change.
  2. Implement the change.
  3. Test the change.
  4. Demo the change for feedback, go back to steps 1 or 2 if needed.
  5. Integrate the change.

This process comes with two main advantages:

  1. Early and fast feedback provides confidence that we are building the correct thing.
  2. If a change causes failures, its impact is small and easy to revert.

Overtime, these incremental changes result in a fully formed feature, and an evolved software application.

“So Ashcir, that’s nice and all, but how does this apply to my real life? That’s why I came here in the first place.” Don’t fret, I’m going to explain how to I use the concept in my life, and in others as well.

I’ll start with a personal example. I spent the majority of my day around a desk because of my job, and it got worse post-pandemic. I decided to take up running as a form of exercise and as a way to clear my mind and help with my mental health. I set a goal to run 5K in a decent time, sub 30 minutes to be specific. I knew that I could not start running 5k/day at the beginning unless I wanted to lose the use of my legs for a week. I broke my goal into pieces I could achieve incrementally.

  1. Determine how far I can currently run at a given pace. (3.2 km at the time)
  2. Run that distance at that pace for the week. (3 to 4 days a week)
  3. Increase the distance by 0.5km the following week.
  4. Run that distance at that pace for the week. (3 to 4 days a week)
  5. Repeat until I reached 5km.
  6. Check if the time was sub 30 minutes.
  7. Increase the pace then go back to step 1.

By following that process, I eventually achieved my goal, but then I started losing too much weight, which was a separate issue 😅. Regardless, you can use a similar concept to achieve whatever goals you have.

As I mentioned earlier in the post, it’s important that a feedback mechanism is incorporated into the process. In the running example, I tracked my growth after each run and at the end of the week with my Fitbit. The feedback is crucial for two reasons. It confirms that your method is working, and it rewards you. Being rewarded increases our motivation because we are wired to appreciate progress. Couple the psychological reward with a physical reward (in my case, I treated myself to ramen) to increase the effect and trigger a motivation feedback loop.

Here’s another example, In part 1 of this series I mentioned personal investments and how I view all my assets in one app. What I did not mention was that I accumulated these assets by investing. From my experiences, I realized that many people I spoke to believed that investing is only accessible for wealthy people; that is far from true. You don’t need millions, or even thousands to invest. What is important is that you invest some of your money, a bit at a time. To be clear, when I’m talking about investments, I am not talking about day trading. I’m talking about long-term investments for the future. There are multiple vehicles that facilitate small investments. You can buy ETFs, stocks, and even partial stocks. The incremental investments will grow exponentially in the long term because of compound interest.

If you started with $1000 and you committed to contributing $100 a month, over the span of 5 years and an interest rate of 10% (average stock market return) you will have $8936.63. Compared to $7000 ($1000 + (12*100)*5) if you just saved your money. That’s a difference of $1936.63! That number grows exponentially as your money grows, causing a snowball effect. It’s a reason why the rich keep getting richer.

“Compound interest is the eighth wonder of the world. He who understands it, earns it … he who doesn’t … pays it.” — Albert Einstein

And as a reminder, it’s important to incorporate motivational feedback into the incremental cycle. Personally, I enjoy looking at the figure increase on a monthly basis, but feel free to choose your own.

Remember:

  1. Break your goals into manageable pieces.
  2. Tackle them incrementally.
  3. Incorporate the feedback.
  4. Lastly, don’t forget to reward yourself.

Conclusion

I enjoy software engineering. I’m grateful for the opportunities it has provided me, but I am more grateful for how it broadened my view of the world. I’ve learnt much from those who have come before me, and I enjoy sharing the knowledge and giving back. Life is a series of incremental moments and I hope reading this piece added another pixel to the beautiful collage that is yours.

If you’re interested in reading more posts in this series, let me know, and I’ll continue to put them out. ‘Till next time!

A huge shoutout to Tony Hankerson JR, the illustrator of this post, and his character Dizzee. If you loved his illustrations, you can find him and more of his work over here.

Additionally, I’d like to thank Sebastian Soares for his excellent help with catching my typos and grammatical errors.

--

--

Ashcir

Software engineer by trade; engineering & life blogger; landscape photographer; and teacher by passion. Born and raised Jamaican living in an American world.