But then again, writing it from the scratch is hard! So recently I started doing this

Steps:

• Run `git diff main... > my-changes.diff`. this is what I run in my target branch.

• get the my-changes.diff

• Upload it to your favourite LLM with this promt "

  Make an MR description for this following code changes. make

  - mr tilte

  - mr description

  I prefer bullet points, conise points, not too much info, give me in read me format

And Done :)

1. Download ollama on your local machine.

2. Install python

3. Get an IDE like PyCharm or VSCode

I could use ChatGPT, Langchain, etc. But I want to understand the AI agent from the core concept. That’s why I am gonna use local LLM and raw Python for now. Will add that complexity over time.

So here is my plan

• Find a project I like or want to make

• Make a small MVP

• Then add layers of complexity over time

• learn new tools or concepts while adding those complexities

• Include my past and previous skills to optimize certain scenarios, if possible. And bridge my backend skills with these new ones.

• Write about my daily progress in my blog as a real-time learning experience.

It’s very common for developers to work on the same files for different reasons. And here comes the problem with updating branches once someone else merges their code before you do.

Usually, there are some known methods

• git rebase

• git merge

In both cases, getting into conflict is pretty common. When you have a conflict, it takes a lot of time and mental energy to resolve it and make sure that they do not overwrite or remove whatever you did.

Sometimes, I even noticed that necessary codes were gone or unnecessary codes were added after resolving the conflict 🫠

So what do I do?

I start with git merge. If the conflict is less than 5-10 lines. I solve it using simple manual conflict resolution.

But if there are lots of conflicts?

• Then I abort the merge.

• I just opened a new branch from the latest main branch.

• And copy the codes from the active feature branch(the branch where the conflict happened) to that new branch

It’s painfully manual work, BUT most of the time those are less than 10 min work and SAFE.

• First, you have to understand the feature or mission at hand.

• Then you need to break those down into smaller technical stories.

• Then you need to execute it.

I also forgot to mention the nitty-gritty details of every aspect of delivery planning, requirements analysis, back-and-forth planning, cross-team dependency, understanding micro and macro level requirements, etc.

A few years ago, I found the MoSCoW method. And since then, it’s been helping me prioritize my work and my team’s work.

MoSCoW is

• Must Have

• Should Have

• Could Have

• Won’t Have

I found this while attending a big non-technical meeting called MoSCoW. The main agenda of the meeting was to set goals for the team/company using this method. I took the idea to use it in tech planning.

So, how does it work in real life?

A simple project requirement: Add a Support ChatBot in the Existing Website (PoC)

Let’s add some imaginary facts/constraints:

• We need it in 4 weeks / 2 sprints

• It’s a PoC

• We will follow agile development

• This feature will have to comply with security features

• This feature will have future support

Our facts will help us navigate through the requirements. Now let’s look into the MoSCoW:

Must Have:

• An interface to send and receive messages

• A BE application to provide read and write APIs

• A DB to store data without user personal info

• Access to an LLM to process the stored data and reply

• User auth-specific validations

• Unit tests in API to e2e flow

Should Have:

• Code should be isolated enough to split it later

• Data should be stored in chunks to support future isolations

• Validation in API fields

• Each function should have unit tests

• Refresh button to reload chat

• Long polling support

Could Have:

• External API should have mocks

• Background processing for the call from the API to the LLM

• Ability to scale the application to 10X

• Async processing for data saving

• Could have access to previous user data

Won’t Have:

• MicroService architecture

• ChatGPT-like thinking

• Chat GPT-like streaming response (HTTP/2 protocol support)

• Vector DB

• Circuit Breaker Pattern

• real-time communication

This is just a quick example I made from the top of my head. We can plan our main features in many ways. The point I am trying to make here is how to use the format to support our need. The rest is up to you.

Nowadays using ORM is common in web development frameworks. A few very common ORMs in Python are SQLAlchemy and Django ORM (django comes with its own ORM).

Almost all ORMs have a common feature called hooks, or signals. Their names may differ, but they work similarly. 👇🏼

This is a great idea in theory. However, maintaining them in real life is incredibly challenging and comes with various costs (of different types).

Let’s see how they look,

SQLAlchemy example

from sqlalchemy import event
from sqlalchemy.orm import sessionmaker


# Create a session factory
Session = sessionmaker()


# Before commit: Triggered right before a transaction is committed
def my_before_commit(session):
    print("Before commit!")

event.listen(Session, "before_commit", my_before_commit)


# After attaching an instance to a session
@event.listens_for(Session, 'after_attach')
def receive_after_attach(session, instance):
    """Triggered when an instance is attached to the session."""


# After a transaction begins
@event.listens_for(Session, 'after_begin')
def receive_after_begin(session, transaction, connection):
    """Triggered when a transaction is initiated."""


# After a bulk delete operation
@event.listens_for(Session, 'after_bulk_delete')
def receive_after_bulk_delete(delete_context):
    """Triggered after a bulk delete operation."""

Django ORM Example

from django.db.models.signals import pre_save, post_save, pre_delete, post_delete
from django.core.signals import request_started, request_finished
from django.dispatch import receiver
from myapp.models import MyModel


# Signal: Before saving an instance
@receiver(pre_save, sender=MyModel)
def before_save(sender, instance, **kwargs):
    print(f"Before saving: {instance}")


# Signal: After saving an instance
@receiver(post_save, sender=MyModel)
def after_save(sender, instance, created, **kwargs):
    if created:
        print(f"New instance created: {instance}")
    else:
        print(f"Instance updated: {instance}")


# Signal: When a request starts
@receiver(request_started)
def on_request_start(sender, **kwargs):
    print("Request started!")

The Problem

In both cases, it’s very easy to add these hooks or signals. And that’s where the next problem arises: as projects grow, this kind of code is often added quickly and scattered across the codebase. Over time, these can be forgotten.

The effects are global.

• New developers: Often don’t know where these magical changes are happening.

• Senior developers: Can forget their existence.

• Team churn: People leave, taking undocumented knowledge with them (and even written documentation gets overlooked or lost 😅).

• Debugging: It takes a lot of time to debug these issues because they work as modules in the middle.

• Refactoring: Becomes difficult when these hooks/signals are deeply embedded.

Here’s a warning directly from Django’s official documentation

Conclusion

Hate is a strong word. I don’t hate these tools. But they are extremely powerful, and as Spider-Man’s uncle said:

With great power comes great responsibility.

Once you set up hooks or signals, they’re very easy to use. There’s no doubt the functionality is fantastic. The main takeaway here is that these features should be maintained properly, generationally, and with raised awareness and knowledge about their usage.

It’s very easy to avoid the pitfalls mentioned above 👆🏼—with a bit of discipline and care.

Author: Austin Kleon

Personal Rating: 5/5

Link: https://austinkleon.com/show-your-work/

Personal Review: Normally it’s weird to give 5 but I felt this resonated a lot with my thoughts. The books is small. Well balanced. You can read them very fast like in 1-2 hr max.
One personal suggestion, you should read each chapter and sit down and think about your own thoughts and process around it.

One of the key points of this book is, it will try to expose our internal talks/thoughts(the things we say in our mind) about our work, about sharing our ideas.

Note: I got this book idea from Ali Abdaal’s YouTube channel.

Quote from the book:

Share what you love, and the people who love the same things will find you.

scoop up the scraps and the residue of your process and shape them into some interesting bit of media that you can share. You have to turn the invisible into something other people can see.

A daily dispatch is even better than a resume or a portfolio, because it shows what we’re working on right now.

Your stories will get better the more you tell them.

Your work is something you do, not who you are.

Beware of selling things that you love: When people are asked to get out their wallets, you find out how much they really value what you do.

The act of sharing is one of generosity — you’re putting something out there because you think it might be helpful or entertaining to someone on the other side of the screen.

The best way to flourish is to retain an amateur’s spirit and embrace uncertainty and the unknown.

The world is changing at such a rapid rate that it’s turning us all into amateurs

Become a documentarian of what you do.

Make stuff you love and talk about stuff you love and you’ll attract people who love that kind of stuff. It’s that simple.

Yes! Yes! I have finally done it, after months of training, injury, retraining, creating new habits, and rediscovering myself 100 times, I did it. I have finally run my first race, a 5 mile/8km run. It is called Dam to Dam Run.

Pre-Context:

In Feb/March, me and my colleagues found out that there is a run happening at September 2024. I was not super sure. But my friends, Anna, and Fabio nudged me a bit and assured me they would help me with my training. And I rode the wave and signed up. Boy oh Boy! I knew I had done a crazy thing, but at the same time, I knew if I did not commit now, it would never happen.

Now at the time I signed up, I had a knee issue. I was not able to walk comfortably or stand comfortably (let alone run). My knee has a half an inch hole(or space-like) stuff. I was absolutely suffering.  Also, I was overweight by 47kg at that time(I am using a standard BMI calculator here).

General Training:

My friends prepped me a couch to 8k Google sheet. Generally, you can find them online or in apps. but this is for a 6-month plan. Where I have different types of running plans on weeks and exercise planning.  But this was also a bit generic. Because I have multiple kinds of stuff like a heavy weight, knee, sleep issue.

This is what I did,

• Core and Muscle exercise 2 times a week

• Swimming once a week

• Special training to fix knees

• Fixing food plans, adding new nutrition

• Reducing Stress

• Fixing Sleeps (trying)

• Saying No to things, that would make break my previous bullet points, Like,

The last point was super super hard. And it kind of helps me realize what it means to set up a routine. And maintaining it

I set up my routine, everything should go perfectly now. No, no no, no! It did not. There has to be more drama.

Drama 1:

Right after, I start running in March. I got sick at the beginning of June. Had a tough fever and I was in bed for 2 weeks-ish. My whole training went down to drain. And I had to rebuild everything from the 3rd week of June. It's like 1 step forward and 2 steps backward.

Drama 2:

Now I again back on track. I almost hit 7.5 km under a nice time. And I was training on a treadmill. But in the last week of August(just 3 weeks shy away the run) got a hip injury out of nowhere. It's called hip bursitis. I was not able to walk, stand, or move. It's like a nightmare. Feels like I would never walk again. Again my friends were supporting me like hell. I went to physio. And the guy helped me with my hip and a lot. And Surprisingly he also helped me with a new running plan.

And Said, do these and visit me one more time. I will fix you(he did not utter these words, but I felt that is what he meant) before your race.

And I did all of them. and visited him. He said you do not need to be fixed. And you will do well in the run.

Final Outcome

Key Takeaways:

I have forced myself into some of the hardest routines for the last few months. Looking back, I feel like I absolutely need them, even if I hate(sarcastic) them.

Some of them are

• No TV while eating

• Reading books after dinner

• Go to bed by 10.30 pm

• Avoiding the food is not good for me. Like gluten, milk-based products. This means all the pasta, bread, pizza, roti, and snacks are gone from my life 😭😭. (This does not mean I do not have them, I have them in moderation)

• Exercise in the morning (no excuses, even if I have to drag myself)

• Stretching is more important than exercise.

• Counting calories I am eating. It does not matter what I am eating, I just have to count them.

• Reduce caffeine, which is bad for sleep

• Be around like-minded people, they will lift you up.

• No social media, this will destroy your mind and mental strength.

There is always time, it's just matter of priority and discipline

A few lines from the internet kept me motivated while doing these

What Would Your ‘Future Self’ Want You To Do now?

Why be normal, when you can be best!

Never say you can't do it. Say, I haven't done it yet, I have not done it Yet!

Discipline is what you hate to do, but doing it like you love it.

The magic you are looking for is in the work you are avoiding.

Training, Obviously! But I had to carve out time. This is what I did,

I went to an adult swimming lesson every Friday Night at 8 pm. from December 2023- July 2024

When I say every week. It's every week, except on holiday. No exceptions for winter nights or sick nights even went swimming 15 min after breaking fast in Ramadan.

What is It?

Finally, I got a Dutch swimming diploma A for adults! Technically that's level 1 (baby level), there are 3 more levels.

To pass the Level A(Level 1) exam, you need to qualify for the following stuff

• Swimming in Clothes: Swim 50 meters (front crawl and backstroke) while wearing full-body tight clothing with a light shoe

• Front Crawl: Swim 25 meters using the front crawl technique.

• Backstroke: Swim 25 meters using the backstroke technique.

• Breaststroke: Swim 25 meters using the breaststroke technique.

• Treading Water: Tread water for at least 15 seconds without moving forward.

• Underwater Swimming: Swim at least 3 meters underwater to pass through a large ‘escape’ hole in a canvas panel without Swim goggles

• Jumping and Swimming: Jump into deep water and swim immediately.

• Floating: Float on the back for a few seconds.

• Safety Skills: Practice basic rescue techniques and safe water exit.

• Water Confidence: Participate in water activities to demonstrate comfort and confidence.

3 years ago in July 2021, I was working in Pathao. We had a massive hackathon event for 3 days. And our team Genjam(in English it means: team Chaos) won the 💫2nd place 💥. This is the first part of the story of what we did and how we did it.

What did we try to solve?

Let’s set the background story first. Pathao is an on-demand digital platform in Bangladesh. But people know it as a ride-sharing, food delivery & parcel delivery company in Bangladesh. And I would say Pathao became the largest tech platform in Bangladesh where the engineers have to solve different varieties of tech problems every day.

With so many interesting existing problems, it’s a bit tough to choose the right one 😅. So what we(team Genjam) did, we tried to find a very old and consistent problem.......

Push Notification aka. Realtime Notification.

Since the beginning of time in Pathao we have been heavily dependent on Google’s FCM. So mainly, whenever we want to send real-time information to any of the users like drivers, customers, or business partners either in the web or mobile app we use Firebase push notifications or web sockets. And we have to maintain millions of HTTP connections with our backend servers.

💡 And in either way those are becoming liabilities.

Why?

• First of all our web-socket service is very old and that does not scale up with our new micro-service architecture that much. Which is slowing us to enable new features in web apps.

• Google FCM is not real-time as that was stated, in Pathao every split second matters. So we needed to send the notification to our driver app within seconds. But sometimes the FCM delivers the messages after 30-60 secs, which literally Pathao can’t afford.

• Sometimes FCM acts weirdly based on geolocation sometimes notification works fine in Bangladesh while lagging notification in Nepal. And that is a nightmare for the support team. Like orders are being canceled, ride-sharing is on hold for an entire city 🙈.

• In a peak time, we are missing almost 15% of all push notifications which should be delivered in real-time daily.

• In peak time, Pathao has to maintain somewhat 100 Million active http connections with backend servers. Which causes a lot of issues.

• Server Outages

• Instant scalability

• Network Bandwidth for servers

• Network Bandwidth for http clients

• Heavy battery draining in mobile clients due to long polling

TBH, Every one of these points has its own reason to get their own attention.

And we thought we should solve this, or at least try to build a technical MVP. Win or lose, this was worth trying, and we can live up to our name Chaos 😂! This solution itself is a chaotic idea 🤯.

What was the idea?

So we were trying to build an architecture with a working prototype called WeJam 📡

💡 💥 A GRPC based communication system for Clients & Servers

🤔 How would that solve anything ⁉️

This architecture/system can have the ability to provide solutions like

• 1 connection between the server & client is enough for receiving and sending data.

• bi-directional ↔️ communication between server and clients.

• No communication lag/loss if the server and client are connected

• this can also solve dependency on FCM.

• Low Network bandwidth usage because of photobuff

• No long polling in mobile apps

• Instant Scalability

• Can be used for push notifications using bi-directional communication

For prototyping we chose these tools/technologies

Tech/Tool Usages gRPC Communication Protocol gRPC web gRPC implantation for Web Apps Envoy Proxy Reverse Proxy for gRPC golang Just another language 🙂 redis for pub/sub communication mysql Just another Database vue.js For showing implementation demo in web app swift For showing implementation demo in Mobile App

So the the prototype WeJam had these features

Server

• Establish gRPC connection between server & client

• Receive data from downstream clients and pass those to proper upstream services

• Receive data from upstream services and route it to proper clients

Mobile

• Build a connection with the upstream gRPC server

• Detect connection health and auto re-connect

• Transfer data through the gRPC connection

Web

• Build a connection with the upstream gRPC server

• Transfer data through the gRPC connection

Some of the features we planned while designing the system but couldn’t implement ☹️ like,

• Implement a message communication system

• Dead letter Queue for missing messages between the gRPC server and clients

What did we do actually?

Stay Tuned for Part 2 :)

Author: Tanya Reilly

Personal Rating: 4/5

Personal Review:

This is a fantastic book!!! I loved it. I would recommend this book to all kinds of software engineers. This is not a coding or technical book. This a handbook on the Sr+ people carrier and future. The topics mostly relate to what, when, how, where, and the nots,  and most importantly the necessary soft skills.

Sr+ engineers can relate the contents and events more easily. It will look like they are reading their life on these 300 pages. I do not know how the writer captured all of my life experiences within this book. I also heard similar things from other sr+/Staff+ people about this book.

Jr or Mid-level Engineers will see a glimpse of leader's life and work. What they are dealing with, and how to deal with them. And what they are expecting in their future careers.

Quote from the book:

If you're the most senior person on the team and you're sloppy, you're going to have a sloppy team

Avoid those "watermelon projects": if the project status is green from one key problem that's going to be impossible to solve, the project status is not really green!

I realized he wasn't slacking: he was intimidated. He'd come from an operations role and had been used to the kind of interrupt driven work where you bounce from fire to fire, rarely getting a block of focus time. This project was his opportunity to begin writing code, but he didn't really believe he could do it, and so he couldn't get started.

If there's any step you can automate, automate it.

The same is true for every temporay hack: if you don't have it in good shape by the end of the project, it's going to take extraordinary effort to clean it up later.

Imposter syndrome is a horrible, insecure feeling: it can even make you do less good work because you don't feel safe taking calculated risks. Take comfort in the fact that it's common, even at this level.

When someone asks you to review a document or pull request or conference talk, do call out the sections that you think are great, but pay them the respect of being(kindly!) honest about their work

I can write 100s of quotes but I think it's better you explore them by reading those.

Link: Amazon Link

Inception

Everything around us is some kind of problem statement. How do you cook, file your taxes, go to new places, make money, do a job, etc? Everything is some kind of problem, and solving problems is my hobby. Most of the time solving a problem consists same kind of things in different wrappers,

1. Know the root cause of the problem

2. Know how to solve the root cause

It's a consistently evolving flow, where we need to discover the root cause then we use our skills to fix the root cause, if we do not have the skills, either we hire/purchase the skill or learn it ourselves. I have written a separate blog on this topic. That can be found here.

For learning a new skill, I have been using a self-driven formula/process for a while. I never made it formalized until recently.

These are my 4 quadrants of solving problems and learning new Things. I have not found time to name it yet. Maybe soon I will find a name.

So How does it work?

I break down my stuff into 3 categories, 1 Action Item

1. Known: Things I already know well, used before. And Comfortable to reuse it in future with very short time to warm up period.

2. Known Unknown: Things I heard of, I know what it can do, I do not know how it can do, I know the top 1 or 2 features of it, I may have used it once or twice in the last couple of years. I need to sit down and spend some dedicated time with it to make myself familiar with it, warm-up time is long.

3. Unknown Unknown: I do not even know about these things. I have never heard of it. There are maybe used in the things I need to use or I am using now. But it's just never ever in my mind

4. Action Item: Things I need to do to move stuff from Unknown Unknown to Known Unknown and Known Unknown to Known.

Also, there is a special relationship here, The more things I know or hear about the easier it becomes to adapt to the Unknown Unknown. Because once we master the basic things, it's easier to reference from one place to another place or make it relatable. Example: If I know how to boil rice, it's easier to know how to boil pasta.

Let's see in action how it works!

Example 1: Learn to Cook Italian Pasta

Example 2: Learn Kubernetes (k8s).

How do I use it?

Whenever I face a new problem or need to learn something new, I use this structured approach to break down the learning process into manageable action items. This method helps avoid feeling overwhelmed and allows for more efficient and effective learning.

Last week, my friend Nushan and I were reminiscing about our old job and the crazy things we did there. We became friends at our first job in the same company, and we did a lot of things that were not part of our job descriptions or even made sense at the time. But somehow, those experiences impacted our lives, shaped our attitudes toward work, and prepared us for new challenges.

Today, I'm going to share one of those stories.

Nushan and I were leading a project at our first office, each from different angles. I handled the technical side, while he managed the project. The goal was to create a system that allowed low-level data to be accessed via an online platform.

After securing the project (let's skip the details of how), we discovered that all the data was on paper. So, our project steps became:

1. Convert analog data to digital

2. Import the digital data

3. Build a system around the data

We were confident in our abilities for steps 2 and 3, but step 1 was a massive challenge.

With the project underway and a ticking clock, we hired 5-6 in-house data entry contractors.

• We purchased desktops and office supplies for their work.

• We set up the workstations with the necessary IT infrastructure.

Once set up, the contractors estimated they'd complete the task in 30 days. However, early data submissions to the project owner revealed a 40% error rate, with issues like spelling mistakes, incorrect info, and missing data.

We were in trouble because we lacked a QA team to check the contractors' work. So...

We became the manual validators. We started by checking the physical paper and verifying the Excel data. We marked errors and asked the contractors to redo their work. It was exhausting!

Things got worse when, after 15 days, 2-3 contractors quit. Now we were short-staffed, with a looming deadline and a high error rate.

Desperate, we joined the data entry efforts ourselves. Instead of coding, we were calculating our data entry rates. Although we were slower than the contractors, our error rate was below 5%. It was a new level of task prioritization.

Our daily routine became:

• 9 am-4/5 pm: Data entry

• 6 pm-8 pm: Data validation

We eventually completed 70% of the project before having to stop due to other complications (a story for another day). This experience taught us several lessons.

Why did we do this? We felt empowered as project leaders and believed we had to finish it by any means necessary.

Why compromise work-life balance? We didn’t understand it then and felt a sense of achievement in reaching milestones.

Doing data entry as a software engineer felt demoralizing, but it taught us the foundational aspects of software development. Behind every polished UI, there are messy, essential processes.

💡 There is a quote by Friedrich Nietzsche: "What doesn’t kill you, makes you stronger." I have mixed feelings about it now. 

We were very unhappy, weird, and did shitty things, but because of those experiences, doing something harder or seemingly impossible seems reasonable or at least viable.

Right now I am living in The Netherlands and I am speaking in English almost 24/7! I am also trying to learn Dutch using English as a base language. But English is not my native language! My native language is Bangla (Bengali). The main complication is that everything is different from English! Letters and everything.

💡 my language has 49 letters, and you can combine letters to form new, different sounds! On the other hand, English has 26 letters and no joining of letters.

Yes, I did get a basic English course as part of my regular studies, but it’s not mandatory anywhere in my country! The subject was an additional one; the rest of the courses were in my native language.

Right now my main focus is to master English so that I can also learn Dutch using it. Plus, mastering a global language has its own perks.

This is what I am doing right now or have done before:

1. Watch lots of English movies, most of the times with subtitles on

2. Watch Japanese anime with English subtitles

3. Watch YouTube videos at 2x speed

4. Listen to podcasts at 1.5x to 2x speed

5. Listen to audiobooks at 1.2x to 2x speed

6. Read any English book and write a summary afterward, even if it takes 6 months to finish the book

7. Write lots of documents in English and spell-check them

8. Write my blogs in English

9. In 2024, rewrite all of my writing with ChatGPT and try to mark what’s missing

10. Recently, I started to read philosophy books and poetry to understand the deeper meanings of words and feelings.

Hello, everyone! I wanted to share my personal journey with insomnia and some tips that have helped me manage it over the years. If you struggle with sleep, this might be a long read, but I hope it helps!

Types of Insomnia

There are three main types of insomnia:

1. Difficulty falling asleep

2. Difficulty staying asleep

3. Waking up feeling tired

A person with insomnia can experience any one type or a combination of two or more. So, the question is, which kind of insomnia do you have?

My Experience

For me, insomnia has been a part of my life for over 15 years. I’m currently treating it, or at least trying to! Throughout my journey, I’ve done a lot of research (since I can’t sleep, I have plenty of time for it!). One significant insight I’ve gained is the connection between sleep and weight loss. Sleep helps burn fat, and lack of sleep increases the appetite for salty and fatty foods (aka junk food). It’s a vicious cycle.

Tips for Better Sleep

Here are some tips and habits that have helped me:

Morning Routine

• Sunlight Exposure: Wake up and go outside to see the sunlight for 60-90 seconds. The sun should be at eye level, typically around 5-6 am. This helps reset your circadian rhythm.

Exercise

• Muscle-Based Exercise: Engage in muscle-based exercises, ideally after 8 pm, to tire yourself out. Aim for 40-50 minutes, three times a week.

• Avoid Late Cardio: Avoid cardio-based exercises after 6 pm.

Evening Routine

• Warm Bath: Take a warm bath one hour before bed.

• Limit Caffeine: Limit coffee to once a day (not after 12 pm); caffeine takes 7-12 hours to wash out of your system. Avoid cola and even hot chocolate as they also contain caffeine. Read the labels!

Hydration

• Drink Water: Drink at least 2 liters of water daily. Online resources can help you determine the right amount based on your weight. Drink water in sips rather than all at once to avoid instant urination without proper absorption.

• Manage Water Intake: I use water bottles with hourly markings placed in different locations at home and work to ensure I always have access and a visual cue to drink.

• Caffeine and Hydration: Remember, coffee also depletes water from your body. Water helps recycle body waste.

Relaxation

• Swimming: Swimming is a very relaxing activity; try it once a week.

• Sunset Exposure: Catch the sundown to help reset your circadian rhythm.

• Supplements: I take supplements to relax my muscles and brain, like magnesium, NAC with inositol, vitamin D, and omega-3.

Diet

• Finish Eating Early: Finish eating 3-4 hours before bed. Establish a routine: eat, drink water, read a book, then go to bed. Make your bed a sacred place only for sleeping.

• Quality Food: I discovered mild intolerances to gluten and cow products. Avoiding these, especially before bed, reduces issues like acid reflux and gas, leading to better sleep.

Nighttime Routine

• Midnight Peeing: Manage water intake to avoid waking up for bathroom trips.

• Avoid Caffeine: Tea also contains caffeine.

• Alternative Stimulants: To get through the day without coffee, tea, or cigarettes, try exercising. If you feel sleepy, take a nap or a 5-minute walk outside.

Technology and Environment

• Sleep Tracking: Monitor your sleep with a good sleep tracking device (not a mobile app; I find them gimmicky). Don’t obsess over sleep reports. If you wake up feeling good, ignore the report. Use the 7-day average reports.

• Phone Settings: My phone is constantly on silent mode. I don't have social media apps on my phone, and all push notifications are off. I reply on my own time. I have a night schedule (10 pm-7 am) on my phone, locking all apps unless I unlock them. I also limit my time on popular video platforms.

• Cool Down: Try to cool down your body during sleep by using fans, bamboo-based bed sheets to soak up sweat, etc.

• Dark Environment: Use a sleep mask to make your environment 100% dark. This is very important. You can also try earplugs.

• Brain Dump: If I have too much on my mind, I write it down. Either I send myself a one-liner email or write everything in a notebook to clear my mind.

Research Materials

Some of the research materials I used:

• Find your chronotype

• Master Your Sleep & Be More Alert When Awake

• Sleep Toolkit: Tools for Optimizing Sleep & Sleep-Wake Timing | Huberman Lab Podcast #84

• How to Fall Asleep Faster | Dr. Gina Poe & Dr. Andrew Huberman

• The 6 Sleep Hacks You NEED! Matthew Walker

• Dr. Matt Walker: The Science & Practice of Perfecting Your Sleep

Author: Barry M O’Reilly

Personal Rating: 4.9/5

Link: https://leanpub.com/residuality

Personal Review:

This is a very interesting book. The author skillfully combines philosophy with software engineering and complex systems (which I am not very familiar with). As someone who works on building software architectures daily, I strongly resonated with this book. It delves into the philosophy behind different ways of solving architectural problems, many of which are already being implemented unofficially by architects. Inspired by this book, I plan to spend more time learning about complex system.

It's a small book, around 90 pages, with lots of breaks in the chapters, making it a fun and easy read. It's a must-read for senior+ engineers. One small critique is that the pricing might seem a bit high compared to the book's content. The price could have been more affordable 🤷🏽‍♂️."

Quote from the book:

In software engineering patterns can be seen as attractors. Attractors are the reason that we are able to engage with complex systems that seem to have innumerable variables-they provide a degree of predictability that is not related to the individual properties of elements of the system.

It is the job of the architect to design a structure for the complicated system that will allow it to survive as the complex context around it changes and moves. This is incredibly difficult as the nature of the complex context means that we cannot know what is going to change and the number of possibilities is enormous. Trying to solve this by somehow predicting the future of the complex context is impossible.

Architecture is the structure of a software application that drives the behavior of a software application in its environment. That is, the way the system responds to scale, load, changes, integrations, and things we normally refer to as non-functional concerns.

The goal of the architect is criticality, not correctness. Correctness is the goal of the programmer and the mathematician. This is one of the first major lessons a becoming architect must learn.

Linear thinkers make excellent programmers. They often come to architecture with a sense of mastery over programming, and often a sense of superiority. It can be quite shocking for many to find themselves outmaneuvered by seemingly lesser programmers who have a knack for lateral thinking and can use their imagination to skip many steps ahead in a single leap. I would venture to say that for the mythical 10X developer, 9X is lateral thinking.

Software architecture is the practice of being consistently wrong until you reach a point of being a little bit less wrong.

A talk by the Author if you do not wanna buy the book:

A few months ago, I went on a trip. While sitting on the train, I kept thinking, "What if I had a diagram for solving problems in general?"

My career revolves around solving problems on a daily basis, and most of the time, I use a similar process for different problems. Below is a simplified version of the diagram illustrating how I solve my day-to-day problems.

This diagram can be applied in many different ways, even in personal life (though some parts may need modification).

Key Elements:

• I Have a Problem: Identify a single, specific problem to address, rather than tackling a batch of problems at once.

• Collect: Gather relevant information and feedback through various means such as calls, chats, emails, or face-to-face conversations. This step is crucial for understanding the problem from different perspectives.

• Idea Validation Process: Enter what I call the R&D mode. This involves experimenting with different ideas and approaches to find the right combination of solutions. It's a hands-on phase where trial and error play a significant role.

• Document It: Keep track of your findings and ideas using tools like whiteboards, Notion, or any other documentation method. This helps in ensuring nothing gets forgotten and you have a clear record of the process.

• Clean Document: This step is about distilling all the noisy data collected into concise, one-liner bullet points. It helps in clarifying the core issues and potential solutions.

• The Solving Part: Once the right problem is defined, finding solutions becomes more straightforward. Often, problems can be deceiving, and the main challenge is identifying the root cause.

Conclusion:

The rest of the solving process becomes easier once the right problem is defined. Solutions are usually quite deterministic once the root cause is identified.

💡 Most of the time, problems can be deceiving, and the key to solving them is finding the root cause.

We all heard about a myth people called Staff Engineers! And what do they do actually? Write code, do they talk the whole day, or sleep yada yada yada!

Inception

I have been working as a Staff Engineer at Protolabs Network since 2023. And I have been fortunate to work with some amazing staff engineers in different workspaces. So when I could not miss the opportunity to give a talk at a small conference arranged by our engineering team. The talk topic was "What does EM/Staff do all day!". Now this blog highlights some aspects of that talk on Staffs role I maintain in the current company.

💡 Every company is different, so are their tech team and their technical needs too. And that impacts the Staff engineer's role as well. This post is just my version of the staff engineer for my current role.

I did a live voting poll to understand what does out audience thinks about us, the staff engineers 😅.

👆, this is what the audience thinks about staff engineers in our company.

The Two Weeks schedule

Instead of explaining everything, here is my two-week calendar! I added some color to make it more sense, and give it a more categorized view. Let me give some brief examples:

• Monitoring: Every morning I start my day by looking into the dashboards, and errors, run some queries to see what happened, and most importantly DataDog/NewRelic.

• Mentoring: Where I actively Work with people to help them with their careers, pair code, sponsor their ideas, etc.

• Any Sync: Any kind of meeting, chatting, having coffee with people to understand the unknown unknowns or everything related to product, tech, future planning, etc.

• Meta Planning Meeting: All of our staff engineers sit down together to talk about planning, issues, meta-level planning, etc.

• Glue: Connect the dots, check issues, take interviews, and anything that connects things to achieve company OKRs.

• Doc Read: You know it 😊

• Doc Write: You already know, what is happening here 😊.  

• POC: Some code writing 😅, which will never go to production(95% time). These activities mostly help me to dive deeper into technologies we are working on and whether we are going to implement them or not 🙏🏼.

• Friday Stuffs/Fun Stuffs: Lot's presentation, demos, retros, socials, etc.

Looking Closer

Here I just tried to combine my activities into higher groups.

• What happened before

• What's happening now

• What's the forecast

• Let's connect them together

• Now let's figure out things for the Future

• Yay, We are Creating history

More specifically:

Inception:

On the other day(a few years ago) I was sending some messages to my tech lead. But every time I sent him some messages, his response was consistent,

Do not send me personal messages in Slack if it's about project work, send the message to the group channels. This way the information will be available to everyone at any time. And if I/you are gone on holiday or leave the company this information will still be available. And there will be less knowledge silo.

Thoughts:

This directive struck me profoundly. Because it takes courage to pose stupid questions(!) in the public channel.  I can always appear as a stupid person, who does not know about simple things!!

On the other side, there might be others who also do not know those answers, who also does not know how to ask the question, who do not know where to ask. And these questions matter (at least to me, to be effective in my job).

Follow Up:

Nowadays I dump so many random questions in so many random channels, instead of asking 1:1s.

Sometimes they appear to be stupid, sometimes they appear to be common knowledge, and sometimes they appear to be important.

Through this process, everyone gains awareness of important questions and their contexts, fostering a collaborative environment. At least that's what I feel.

No such things as a stupid question.

Exception:

Of course, I exercise discretion, refraining from raising sensitive or personal matters in public forums.