Welcome to Coderbased, a software engineering newsletter that helps you to become hands on tech leader. Every week we write about system design, leadership, software engineering mindset or tips to become better Software Engineer.

Before we start, kindly to subscribe, follow me on Linkedin, Twitter and share this content to your friends. Enjoy.

Many software engineers struggle with communication skills, but effective communication is crucial in our field. Strong communication abilities can enhance collaboration, streamline work processes, and even help promote your contributions, leading to recognition and potential promotions.

To begin improving your communication, it's essential to understand the communication styles of your peers and fellow software engineers. Recognizing these styles can significantly improve your relationships, performance, and job satisfaction. This knowledge has opened my perspective on effective communication and helped me identify the right team members for specific roles.

Here are the four main communication styles commonly found among software engineers:

1. Driver Software Engineer

Achiever - Quick - Direct - Competitive

Driver engineers focus on problem-solving and making quick decisions to achieve clear goals efficiently. They generate ideas rapidly and prefer direct communication. Driven by results, they prioritize tasks based on impact and often push themselves and others to meet tight deadlines. Their strong personalities tend to lead them to take charge and expect others to follow.

While they excel in roles where decisiveness and action are valued, they may have little patience for unnecessary discussions or delays. This focus on swift results can sometimes strain relationships with team members who prefer more collaborative or thoughtful discussions, especially if they feel rushed or undervalued.

How to communicate with Driver Software Engineers:

Be direct and concise, focusing on clear outcomes and how your proposal will help achieve their goals quickly. Avoid unnecessary details and emphasize tangible benefits, such as increased efficiency or faster results. If they are insistent on their ideas, respect their need for autonomy and allow them the space to make decisions without micromanagement. It’s wise to prepare backup plans in case things don’t go as expected. Fortunately, driver types often learn quickly from failures.

2. Analytical Software Engineer

Detail - Structural - Data Driven - Cautious

Analytical engineers are also focused on solving problems, but they tend to seek out information, ask questions, and gather details before making plans or decisions. They are methodical, detail-oriented, and highly focused on logic and accuracy. Analytical engineers thrive on data collection and analysis, approaching problems systematically. They prefer to work at a slower, more deliberate pace, ensuring they fully understand a problem before developing a solution. Their meticulous nature often leads them to evaluate all possible options, identify potential risks, and consider long-term outcomes.

However, their desire for thoroughness can lead to "analysis paralysis," causing delays in decision-making and project progress. They may become so caught up in perfecting details or exploring multiple solutions that it slows down the workflow.

How to communicate with Analytical Software Engineers:

Be detailed, logical, and well-prepared. Present facts, data, and clear evidence to support your points, as they value accuracy and thoroughness. Ensure your arguments are well-founded and can be substantiated. Be patient and give them time to analyze information before making decisions. Additionally, structure your discussions by breaking down complex topics into clear, logical steps, and be ready to answer their questions, as they often seek clarification.

3. Amiable Software Engineer

Democracy - Empathetic - Conflict Avoid - Supportive

Amiable engineers are empathetic, approachable, and thrive in collaborative environments. They often prioritize harmony and positive interactions within the team. In simple terms, they want everyone to be happy. Amiable engineers are great listeners and supportive of others, making them effective at mediating conflicts and fostering a positive work culture. When issues arise, they may hesitate to share their ideas until they feel comfortable with the situation. They value consensus and input from others before making decisions.

While they excel in building strong, trusting relationships, their focus on maintaining harmony can sometimes lead them to avoid difficult conversations or necessary confrontations. This tendency may slow down decision-making and lead to unresolved issues. Additionally, their desire to please others can make them reluctant to push back on unreasonable demands or tight deadlines, potentially resulting in overcommitting and blurred boundaries.

How to communicate with Amiable Software Engineers:

Avoid exploiting their kindness by taking on the "bad cop" role. Instead, create a collaborative environment by inviting them to work together. Establish a friendly tone and show genuine interest in their thoughts and feelings. Encourage open dialogue and actively listen to their concerns, ensuring they feel heard and valued. When discussing projects or ideas, frame your suggestions around teamwork and shared goals, as they appreciate collaboration. Be patient and steer clear of aggressive communication styles that may make them uncomfortable. Recognize their contributions and create space for them to express their opinions without pressure.

4. Expressive Software Engineer

Creative - Big Picture - Spontaneous - Optimistic

Expressive engineers enjoy engaging discussions, brainstorming, and collaborating with others. They thrive in dynamic environments and are typically outgoing, easily connecting with their peers. Expressive engineers are effective at inspiring and motivating team members, often thinking outside the box and exploring innovative solutions. However, they may prefer a faster-paced work environment, which can lead to a focus on ideas rather than practical execution. While they enjoy collaboration, they might need reminders to stay on task and follow through with their concepts.

Their emphasis on creativity and enthusiasm can sometimes result in a lack of attention to detail or practical implementation, affecting project timelines. They often generate many ideas but may struggle to maintain focus during the execution phase.

How to communicate with Expressive Software Engineers:

Create an engaging and open environment that encourages idea sharing. Start by showing enthusiasm for their thoughts and contributions, as they thrive on positive reinforcement. Use an interactive approach during discussions, allowing them to express their creativity while keeping the conversation focused. Help them structure and summarize the discussion. Provide clear goals and deadlines to keep them on track while allowing flexibility for their creative input. Lastly, be patient and ready to clarify points, as their expressive nature might lead to fast-paced exchanges that require further explanation.

These are the four communication styles. While each person may exhibit a dominant style, many may also combine two or more styles. Personally, I identify most with the analytical style. What about you? Share your thoughts in the poll below!

Welcome to Coderbased, a software engineering newsletter that helps you to become hands on tech leader. Every week we write about system design, leadership, software engineering mindset, tips to become better Software Engineer.

Before we start, kindly to subscribe, follow me on Linkedin, Twitter and share this content to your friends. Enjoy.

The custom domain feature enables you to use your own domain to access a service, even though, behind the scenes, it’s actually hosted by another service. This feature is commonly offered by SaaS platforms or B2B white-label solutions.

For a simple example, although you're accessing this website through coderbased.com, it’s actually hosted on Substack. Initially, the domain was coderbased.substack.com, provided when we registered our publisher account.

Today, we’re going to discuss how to design a system for a custom domain feature. This is an exciting topic, so let’s dive in.

Building a Custom Domain Feature

Imagine we’re building a Blog-as-a-Service platform similar to Substack, called Blogstraps, and we want to implement a custom domain feature. To understand this better, let’s walk through the user journey on Substack.

When you first create a Blogstraps account, you're provided with a subdomain—let’s say coderbased.blogstraps.com.

In the settings, you can then specify a custom domain, like coderbased.com, and you'll need to update your DNS records with certain values.

1. When you first create a Blogstraps account, you're provided with a subdomain—let’s say coderbased.blogstraps.com.

2. In the settings, you can then specify a custom domain, like coderbased.com, and you'll need to update your DNS records with certain values:

   

3. After this, you submit the request and wait for the DNS propagation

4. Once the DNS propagation is complete, the system processes the custom domain setup. On Substack, this process can take almost a day

How would you design a custom domain feature? Feel free to contribute and share your ideas by filling out the form at this link.

Now, let’s explore our proposed solution.

Build a Custom Domain Using Multi-Tenant System Architecture

Our solution uses the concept of a multi-tenant system architecture. Multi-tenancy allows multiple users or customer groups to access the same application or infrastructure. In MySQL or Postgres, this can be implemented by adding a tenant column. In this case, the domain column can serve this purpose.

Before we go further, we'll focus on how to use multi-tenancy to build the custom domain feature, without diving too deeply into the blog system.

Database Design

Let’s start with database design.

The most important tables and columns for implementing multi-tenancy in a custom domain feature are in the project table:

• domain: Stores the Blogstraps subdomain (e.g., coderbased.blogstraps.com).

• custom_domain: Stores the actual custom domain (e.g., coderbased.com). It’s nullable, meaning if it’s null, no custom domain has been set.

• custom_domain_status: Tracks the status of the custom domain setup with values like:

  • {status: "pending", domain: ""}

  • {status: "processing", domain: "coderbased.com"}

  • {status: "success", domain: "coderbased.com"}

When custom_domain is null, the user accesses the blog via the domain. If custom_domain is set, they can use either domain or custom_domain. We can handle database access like this:

if HasSuffix(host, ".blogstraps.com")
   SELECT * FROM project WHERE domain = {host}
else 
   SELECT * FROM project where custom_domain = {host}

// p.s: Here, host refers to the domain used by the user in their browser.

High Level Design

Before enabling a custom domain, if a user accesses coderbased.blogstraps.com, the request hits a reverse proxy (e.g., NGINX), which then queries Blogstraps' backend system. This is the typical request flow.

When the project owner sets up a custom domain (e.g., coderbased.com), the project table is updated. A worker process periodically checks for new custom domains to process. The worker checks if the DNS for coderbased.com points to the Blogstraps backend.

The owner must configure their DNS settings (using A or CNAME records) to point to Blogstraps' servers, as described in the earlier steps. Once DNS propagation is complete, Blogstraps prepares the custom domain’s route, including redirection, and sets up SSL (using Let’s Encrypt for simplicity).

Once the custom domain is set up, accessing coderbased.blogstraps.com will redirect to coderbased.com, and requests to coderbased.com will go through the Blogstraps backend.

At a high level, it may still be missing a lot of information. To understand more, let’s discuss each use case in detail.

System Behavior Before Custom Domain Setup

Before the custom domain is set, accessing coderbased.com won’t route to Blogstraps System, resulting in a 500 error. However, accessing coderbased.blogstraps.com will work as follows:

1. The request passes through Blogstraps' NGINX.

2. Blogstraps recognizes the host as coderbased.blogstraps.com.

3. It queries the database to fetch the articles:

// Query for accessing articles
SELECT a.* FROM article a 
INNER JOIN project p on a.project_id = p.id 
WHERE p.domain = {host}

Setting Up the Custom Domain

The process begins when the project owner sets the custom_domain (e.g., coderbased.com). At this point, the database reflects this change.

Next, the owner configures the DNS, directing coderbased.com to coderbased.blogstraps.com.

The background worker checks if the DNS has propagated, and once it has, NGINX configurations are updated:

• /etc/nginx/sites-available/coderbased.com

• /etc/nginx/sites-enabled/coderbased.com

At this stage, coderbased.com is connected to the Blogstraps system, but SSL is not yet set. Running sudo certbot --nginx -d coderbased.com will secure the domain using Let’s Encrypt.

For more details, refer to this tutorial

Now, the database state reflects this change:

System Behavior After Custom Domain Setup

After the custom domain is set, accessing coderbased.blogstraps.com will trigger a redirect to coderbased.com via a 301 redirect.

First it will query:

SELECT * FROM project where domain = 'coderbased.blogstraps.com'

Since the query returns data indicating that the custom domain has been set, it will trigger a 301 redirect to coderbased.com

At this point, the user can only access the site through coderbased.com. When the user visits coderbased.com and, for example, wants to query the articles, the system will perform a similar process but will use the custom domain instead of the .blogstraps.com suffix:

SELECT a.* FROM article a 
INNER JOIN project p on a.project_id = p.id 
WHERE p.custom_domain = {host}

That’s all for today. If you have a system design topic you're interested in, or any other interesting system design solution for specific topic, don't hesitate to let me know—I’d be more than happy to share them here.
Propose Topic For Next Post
Propose Your Solution

Subscribe now

Share

Leave a comment

Welcome to Coderbased, a software engineering newsletter that helps you to become hands on tech leader. Every week we write about system design, leadership, software engineering mindset or tips to become better Software Engineer.

Before we start, kindly to subscribe, follow me on Linkedin, Twitter and share this content to your friends. Enjoy.

When I meet technical leaders (such as Heads of Engineering, Engineering Managers or even VP of Engineering) who aren’t technical—who don’t code or understand the technical aspects—I always wonder:

As you advance in a company, especially on the managerial path, you take on responsibilities beyond just writing code. These can include meeting with stakeholders, developing strategies, setting KPIs, and exploring business opportunities.

However, with technology evolving rapidly, if you don’t keep up, you risk losing your technical skills.

Why should technical leaders stay technical?

In my view, it’s essential for tech leaders to remain technical. Here’s why:

Credibility

No software engineer wants a leader who can’t code or doesn’t understand the technical side. Staying technical allows you to empathize with your team and communicate in their language, improving collaboration and earning respect.

On the flip side, a lack of technical knowledge can lead to miscommunication and poor decision-making. You might even be misled—for example, your team could exaggerate the effort or timeline for a project.

Full Control

A tech leader’s top responsibility is hiring or promoting the right people for the right roles. When you’re technical, it’s easier to identify strong engineers, and you won’t feel anxious when someone leaves.

You’re also less reliant on others. For instance, when a critical error arises, you can contribute your insights rather than just waiting and hoping someone else will fix it.

Ultimately, this speeds up development, fosters innovation, and improves troubleshooting.

Empowering the Team

Technical leaders who stay technical are better at empowering their teams. They are seen as leaders, not just bosses. When you set realistic expectations for your team, you become a source of support rather than a burden.

I’ve seen many non-technical leaders assume that certain tasks or projects are easy when they are actually quite difficult—or even impossible. This disconnect leads to frustration and makes them a hindrance instead of a help.

More Impact

Leaders who lose their technical skills often shift their focus to project or people management. I’ve seen this happen frequently, especially at the middle-management level, like Engineering Managers, who end up acting as mere messengers. They can't defend their team with solid technical reasoning, which limits their impact. In the end, they just become another layer, pushing initiatives downward without adding real value.

I firmly believe that strong leadership requires a balance between top-down and bottom-up decision-making. Leaders need to understand both the technical and managerial sides to make a real difference.

P.S. This reminds me of a viral article from last year titled “The Death of Middle Management.” Is this one of the reasons why?

How to Stay Technical as a Leader

Staying technical doesn’t mean micromanaging or doing your team's work. It means ensuring that your skills stay sharp. Here are a few tips on how to do that:

• Attend architecture or high-level design meetings: This keeps you informed about how your company’s systems work and ensures you’re continuously learning.

• Set aside research time: As you move higher in your career, dedicate more time to researching technical topics, not just attending meetings. Research allows you to discover new opportunities, whether by introducing new technology or exploring new solutions. Personal projects can also serve as valuable research.

• Write technical blogs or newsletters: Sharing your knowledge is a great way to reinforce your technical skills. Writing forces you to review what you know and may even inspire further research.

• Delegate and establish SOPs: If you’re pressed for time, consider reviewing which tasks you can delegate or automate with standard operating procedures.

Do you have any other ideas for how technical leaders can stay technical?

That’s all for today. Thank you for reading today's newsletter! If you find it valuable, don’t forget to:

Subscribe now

Share

Leave a comment

Welcome to Coderbased, a software engineering newsletter that helps you to become hands on tech leader. Every week we write about system design, leadership, software engineering mindset, tips to become better Software Engineer.

Before we start, kindly to subscribe, follow me on Linkedin, Twitter and share this content to your friends. Enjoy.

Technical Debt (Tech Debt) is called debt because it represents the technical tasks that need to be done now but are postponed for the future in favor of shortcut solutions.

I may start with something that simple such as improper database design. Then comes small issue. Fix it using workaround. Push the development and add more issue that fix through workaround. Until one day the small issues become greater issues and now it’s hard to solve it.

Technical Debt (Tech Debt) is called "debt" because it refers to the technical work that should be done now but is postponed in favor of quicker, short-term solutions.

It often starts with something simple, like a poorly designed database. Then a small issue comes up. You fix it with a workaround, push forward with development, and add more issues that also get fixed with workarounds. Eventually, those small problems grow into much larger ones, making them difficult—and expensive—to fix.

Tech Debt usually happens for a few reasons:

• Improper system design – A common example is poor database design, often caused by rushed development or an inexperienced engineer.

• Poor code quality – This leads to bugs that are patched with quick fixes instead of proper solutions.

• Using outdated technology – Continuing to rely on old tools that don’t scale or perform well over time.

Tech Debt is dangerous and tricky. Why?

It’s like a ticking time bomb. It builds up slowly, and if left unchecked, it can "explode" into serious issues. What seems like small, manageable problems at first can snowball into something much bigger.

For non-technical people, it may not seem like a big deal, and the impact of not addressing these issues isn’t always clear—until it’s too late.

That’s why, in many companies without strong engineering leadership, management often prioritizes fast development and growth, overlooking the need for proper processes. Eventually, though, the debt catches up, and it has to be paid.

Stages of Tech Debt

Level 1: Minimal Impact

At Level 1, there are some reported issues, but they’re still minimal.

• Fixes are easy and don’t slow down development.

• All stakeholders, including engineers, product teams, and ops, are content.

• Business continues as usual with no major disruptions.

Level 2: Emerging Problems

At Level 2, the number of reported issues begins to grow.

• Workarounds or "band-aid" fixes become common to prevent breaking existing features.

• Productivity is slightly impacted, but things remain under control.

• The product and engineering teams start spending more time on ad hoc issues, though it's still manageable.

Level 3: Increasing Complexity

At Level 3, issues arise almost daily.

• Fixes become more difficult, and past technical decisions become major roadblocks.

• Productivity noticeably declines.

• Product and engineering teams work overtime to keep things running, patching issues as they arise.

Level 4: Critical Breakdown

At Level 4, issues are constant.

• Frequent outages, performance issues, and cascading failures are common.

• Every bug fix or update introduces new problems.

• New features are either impossible or incredibly expensive to implement.

• Stakeholders are experiencing burnout.

• Teams outside engineering, such as ops and business, begin losing trust in the tech teams.

What to Do if You’re Already at Level 4?

At Level 4, it’s not just the company that’s suffering financially due to the instability of the application—it also affects team morale and culture. To avoid reaching this point, prevention is key. Scheduling regular "tech debt payments" can help keep issues from spiraling out of control.

But what if your company is already at Level 4? Before jumping into solutions, ensure that management understands the severity of the situation.

At this stage, your system likely has deep architectural problems. It’s similar to having a house with a crumbling foundation—you can’t add new rooms or floors until you fix the base structure.

Here’s how you can approach it:

• Hire an Expert
  You need a skilled software architect. If you don’t have one, hire a full-time expert or a fractional architect who can help restructure the system.

• Commit to Long-Term Fixes
  Reducing tech debt from Level 4 to Level 1 takes time, energy, and resources. This requires strong commitment from management and collaboration across all teams.

There are two main approaches:

1. Hard Reset:
   Halt all development. The system might remain unstable, but focus all resources on laying a new foundation.

2. Create a SWAT Team:
   Minor changes are allowed, but major changes are prohibited. The current team continues firefighting, while a new SWAT team, led by the best architect and highest leader, lays the groundwork for a new system and handles the migration.

That’s all for today. How’s your company’s tech debt situation? Comment below! Thank you for reading today's newsletter! If you find it valuable, don’t forget to:

Subscribe now

Share

Leave a comment

Welcome to Coderbased, a system design newsletter that literally about designing a system that become foundation of a product and feature

Before we start, kindly to subscribe, follow me on Linkedin, Twitter and share this content to your friends. Enjoy.

As an engineer who has worked extensively using laptop, I love using WhatsApp over the web. One feature that stands out to me is the authentication process. It's incredibly easy, seamless, and provides an excellent user experience.

Since WhatsApp is primarily a mobile-first application, we don’t see this type of authentication method often. However, it’s still fascinating to break down how this feature works. While it’s not overly complex, it’s certainly cool to build. So, let's dive in.

Building Whatsapp Web QR Code Authentication

Imagine we have a chat application similar to WhatsApp called Coderbased Chat, and we want to implement a web authentication feature similar to WhatsApp’s. Before we proceed, let’s understand how WhatsApp’s authentication process works.

WhatsApp, being mobile-first, doesn’t use the typical methods like entering a password or receiving an OTP to log into the web version. Instead, the process is as follows:

1. Authenticate on the mobile app.

2. Visit web.whatsapp.com, which will display a QR code.

3. Scan the QR code using the WhatsApp app on your phone.

4. Done! You’re now authenticated on the web version and can start chatting.

For a visual reference, check out the illustration below..

Similar to WhatsApp, when you visit chat.coderbased.com, it will display a similar UI, including a QR code that can be scanned using the Coderbased App for authentication.

Additionally, to make the challenge more interesting, we’ve added another requirement: when the mobile app logs out (whether the session expires or the account is banned), the website should automatically log out as well.

How would you design a system for WhatsApp Web QR Code authentication? Feel free to contribute and share your ideas by filling out the form at this link.

Now let’s go into our proposed solution

Proposed Solution

At a high level, there are several key components involved in building this feature:

1. Mobile App (must already be authenticated)

2. Website

3. Chat Service: This service maintains the connection (via WebSocket) to bridge the system and frontend (both the website and mobile app).
   It's common in chat systems to use WebSocket for two-way, real-time communication.

4. Auth Service: Provides authentication information and tokens.

Here are the steps and ideas to make this feature work:

1. The website requests a code/token/ID, but let's call it a Guest Token from the Chat Service, which is displayed as a QR code.

2. The authenticated mobile app scans the QR code and retrieves the Guest Token.

3. The Auth Token (from the mobile app) and the Guest Token are forwarded to the Auth Service.

4. The Auth Service generates a new token specifically for the website, called the Web Auth Token.

5. The Web Auth Token is sent back to the website through the Chat Service (via WebSocket).

6. The website reinitializes its connection to the Chat Service, now using the Web Auth Token.

To understand more, let’s break down the details:

Website (Guest State): Generating the QR Code

The website operates in two states:

• Guest State: Displayed when there is no Web Auth Token stored in the browser.

• Authenticated State: Displayed when there is a valid Web Auth Token stored in the browser.

By default, when a user first visits the website, it opens in Guest State, displaying the QR code for authentication.

To generate this QR code, the website connects to the Chat Service through WebSocket, identifying itself as a Guest. The Chat Service then generates the Guest Token.

Mobile App: Scanning the QR Code

Now that the QR code is displayed on the website (from the Guest Token), the mobile app can scan it.

So, what happens when the QR code is scanned?

After scanning, the mobile app retrieves the Guest Token and sends both the Auth Token (from the mobile app) and the Guest Token to the Auth Service. These tokens are used to generate a new Web Auth Token.

The Web Auth Token is then sent to the website (browser) by notifying the Chat Service. The Chat Service, which manages all WebSocket connections, is able to send the token to the correct recipient.

Website (Authenticated State)

Once the Web Auth Token is received, there are two possible scenarios:

1. Valid Token

2. Invalid Token (e.g., expired, banned, logged out, etc.)

Upon receiving the token, the website reinitializes by sending a message to the Chat Service via WebSocket.

If the authentication is valid, the website switches from Guest State → Authenticated State, enabling full access to chat features similar to the mobile app.

Mobile App: Logout Scenario

There are two scenarios when the mobile app triggers a logout:

1. The website is not connected (no user is currently connected via the website). They may connect in the future.

2. The website is connected, and the expectation is that the website will automatically log out in real time.

In the first scenario, when the user later opens the website, it will reinitialize its connection to the WebSocket. During the authentication step, the Auth Service will reject the request, signaling the website to return to Guest State.

In the second scenario, the process is similar to scanning the QR code. When the mobile app triggers a logout, the Auth Service notifies the Chat Service, which sends a signal to the active connection on the website, prompting it to log out. Check the picture below

That’s all for today. If you have a system design topic you're interested in, or any other interesting system design solution for specific topic, don't hesitate to let me know—I’d be more than happy to share them here.
Propose Topic For Next Post
Propose Your Solution

Subscribe now

Share

Leave a comment

Welcome to Coderbased, a system design newsletter that literally about designing a system that become foundation of a product and feature.

Before we start, kindly to subscribe, follow me on Linkedin, Twitter and share this content to your friends. Enjoy.

With US Election Day approaching, I’ve been thinking about designing a system for online voting. While voting systems may seem simple, handling hundreds of millions of votes within a short time frame could present significant challenges.

Building an Online Voting System

Requirements & Scope

In this system design challenge, we are tasked with creating an online voting system for an election scheduled on day X in the year 2024, with 250 million voters expected to participate between 08:00 AM and 12:00 PM. The system must be designed to handle and withstand heavy traffic.

Detailed Requirements & Scope:

• Authentication and security are out of scope. The focus is on building a system capable of handling high traffic.

• An estimated 250 million voters are expected to participate.

• Each user can vote for one candidate from two or more options.

• Users cannot vote more than once. If a second attempt is made, the first vote will be counted.

• Users should be able to view real-time results for each state. “Real-time” means a user perceives it as real-time, so a delay of one or two minutes is acceptable.

For more clarity, see the illustration below.

Breaking Down the Challenge

Before diving into the solution, it's important to understand why this task is challenging. Designing an online voting system for low traffic might be straightforward, but managing high traffic at this scale is much more complex.

Typically, the traffic pattern shows a sharp spike in the first 5-10 minutes, after which it starts to flatten. This initial peak is the critical point where the system must be designed to handle the load.

There are two main use cases to address in an online voting system: inserting votes and showing live results.

Challenges in Displaying Live Results

Let’s assume that at least 50% of voters will cast their votes during the peak period (5 after voting opens). This translates to:

125 million voters ÷ 5 minutes = around 400,000 requests per second (RPS).

Given the unpredictability of traffic spikes, we should scale for 2x-4x the estimated load, meaning the system must handle at least 1 to 2 million RPS during peak times.

Challenges in Votes Submission

High traffic with numerous simultaneous insertions into the database can cause significant delays. A single insert query to databases like MySQL or Postgres typically takes 2-5ms. So, what happens when there are 10 million inserts?

10,000,000 × 2ms (optimistic scenario) = 5.5 hours.

Given the expectation of more than 10 million requests within the first 5 minutes, inserting them all directly into the database would take 5.5 hours. For 250 million votes, it would take approximately 138 hours (5.7 days).

Basically,tThe main challenge in designing an online voting system for an election is efficiently handling high read and high write loads simultaneously.

Question: How do you design a system that can handle hundred millions online voting for election? Feel free to contribute and share it by filling out the form at this link.

Now let’s go to our proposed solution

Proposed Solution

At a high level, we propose the system design shown in the picture above. Let’s break down each component:

• Database (Vote DB): We will use MySQL or Postgres because we need ACID properties. For this solution, we will use Postgres.

• Vote Input Service: This service handles voting submissions from voters and logs them in a vote log file. We will discuss the specifics later.

• Vote DB Service: This service processes the vote log file and inserts the data into the Postgres database in bulk.

• Vote Summarizer Service: Instead of calculating results directly from the database for every request, this service will run every minute, query the data, and cache the required information (in this case, using Redis) for displaying results.

• Vote Result Service: This service is a layer that presents the vote results from the Redis cache.

Handling Votes Submission Use Case

Here’s the idea: we cannot write every request directly into the database, so we need to insert votes in bulk.

Why?

Inserting a large number of records one-by-one is inefficient and resource-intensive. The back-and-forth communication consumes a lot of I/O resources. Let’s compare single inserts to bulk inserts:

• A single insert requires 2-5 ms.

• A bulk insert (5000 records) requires 20-25 ms.

Calculation:

(250 million records ÷ 5000) * 25 ms = 21 minutes

This means that between 08:00 AM and 08:21 AM, there might be a queue of data waiting to be inserted. After that, the system will process in near real-time. I believe this still offers a good real-time experience.

Next, How do we handle bulk insertion?

We need to queue vote data into a persistent system. The simplest solution is to use a log file, where every data entry posted through the Vote Input Service is appended to a persistent log file.

There are 4 stages that the log file will go through until the data is bulk-inserted into the database:

• Current: Every minute, the Vote Input Service will open a single current file, indicated by the hour and minute in its name. For example, if the current time is 08:02:33 AM, the file will be named voting-08:02.log.current. When a vote was submitted, it will be appended to this file.

• Waiting: Every minute, the current file is closed and renamed to a waiting file. The naming pattern will change to something like voting-08:02.log.waiting.

• Ready: The waiting file may contain more than 5000 records (or however many you choose for each chunk). The Vote DB Service will split the file into smaller ready files. For example, if voting-08:00.log.waiting contains 12,000 records, it will be split into:

  • voting-08:00.log.1.ready (5000 datas)

  • voting-08:00.log.2.ready (5000 datas)

  • voting-08:00.log.3.ready (2000 datas)

• Done: The Vote DB Service has another cron job that detects ready files, processes them, and bulk inserts the data into the database. After a successful insertion, the files are renamed to done, for example:

  • voting-08:00.log.1.ready → voting-08:00.log.1.done

  • voting-08:00.log.2.ready → voting-08:00.log.3.done

  • voting-08:00.log.2.ready → voting-08:00.log.3.done

Handling Showing Vote Result

Now that inserting vote data into the database is clear, we need to handle how to display the vote results, where traffic can be much higher than for vote submissions.

There’s nothing particularly complex about the database design; it can be kept simple, as shown in the diagram above.

If we want to display the result based on who’s winning in each state, as illustrated in the product example, a simple query like this could work:

SELECT s.state, v.candidate, count(vo.*) as total_vote
FROM vote v 
INNER JOIN voter vo on vo.identity_card_number = v. identity_card_number
INNER JOIN state s on s.id = vo.state
GROUP BY s.state, v.candidate

However, running this query for every request is not scalable. Therefore, we need to implement a caching mechanism.

A typical caching mechanism using Redis follows this flow:

1. Hit the Vote Result Service.

2. Check Redis for cached data.

3. If cached, return the data.

4. If not cached, query the database and cache the result.

We cannot use this approach because it can lead to inconsistencies between different virtual machines (VMs), especially if we plan to scale horizontally. Inconsistent data is likely because vote data is increasing rapidly.

That’s why the Vote Summarizer Service is essential. This service will run a scheduled job (cron) that executes the query mentioned above and stores the result in Redis as a cache.

Since Redis would be a single point of failure in this setup, we need to implement Redis replication (e.g., primary and slave).

With this design, when a viewer requests the vote results, they will hit the Vote Result Service, which retrieves the data from the Redis cache. This approach is highly scalable—we only need to scale the service and Redis replication.

Note: To make the website appear real-time, it can implement a timer to refresh and re-request the data from the Vote Result Service.

That’s all for today. If you have a system design topic you're interested in, or any other interesting system design solution for specific topic, don't hesitate to let me know—I’d be more than happy to share them here.
Propose Topic For Next Post
Propose Your Solution

Subscribe now

Share

Leave a comment

Welcome to Coderbased, a system design newsletter that literally about designing a system that become foundation of a product and feature.

Before we start, kindly to subscribe, follow me on Linkedin, Twitter and share this content to your friends. Enjoy.

Hi, long time no see! We are rebranding as Coderbased, a community for coders focused on system design to build products and features. You can read more about why we decided to rebrand and focus on this specific concept here.

Product & System Requirements

Suppose we are software engineers for an enterprise company with an in-house ERP system. The ERP system includes a purchase module that allows employees to create purchase requests.

We have been asked to enhance the system by developing a multi-level approval process for purchase requests. For example, when an employee submits a purchase request, it needs to be approved by their supervisor. After the supervisor approves it, the request must then be approved by the manager before it can be executed.

Employee → Supervisor → Manager (2-Level Approval).

Requirements & Scope:

While, ideally, the ERP system would require a multi-level approval process for almost all documents, let's focus solely on purchase requests (so we don't need to develop an agnostic approval system).

• The number of levels (stages) can be unlimited.

• Approvers can be based on the line of superiority or selected as specific individuals.

• A minimum number of approvers can be set before the workflow advances to the next level.

• There can be rules based on the amount of the purchase request. For example:

  • If the request is <$100, it needs only one level of approval by a superior.

  • If the amount is ≥$100, it requires approval up to the managerial level.

• You can make assumptions regarding the employee structure (line of superiority).

To understand more, check the product illustration below.

Before we present the proposed solution, we believe there are many ways to design a system to solve problems. If you have a different idea, we encourage you to contribute and share it by filling out the form at this link.

We will post your solution if it is good and effectively solves the problem.

Proposed Solution

High Level Design & Architecture

At a high level, there are four components and technologies that we use to solve the multi-approval system:

1. Purchase Service: Manages purchasing data and flow, including purchase requests.

2. Approval Service: Manages approval configurations and the actual approval transactions for specific purchase requests.

3. Postgres or MySQL: Both are ACID-compliant databases, which are crucial for an enterprise system. In this case, we are using Postgres.

4. Message Broker (RabbitMQ or Kafka): Facilitates asynchronous communication between the Purchase Service and the Approval Service, ensuring they remain loosely coupled.

There are two main user flows required to handle the multi-level approval process:

• Purchase Request Creation: When an employee creates a purchase request, it will go through the existing Purchase Service. In our proposed solution, an additional step will inform the Approval Service to prepare approval transaction data based on the configured rules.

• Approval Flow: After the purchase request is created, its status will be set to WAIT_APPROVAL. The approval process will then proceed sequentially through stages 1, 2, and so on. If the request is rejected or all stages are approved, the Approval Service will inform the Purchase Service via the message broker, updating the status to APPROVED or REJECTED

We'll dive into the details of how this works in the use case section below.

Database Diagram (Schema)

There are four main tables for the multi-level approval system: three for configuration and one for actual transactions:

• pr_approval_workflow: This is the main table for configuring the approval workflow. You can apply rules based on the purchase request amount by setting min_amount and max_amount. If more than one rule is applied, the workflow with the higher weight will be selected.

• pr_approval_employee: This table indicates who is eligible for a specific workflow. If employee_id is set to *, it means the workflow is applicable to all employees.

• pr_approval_workflow_stage: This table configures the stages/levels of the workflow, including who the approvers are and how many approvals are required before moving to the next level.

• pr_approval_transaction: This table records the actual approval transactions, with a direct relation to the purchase request data.

Let’s Breakdown the Design One by One

Approval Workflow Configuration

The first thing we need to do is to define the workflow configuration, with at least one workflow needing to be designed. To make this clearer, let's use some data examples.

• Unlimited level configuration
  Let's look at the pr_approval_workflow and pr_approval_workflow_stage tables. With this setup, we can create unlimited approval levels. For example, "workflow 1" has a single approval level, while "workflow 2" has three levels of approval

• Purchase Request Amount-Based Rule:
  In the pr_approval_workflow table, workflows with IDs 1 and 2 are both eligible for all employees. However, the min_amount and max_amount fields are set so that purchase requests up to $100 will follow "workflow 1," while anything above $100 will follow "workflow 2."

• Specific Workflow by Weight:
  We can use the weight field for specific cases. For example, if a head-level employee makes a request over $100, they may only need approval directly from the CTO.

Create Purchase Request Flow

What happens in the Approval Service when a purchase request is created?

Step 1: Identify the Applicable Workflow

Find the specific workflow that applies based on the eligible employee, purchase amount, and workflow weight.

SELECT paw.* 
FROM pr_approval_workflow paw
INNER JOIN pr_approval_workflow_employee pawe on pawe.workflow_id = paw.id
WHERE pawe.employee_id in ('*', <employee id>)
AND <purchase request amount> BETWEEN paw.min_amount AND paw.max_amount
ORDER BY paw.weight desc 
LIMIT 1

Step 2: Populate pr_approval_transaction
Next, fill the pr_approval_transaction table using data from pr_approval_workflow_stage and the employee table.

Assume the requester is STF-001 (Phillip McDaniel), and the request amount is $100, so "workflow 2" will be applied. The expected result would look like the image below.

Columns id, purchase_request_id, workflow_id, workflow_stage_id, level, and approver_count should replicate the data from the pr_approval_workflow_stage table.

Columns approver_list, reject_list, and status columns will be filled with default values since no one has approved or rejected the transaction yet. The status WAIT_APPROVAL indicates that the transaction is the currently active level.

The tricky part is the approver column, which is populated based on the approver_type from the pr_approval_workflow_stage table:

• If approver_type is EMPLOYEE, fill the column with the approver_id from the pr_approval_workflow_stage table.

• If approver_type is SUPERIOR, find the approver from the employee table. The approver_superior_level column in the pr_approval_workflow_stage table indicates how many levels above the requester the approver is:

  • 1 = direct superior

  • 2 = superior of the superior

  • 3 = superior of the superior's superior

  • and so on.

Approval Flow

Approval Level 1

The approval flow is straightforward. Every approver who needs to approve a transaction simply queries the pr_approval_transaction table. In this example, the first approver is SPV-001 (Sophie Sims), so:

SELECT * FROM pr_approval_transaction pat
WHERE 'SPV-001' = any(pat.approver)
AND status = 'WAIT_APPROVAL'

The query above will show all approval transactions that need to be approved or rejected by SPV-001.

• If a transaction is rejected, the Approval Service will publish a message to the Message Broker, which will notify the Purchase Service to change the purchase request status from WAIT_APPROVAL → REJECTED.

• If a transaction is approved, the next level (stage) of the approval process must be identified, and the status (of next level approval process) should be changed from PENDING to WAIT_APPROVAL:

UPDATE pr_approval_transaction SET status = 'APPROVED' WHERE id = $1

UPDATE pr_approval_transaction 
SET status = 'WAIT_APPROVAL'
WHERE workflow_id = <current workflow_id> 
AND level = <current level + 1>

Approval Level 2

The flow for Level 2 is similar to Level 1, but since MGR-1 is the approver at this level, the query is:

SELECT * FROM pr_approval_transaction pat
WHERE 'MGR-1' = any(pat.approver)
AND status = 'WAIT_APPROVAL'

If approved, the process is updated to the next level:

UPDATE pr_approval_transaction SET status = 'APPROVED' WHERE id = $1

UPDATE pr_approval_transaction 
SET status = 'WAIT_APPROVAL'
WHERE workflow_id = <current workflow_id> 
AND level = <current level + 1>

Approval Level 3 (Final Level)

The flow for Level 3 is similar to Levels 1 and 2, but since PMG-1 is the approver at this level, the query is:

SELECT * FROM pr_approval_transaction pat
WHERE 'PMG-1' = any(pat.approver)
AND status = 'WAIT_APPROVAL'

If the transaction is rejected, a notification will be sent. If all levels are approved, the process continues as follows:

UPDATE pr_approval_transaction SET status = 'APPROVED' WHERE id = $1

UPDATE pr_approval_transaction 
SET status = 'WAIT_APPROVAL'
WHERE workflow_id = <current workflow_id> 
AND level = <current level + 1>

At this point, the last update statement will return no results since Level 3 is the final approval level. In this case, we need to trigger a message with ALL_APPROVED to the Message Broker, which will notify the Purchase Service to change the “purchase request status” from WAIT_APPROVAL → APPROVED.

That’s all for today. If you have a system design topic you're interested in, or any other interesting system design solution for specific topic, don't hesitate to let me know—I’d be more than happy to share them here.
Propose Topic For Next Post
Propose Your Solution

Subscribe now

Share

Leave a comment

Welcome to Coderbased, a newsletter designed to help you become a bit better at software engineering. We are grounded in real-world experience, not just theory and concepts. Learn one bit at a time.

Before we start, kindly to subscribe, follow me on Linkedin, Twitter and share this content to your friends. Enjoy.

When we talk about improving application or system speed, caching is often one of the first things that comes to mind. And when it comes to caching, Redis is probably the first tool you think of.

Redis caching has been extensively discussed, so I won't rehash the basics. Instead, I want to focus on what software engineers often overlook when using Redis as a cache. These oversights can lead to potential bugs or inefficiencies.

Let’s go to the list.

1. Forgetting to Invalidate or Clear Redis Cache

Imagine you have an API that provides product pricing. Because your site receives high traffic, you cache the product information, including prices.

A common mistake engineers make is forgetting to invalidate or clear the cache when prices change.

For instance, if the price changes from $100 to $120, some users might still see the old $100 price if the cache isn’t properly updated.

Always plan when and how you’ll invalidate the cache to avoid these inconsistencies.

How to clear redis cache? either use TTL or DEL. In this case when the price getting update we need to trigger DEL statement

DEL product:1

2. Not Caching "Not Found" Responses

Let’s say you have an API to fetch product information by ID:

https://api.site.com/product/1

If the latest product ID in the database is 50, then IDs like 51, 52, and so on don't exist. Many engineers skip caching these "not found" responses, but this can be problematic.

When requests bypass the cache, the whole purpose of caching is undermined. In the real world, there might be cases where data existed before but no longer does, yet people still access it, perhaps through Google’s indexing. In a high-traffic environment, this can overload your server.

So, don’t forget to cache the "not found" responses as well. For example, you could cache it like this:

SET product:51 "{}"

3. Using Redis Cache in Non-Atomic Operations

A typical approach when using Redis for caching might look like this:

GET → Process → SET

If the GET statement finds the data in Redis, you return it. But if it doesn’t, the system must perform some processing and then cache the result with a SET statement.

The problem arises in the time between the GET and SET operations. While this approach might work fine in many cases, if the process is complex, resource-intensive, or time-consuming, it can lead to a thundering herd problem.

When the process takes a long time, every request bypasses the cache, putting extra strain on the server.

Suggestion: Evaluate the complexity of your logic before applying Redis caching. You can use a single-flight mechanism to ensure that when one process is being handled by the server, other requests wait until the cache is updated. Consider using SETNX for this.

4. Forgetting to Warm Up the Cache

When Redis is restarted or redeployed, the cache is often empty, which can lead to a spike in requests as the cache is rebuilt. If your application can handle this spike, you’re fine. But in many high-traffic environments, this can cause the system to go down.

To avoid this, set up Redis persistence and pre-fill the cache before starting the application. Warming up the cache ensures that it’s not empty when the application goes live.

Did you find other things that software engineers often overlook or forget? Please comment below

Subscribe now

Share

Leave a comment

Welcome to The Scalable, blog and newsletter to help you faster in becoming tech leader. Check our tech lead roadmaps.

Before we start, kindly to subscribe, follow me on Threads & Linkedin and share this content to your friends. Enjoy.

Quick Links:

• Intro

• Reproduce the Bugs

• Find the Root Cause

• Fix & Test

• TL;DR

Intro

In programming, "bugs" refer to errors or defects in a software program that cause it to behave in unexpected or unintended ways.

Writing perfect code without bugs is hard to achieve, and it’s inevitable to have bugs. That’s why debugging is a must-have skill for software engineers. Debugging is the process of identifying, analyzing, and removing bugs or defects from a software program.

While it's a must-have skill, many software engineers don't know how to debug. When they encounter a bug, they tend to resort to blind guessing, resulting in poor decision-making. Sometimes, they fail to fix the root cause, and even worse, it may lead to the generation of new bugs.

So, in today's issue, we are going to talk about the debugging process, which generally involves three stages:

1. Reproduce Bugs

2. Find the Root Cause

3. Fix & Test

Reproduce the Bugs

The first thing we need to do when we encounter bugs is to find out how to reproduce it. Reproducing the bugs means we need to understand step-by-step how to trigger the bugs to happen.

The purpose of reproduce bugs are to identify:

• Trigger Point (on button clicked, on page load, endpoint hit, etc.)

• Actual Behavior

• Expected Behavior

If we are able to reproduce the bugs, it becomes easier to solve them and ensure whether they are really resolved or just partially fixed.

There are two types of bugs in terms of occurence:

1. Consistent bugs: These bugs occur every time we follow the reproduction steps, consistently producing the bugs.

2. Intermittent bugs: When we follow the reproduction steps, sometimes the bugs occur, and sometimes they do not.

In my experience, if we encounter an intermittent bug, the first thing we need to do is find the intermittent variable that might affect the bug's occurrence.

These variables could be related to hardware, software versions, network connectivity, the number of servers, the volume of traffic, and other specific settings.

If we still can't understand the intermittent variable, then just jump into the next step, which is finding the root cause and going back to it when we have another clue. But remember, skipping to find the intermittent variable will make finding the root cause harder.

Find the Root Cause

Note: If the bugs are super urgent, the first aid is to restart the service (or the part of the software) that is related to the bugs. We can skip finding the cause for later.

To find out the cause of the bug, what we need to do is isolate the problem, which means we need to narrow down which part of the software or even which line of code is causing the bug.

There are 2 starting points to find the root cause:

1. Read the Error Message

   A good error message usually provides a clear explanation of why something is working unexpectedly. It also offers information about the specific part of the software that caused the bug. We can begin to find the root cause using this information or even try to fix the bug by searching online.

2. Start from the Trigger Point

   In the first step, which is reproducing the bugs, one of the outcomes is that we know what triggers the bug to occur. For example, if the bug is triggered when a button is clicked, we can start by examining the function behind the button click.

The next step is to trace back and pinpoint the bug. I often use 3 approaches to isolate and find the specific part of the software that is causing the bugs:

1. Deduce from code

   To start, we can thoroughly read the code and make educated guesses about which part of the code might be causing the issue. Utilize this approach when we have a strong understanding of the product and the technical aspects of the software.

2. Breakpoint

   If deducing from the code not worked, we can use breakpoints to trace what is causing the error. The breakpoint feature allows developers to pause the execution of a program at a specific point in the code. When a breakpoint is set, the program will stop running when it reaches that line of code, allowing the developer to inspect the program's state, variable values, and the flow of execution at that particular moment. Some programming languages, especially the compiled type, usually provide the breakpoint feature.

3. Print statement in every line

   Sometimes we can't use breakpoints, and in that case, I often use this approach. We can simply add print statements in every line of code that might be the cause of the error. Here's an example:

   func f1() {
      print("f1 called")
      f2()
      print("f2 called")
      f3()
      print("f3 called")
      f4()
      print("f4 called")
   }

   If the bug happens in f3(), then the f3 called message will never be printed. So, we can isolate the problem and check the f3() function to identify the cause.

Fix & Test

If we receive a good error message, then google it. We can simply "Copy & Paste the error message to Google" and review the top 5 search results. In my experience, both StackOverflow and GitHub issues are very helpful in such cases. The bug you encountered might have occurred to other people and has already been resolved

However, if we are unable to solve it by Googling, it's okay as long as we have identified the part of the software that causes the bug (this is actually the most challenging part). Once we find it, we can make the necessary changes to fix the bug.

The most crucial part is testing the solution. During the reproduction phase, we understand both the actual behavior and the expected behavior. When we make changes to fix the bug (whether following information from Google or fixing it manually), we need to observe the changes in behavior and ensure it works as expected. It's important to be cautious because the changes we make might introduce new bugs. So, test it thoroughly and carefully.

TL;DR

Picture tells 1000 words:

That’s it for today, thank you for reading! If you find it valuable, don’t forget to:

Subscribe now

Share The Scalable

Leave a comment

Welcome to The Scalable, blog and newsletter to help you faster in becoming tech leader. Check our tech lead roadmaps.

Before we start, kindly to subscribe, follow me on Threads & Linkedin and share this content to your friends. Enjoy.

Quick Links:

• Intro

• Utilize One-on-One Meeting

• Be Proactive

• TL;DR

Intro

Last week, I wrote about one-on-one meetings for managers and tech leaders, focusing on how to effectively lead these meetings. You can check the link below to gain insights from tech leaders who have utilized this meeting format.

Today's discussion is a continuation of the previous topics, but this time, we will focus on the other party involved: the Software Engineer (or mentee). The topic for today is how to maximize the one-on-one meetings with your manager to ensure that you gain numerous benefits from them.

Let's get started!

Utilize One-on-One Meeting

One misconception about one-on-one meetings is that many people, especially junior or new software engineers, think of it as a place for the leaders to simply give directions (one-way communication).

However, it is more than that. There are many benefits for software engineers if they can utilize these meetings effectively. What are they?

Utilize It for Career Growth

Yes, one-on-one meetings are a great opportunity to define your career goals and foster career growth. If your manager or leaders have not brought up this topic, you should ask them to discuss it. To utilize it, you need to ensure at least these three things below:

1. You have to talk about the clear requirements for you to reach the next career level.

2. Ensure that the list is measurable.

3. Review the progress toward these goals during each one-on-one meeting.

By following these three steps, you can proactively track your performance and development. Additionally, this approach enables your leaders to make objective judgments when considering your eligibility for promotion.

Utilize it for Solving Problems

Common problems that often happen in the workplace are misalignment, misexpectation and miscommunication. In short it is a gap.

With one-on-one meetings, you can solve these problems by:

1. Setting clear expectations.

2. Engaging in open communication to address the issues.

3. Creating an action plan to resolve the problems.

Remember that you are allowed to have expectations from your leaders, and it is crucial to communicate them. Your leader, at least your direct reportee, should be aware of your expectations. This approach can help bridge gaps and solve many issues.

Utilize it to Build Trust

A one-on-one meeting is a valuable opportunity to get to know each other better and build trust. It provides a platform for analyzing the behavior of your leaders, understanding their preferences, and identifying what they consider important.

As your leader is the decision maker, knowing and being able to influence them can significantly improve your work life, making it much easier to navigate.

You Need to Become Proactive

I often encounter average software engineers who grumble a lot about things they don't like, such as decisions, culture, or even their teammates. However, it's essential to understand that your career and happiness in the company are your responsibility, not your leader's alone. Therefore, taking ownership of the one-on-one meeting is also your responsibility.

If you have a good leader who genuinely cares about their subordinates and conducts effective one-on-one meetings, consider yourself lucky. However, in reality, you may encounter leaders with different approaches to connecting with their co-workers.

This validates the need for you to become proactive. Don't wait for your leader to spoon-feed you. In the context of one-on-one meetings, it means:

• It's okay for you to initiate the one-on-one meeting.

• You should proactively bring up relevant topics in the meeting.

• You should be the one who writes up and cares about the results of the meeting, including the action plan.

TL;DR

In summary, a one-on-one meeting is not just for your leader; you can also derive many benefits from it if you utilize it effectively. You can contribute to your career growth, solve problems, and build trust between co-workers through these meetings. Additionally, you need to be proactive instead of waiting for your leader to spoon-feed you. It means you should feel comfortable initiating the meeting, expressing your expectations to your leader, directing the topics of discussion, and more. Take charge of these meetings to make the most of them for your personal and professional development.

That’s it for today, thank you for reading! If you find it valuable, don’t forget to:

Subscribe now

Share

Leave a comment

Welcome to The Scalable, blog and newsletter to help you faster in becoming tech leader. Check our tech lead roadmaps.

Before we start, kindly to subscribe, follow me on Threads & Linkedin and share this content to your friends. Enjoy.

Quick Links:

• Intro

• Why Important?

• One-on-One Questions and To Do

• How Does Good 1:1 Look Like?

• TL;DR

Intro

I am often asked by many tech leaders about their routine in their company, and all of them always mention doing one-on-one meetings.

Currently, conducting one-on-one meetings is a proven practice that is a must for tech leaders. However, I have also heard that many people, especially new managers or leaders, find it hard to engage in one-on-one meetings. Most of them don't know what to do during these meetings.

Therefore, in today's discussion, we will delve into the topic of one-on-one meetings from the perspective of a manager or mentor. We will talk about the importance of conducting one-on-one meetings, what to ask, and what a good one-on-one meeting should look like.

Before we explore what to do in a one-on-one meeting, it is essential to understand what a one-on-one meeting is and why it's important.

Why are One-on-One Important for Managers & Tech Leaders?

For those of you who have never heard of a one-on-one meeting, basically it is a routine where a manager/leader/mentor meets with an employee to discuss various work-related matters. Typically, these discussions revolve around topics such as career development, goals, projects, and issues.

One-on-one meetings have been proven to have positive impacts, such as improving employee engagement. Employee engagement is closely linked to employee performance.

Basically, I have categorized the purposes (for managers/leaders) of conducting one-on-one meetings into two:

1. Solving problems
   Have you ever heard the phrase, "Most of your problems can be solved by talking"? Incorporating one-on-one meetings as a regular practice definitely helps reduce misunderstandings and assumptions that often lead to employee-company problems

2. Decision-making
   By regularly having these meetings, mutual understanding can be fostered, which ultimately proves useful in making decisions.
   For example, I have a friend who is a tech leader and didn't face difficulties when deciding back to WFO because he knew who supported and opposed the idea. He also have a strategy how to handle the opposing viewpoints

Engaging in one-on-one meetings offers numerous advantages compared to disadvantages. So, why not give it a try?

What Should be Discussed during a One-on-One Meeting as Manager / Tech Leader?

Now that we understand the importance of conducting one-on-one meetings, it's important to address the issue that many people, especially new managers/leaders, don't know what to do during these meetings. This can result in unproductive meetings with no clear purpose.

In this section, we will delve into what should be discussed during a one-on-one meeting.

Organization & Company Awareness

Organization here can refer to a team, division, or even a company. Organization awareness is crucial as it pertains to an individual's understanding and knowledge of an organization's purpose, goals, values, structure, culture, and operations.

Often, when decisions are made within an organization, there is a risk of being misunderstood by its members. By initiating discussions about organization and company awareness, it helps enhance the employee's sense of belonging.

Here are some actions and questions you can use during a one-on-one meeting:

• Company & Team Updates:

  • "I would like to provide you with an update on the company."

  • "Recently, our company made a decision to transition back to working from the office (WFO). You may have opposing views, but let me explain the thought process behind this decision."

• Management, Team, and Company Culture:

  • "On a scale of 1 to 10, what is your approval rating for our management and CEO?"

  • "Is there anyone in the team you would like to express gratitude to?"

  • "How would you describe your relationships with your co-workers? Are there any issues or areas for improvement?"

  • "How do you feel about our company culture?"

  • "What aspects of our team culture did you like the most and the least?"

• Organization Purpose, Direction, and Future Projects:

  • "Do you have a clear understanding of our company's purpose?"

  • "Do you have any ideas regarding features, products, or projects that we should prioritize?"

  • "What opportunities do you think we might have missed?"

  • "This semester, our focus will be on achieving specific Key Performance Indicators (KPIs). Here's the big picture behind why we are pursuing these objectives and why they are important."

  • "What do you like about our products?"

Goals & Expectation

Another important topic to discuss is goals and expectations.

Not always, but most employees might want to talk about their careers and how they can achieve their career goals. Therefore, career goals are also part of this kind of discussion.

Here are some actions and questions you can use:

• Goal Setting:

  • "Where do you see yourself in the company in the next 5 years?"

  • "What are your plans for next week?"

  • "Do you have any career goals? How long do you intend to achieve them?"

  • "Does working in this company help you achieve your goals?"

  • “What skills you want to improve?”

• Aligning Expectations and Requesting Feedback:

  • "How clear do you feel about what is expected of you?"

  • "Let's establish a mutual agreement on what we should and shouldn't do."

  • "What are your red flags? For me, a red flag is failing to communicate effectively. What about you?"

  • "Let's discuss how we can resolve conflicts. Do you prefer a direct or indirect approach?"

  • "What do you think I need to improve?"

  • "If you were in my position, what are 1-2 things you would change?"

• Career and Growth Plan:

  • "What can I do to help you grow?"

  • "In the last 3 months, I have seen improvement in your skills. Keep up the consistency."

  • "You were mentioned on Slack, but you haven't replied. This is unacceptable, how can we fix this?"

  • "If you want to get promoted in the next performance review, here are the things you need to demonstrate!"

  • "Who in the company would you be excited to learn more from?"

  • "What parts of the business would you like to be more involved in?"

• Milestone & Celebrate Success

  • "Congratulations! The last project you were involved in achieved the predicted KPIs."

  • "Thank you for delivering the project on time."

Setup Routine

What contributes to the success of employee goals is having a routine or system in place. It becomes easier when you have specific actions, such as "reviewing at least 10 pull requests per week" or "speaking up in meetings at least twice a week," and so on.

Here are some actions and questions you can use:

• Identifying Opportunities:

  • "Are there any recurring ad hoc tasks that we should address?"

  • "I noticed that the operations team frequently needs help finding bugs. Perhaps you can dedicate one hour in the morning to assist them."

  • "We agreed that misunderstandings of requirements have been causing delays. How about making it a routine to re-explain the requirements during brainstorming sessions?"

  • "Do you have any ideas on what problems can be solved by creating a routine or procedure?"

• Reviewing the Routine:

  • "Are we comfortable having this one-on-one meeting every week, or would you prefer it to be biweekly?"

  • "Do you feel that you attend too many meetings?"

Health Check

One-on-one meetings can be used to "health check" employee happiness and engagement, as happy employees tend to yield better results.

• Employee Happiness

  • "Are you generally happy working in this company?"

  • "Which part of your work is the most enjoyable?"

  • "What aspects of working here are not enjoyable for you?"

  • "What are the biggest time-wasters for you each week?"

  • "Which projects or tasks bring you happiness?"

• Personal

  • "How is life outside of work?"

  • "What did you do last weekend?"

  • "How are your family/children doing?"

  • "I noticed a decline in your performance recently. Is there any personal or family issue that may be affecting you?"

  • "What’s your hobby? do you play game?"

How Does a Good One-on-One Meeting Look Like?

There are several parameters that identify a good one-on-one meeting:

Clear agendas: Before the one-on-one meeting, both parties should understand the topics to be discussed and come prepared. In the previous section, we discussed what to do in a one-on-one meeting, and you can use one or some of those topics as the agenda.

Two-way discussion: A good one-on-one meeting should facilitate a two-way discussion where both parties get to know each other better and work together to solve problems, rather than it being a one-sided lecture.

Action plan: The best outcome of a one-on-one meeting is the establishment of an agreed-upon action plan. This plan can involve both the manager/leader and the employee who participated in the one-on-one.

Positive results: A good one-on-one meeting often leads to a more motivated employee, clarifies any areas of uncertainty, and helps the employee improve in some way.

TL;DR

A one-on-one meeting is a crucial routine that should be held by managers and tech leaders. It serves as a means to solve problems, build relationships, and enhance employee engagement. If you are unsure about what to do in a one-on-one meeting, focus on the following topics: organization and company awareness, goals and expectations, setting up routines, and employee happiness.

A good one-on-one meeting typically involves clear agendas, facilitating a two-way discussion between both parties, and yielding positive outcomes such as increased employee motivation and the establishment of clear action plans.

That’s it for today, thank you for reading! If you find it valuable, don’t forget to:

Subscribe now

Share

Leave a comment

Welcome to The Scalable, blog and newsletter to help you faster in becoming tech leader. Check our tech lead roadmaps.

Before we start, kindly to subscribe, follow me on Thread & Linkedin and share this content to your friends. Enjoy.

Quick Links:

• Intro

• Fake Smart Workers

• Misconception of Work Hard vs Work Smart

  • Becoming a Smart Worker is not Easy

  • Hard Work First before Work Smart

• Answering “Are You Work Hard or Work Smart?”

• TL;DR

Intro

Work Hard and Work Smart are two phrases often used in the context of productivity and success.

Work hard emphasizes the importance of putting in effort, dedicating time, and having a strong work ethic to achieve goals.

Work smart emphasizes the efficiency of your effort to maximize the result.

Over 80% of the software engineers I've met claim to be a smart worker rather than hard worker, but most of them are just average software engineers. On the other hand, those who call themselves hard worker are mostly great engineers.

How can this happen?

In today's discussion, we will be talking about work hard, work smart, and the misconceptions about them. Initially, I am not a fan of working smart. Why? Let's find out.

Fake Smart Workers

Every time I conduct an interview with a software engineer, one question that I often ask is:

Do you work hard or work smart?

My intention in asking this question is to understand their work behavior, especially to determine if they are lazy (continuous learner) or not.

I don't directly ask, "Are you a hard worker?" because the answer is easy to fabricate.

On the other hand, adding work smart as a comparison makes the results more interesting. If the engineer answers with "I am a hard worker," then they are likely telling the truth. Because if they are not, answering with "work smart" is more appealing and cool.

More than 80% of them answer with "work smart," and most of them (not all) are fake.

How can I know?

When I add a follow-up question, "What's the proof?" they cannot answer it.

Note: Now I need to remove this question 😂

Work Hard vs Work Smart (Misconception)

Are there any people who claim to be smart workers without faking it?

The answer is yes, but not many. However, that's not the real problem. The real problem lies in why we need to choose between those two.

I would say that this misconception arises in society because many people, including coaches, influencers, and motivators, glorify working smart over working hard.

I believe that working smart can be achieved after working hard enough.

Becoming a smart worker isn’t easy

Let's discuss this with an example (which actually happened in real life).

Imagine you are working in a company that uses Kubernetes as its infrastructure. You are managing hundreds of microservices, and there's a problem with the deployment process. It becomes a hurdle when you have to write the YAML files one by one.

One of the smart moves is to "create a tech tool" to automate the deployment. However, to achieve that, you need:

• Understanding of how Kubernetes works

• Strong technical proficiency to develop the tool

• Designing a suitable tool

• Dedicated time to develop it

• And more

If you look at the list above, it becomes clear that you need to work hard to learn and gain experience in many areas. If you haven't worked hard enough, you may not even be aware that you can create a tool to solve the problem.

Hard Work first then learn to work smartly

Working smart has prerequisites, unlike working hard, which everyone is capable of doing. Therefore, in order to work smartly, you need to acquire a lot of knowledge and experience. All of this can be achieved by investing a significant amount of time.

Once you have gained a substantial amount of knowledge and experience, it's time for you to learn how to work smart. This is crucial because there are many people who stop at working hard. After acquiring a vast amount of knowledge, they fail to learn how to work smartly, leading to burnout.

Herry, Are you Work Hard or Work Smart?

I will answer it by saying both. It depends on the situation, but essentially, I am a hard worker.

Here are some actions where I adopt a work hard approach:

1. When learning and keeping up with new technology.

2. Spending time writing thescalable every day.

Here are some actions where I adopt a work smart approach:

1. Solving recurring problems by building tech tools.

2. When it comes to prioritization and planning, I tend to find ways to limit the scope while still achieving the goals.

TL;DR

You can't work smart if you haven't worked hard enough, especially in the field of software engineering. You need to invest effort in learning, gaining fundamentals, and more before you can utilize them to become work smart.

It's not about choosing between working hard or working smart. They can even be used together. There are instances where you work smart on one task and work hard on another.

That’s it for today, thank you for reading! If you find it valuable, don’t forget to:

Subscribe now

Share

Leave a comment

Welcome to The Scalable, blog and newsletter to help you faster in becoming tech leader. Check our tech lead roadmaps.

Before we start, kindly to subscribe, follow me on Twitter & Linkedin and share this content to your friends. Enjoy.

Quick Links:

• Intro

• Technical Skill

• Soft Skill & Mindset

  • Think Structurally

  • Focus on Solve Problem

  • Growth Mindset

  • Positive Mindset

• Behavior

  • Eager to Learn

  • Proactive & Self Motivated

  • Good Ethics & Integrity

• TL;DR

Intro

A great junior software engineer is a software engineer who demonstrates qualities and potential for growth. This type of engineer simply needs a bit of direction, and they will quickly excel in terms of skills and career progression.

Whether as a co-worker or a leader, working with this type of engineer is pleasant for me. I don't need to put in much effort to make them functionally capable, and witnessing their growth is truly enjoyable.

I have interviewed 1k++ software engineers, and after conducting numerous interviews, I have noticed a pattern that distinguishes an average engineer from a potential software engineer.

In today's discussion, we are going to break down the characteristics and qualities of good junior software engineer looks like. We will explore the technical skills, soft skills, and behaviors needed for a software engineer with great potential.

Technical Skill

Having strong technical skills in the early stages of a software engineering career indeed helps, but it does not guarantee success. I have observed many individuals who excelled in university or were capable of writing good code, but when they entered the industry, they failed to make an impact on the company, and their skills and careers stagnated.

If you don't have strong technical skills, don't worry. At this stage, you are allowed to "Follow the rule first (framework or standard), then follow your heart." However, it's important to note that you still need a decent technical skill. At the very least, you should:

1. Understand the fundamentals of algorithms and data structures. It's okay if you only know how to use them. Having a deeper understanding of how they work is even better.

2. Be proficient in at least one programming language and its associated frameworks.
   Suggestion: focus on mastering one language first. When you already have a grasp you could learn more with the focus understanding end-to-end from frontend until your product deployed and can be accessed.

3. Be able to read logs, perform testing, debugging, and Googling (and Chat GPT-ing) to learn from problems.

4. Be able to work with MySQL or PostgreSQL, familiarizing yourself with database management and interacting with databases.

Soft Skill & Mindset

Think Structurally

Software engineering things revolve around thinking structurally. Algorithms involve step-by-step to solve a problem, which inherently follows a structure. Similarly, data structures, as the name suggests, are all about organizing and structuring data.

I have observed that software engineers with great potential always think structurally. It is easy to identify this quality by simply examining how they explain things and approach their work on projects.

When explaining things, they tend to provide explanations in a step-by-step manner, rather than jumping in and out of concepts. They organize their tasks structurally, for example developing "Create API" before the "Getter API" is important for them, because it helps them become more efficient in testing features and ensures a systematic progression in their work.

Problem Solver

An average software engineer: focus on completing tasks

A great junior software engineer: focus on solving the problems.

To illustrate this contrast, let's consider the scenario where an engineer is asked to build an API to display a transaction history.

The software engineer that has a great potential will find out what is the real problem and how to solve it. In this scenario, writing code is not a problem, querying is not a problem, how to display the transaction is the problem.

Growth Mindset

A growth mindset is a belief system or mindset in which individuals believe that their abilities, intelligence, and talents can be developed and improved through effort, learning, and persistence.

Software engineers with great potential possess a growth mindset. They embrace challenges and constantly seek opportunities to review their mistakes and improve in the future. They are not afraid of feedback and actively seek ways to grow and develop their skills.

Positive

It's always easy to find faults in others or even within your own company. The larger the company, the higher the chance of encountering a "toxic group" of people who engage in negative conversations, leading to a detrimental atmosphere. Unfortunately, I have witnessed many potential software engineers who ended up joining such groups, resulting in a decline in their performance.

On the other hand, true software engineers with great potential, when they encounter something they dislike, choose to communicate with their superiors to clarify assumptions and find solutions. They approach these situations in a proactive and constructive manner.

Behavior

Eager to Learn (20-80 Pareto Principle)

I have observed that great junior software engineers share a common trait: they invest their time in developing their skills outside of working hours. This aligns with the Pareto principle, which suggests that 20% of the time spent outside of work can have an impact on 80% of their career development.

They often engage in personal projects, pursue learning courses, or go the extra mile for their company. This is what we refer to as being "eager to learn." However, the term can sometimes be vague. Many software engineers self-proclaim that they are eager to learn, but to clarify this, a simple question can be asked: "Could you explain what you have learned in the past 3 months?" This helps gauge their actual commitment to continuous learning and skill development.

Proactive & Self-Motivated

Great junior software engineers possess a deep understanding that their success in their career is primarily dependent on their own efforts, rather than relying solely on others. As a result, they exhibit a proactive approach to acquiring knowledge and skills. They recognize the value of mentors, senior colleagues, and managers as valuable resources for growth and learning.

During one-on-one meetings, for instance, they take an active role in seeking feedback, guidance, and direction to enhance their impact within the team and the company. They actively participate in discussions, ask relevant questions, and demonstrate a genuine eagerness to improve.

Moreover, they exhibit a strong initiative in problem-solving. They don't wait for instructions or assignments; instead, they proactively identify and address challenges and seek solutions. These junior engineers willingly take on larger responsibilities when the opportunity arises, showing their readiness to contribute beyond their designated tasks.

Good Ethics

Many people possess various characteristics, but without good ethics, trust can be compromised, leading to a decline in professional relationships. Ultimately, trust is the most crucial aspect of one's career. When trust is established, it opens doors to opportunities, even if you may not be the most intelligent or skilled individual in the room.

TL;DR

So, being a great junior software engineer is not solely about technical proficiency. While they should possess a decent technical foundation, their soft skills and mindset play a significant role. These include structural thinking, a growth mindset, and a focus on problem-solving. Additionally, their behavior is instrumental in their growth, such as investing time to learn outside of working hours and being proactive.

Furthermore, they exhibit integrity and demonstrate positive ethics within the company. This involves acting in an ethical and principled manner, fostering trust and maintaining strong professional relationships. These qualities contribute to their overall success and growth as junior software engineers.

That’s it for today, thank you for reading! If you find it valuable, don’t forget to:

Subscribe now

Share

Leave a comment

Welcome to The Scalable, blog and newsletter to help you faster in becoming tech leader. Check our tech lead roadmaps.

Before we start, kindly to subscribe, follow me on Twitter & Linkedin and share this content to your friends. Enjoy.

Quick Links:

• Intro

• User Followers System & Database Design (One-Way)

• Two-Way Friend System

  • Using is_approve Column

  • Add rule UserID1 < UserID2

  • Double Row

• Conclusion

Intro

One important component of a social media feature is the friend system. Having a friend feature in your product fosters social interactions and enhances user experiences, which can lead to better engagement.

I categorize the friend system into two types:

1. User Followers (one-way): This is a Twitter-like friend system.

2. Two-Way Friend: This is a Facebook and LinkedIn-like friend system.

There are several components in friend systems, including:

• Adding friends

• Approving or rejecting requests (depending on the use case)

• Friend List

• Friends of friends

In today's article, we will discuss the system and database design of both types, and we will use MySQL or Postgres as the database. We will provide an overview of the user follower system and focus more on the two-way friend system. Additionally, we will specifically address the use case of adding friends and displaying the friend list.

User Followers Database & System Design

In a user followers system, users can establish a one-way relationship where one user can follow another user without requiring mutual consent.

Twitter User Followers System

On Twitter, you can follow other users without their consent. The database design for this feature is relatively straightforward.

Both option 1 and option 2 are relatively the same; it's just a matter of perspective. Personally, I prefer the first option because it's more intuitive for me.

Instagram User Followers System

On Instagram's following system, it's a bit different because you have the option to enable approvals. However, it is still considered a one-way relationship.

To solve this, we just need to add a new column: is_approve column.

Two-Way Friend System

In the two-way friend system, mutual consent is required to establish a friendship between two users. This is similar to the friend systems found in Facebook and LinkedIn.

Here is the general system design:

Option #1: Using is_approve Column

Let's start with the first solution, where we use the same database design as Instagram's approval-based one-way user followers system. The difference lies in how we query the data.

Here are some notes you need to know to understand this schema:

• uid1 refers to the user who initiates a friend request

• is_approve == false, means the request is still pending

• is_approve == true, means both users have become friends.

Add Friend Request

// `id 10` add request to `id 15`
SELECT count(*) FROM user_friend 
WHERE (uid1 = 10 AND uid2 = 15) 
OR (uid1 = 15 AND uid2 = 10)

// If the result is 1, then the request has been made
// If the result is 0, then we could insert the request to the table
INSERT INTO user_friend (uid1, uid2, is_approve) 
VALUES (10, 15, false) 

Retrieve Pending Friend Request

SELECT * FROM user_friend 
WHERE uid2 = 10 
AND is_approve is false

Retrieve Friend List

// use OR statement
SELECT * FROM user_friend 
WHERE (uid1 = 10 OR uid2 = 10) AND is_approve is true

// use UNION statement
SELECT * FROM user_friend WHERE uid1 = 10 AND is_approve is true
UNION ALL
SELECT * FROM user_friend WHERE uid2 = 10 AND is_approve is true

Approve / Reject

// Approve
UPDATE user_friend SET is_approve is true 
WHERE (uid1 = 10 AND uid2 = 15) 
OR (uid1 = 15 AND uid2 = 10)

// Reject
DELETE FROM user_friend 
WHERE (uid1 = 10 AND uid2 = 15) 
OR (uid1 = 15 AND uid2 = 10)

Advantage:

• Easy to implement

• Uses only 1 table

Disadvantage:

• The retrieval query is not satisfactory.

  • If using an OR query, it cannot be indexed.

  • If using UNION, sorting can be tricky.

• There is no guarantee that the data will not be duplicated (e.g., 10, 15 and 15, 10 are both possible)

Option #2: Improved version, adding rule UserID1 < UserID2

This is an improved version of the first option. It is similar but with an adjustment:

• Adding the rule uid1 < uid2

• Changing the status to an enum

  • REQ_UID1: uid1 makes a friend request to uid2

  • REQ_UID2: uid2 makes a friend request to uid1

  • FRIEND means both users are friends

Add Friend Request

// `id 10` add request to `id 15`
INSERT INTO user_friend (uid1, uid2, status)
VALUES (10, 15, 'REQ_UID1');

// `id 10` add request to `id 4`
INSERT INTO user_friend (uid1, uid2, status)
VALUES (4, 10, 'REQ_UID2');

Retrieve Pending Friend Request

SELECT * FROM user_friend 
WHERE (uid1 = 10 AND status = 'REQ_UID2')
OR (uid2 = 10 AND status = 'REQ_UID1')

// OR using UNION

SELECT * FROM user_friend WHERE uid1 = 10 AND status = 'REQ_UID2'
UNION ALL
SELECT * FROM user_friend WHERE uid2 = 10 AND status = 'REQ_UID1'

Retrieve Friend List

SELECT * FROM user_friend 
WHERE (uid1 = 10 AND status = 'FRIEND')
OR (uid2 = 10 AND status = 'FRIEND')

// OR using UNION

SELECT * FROM user_friend WHERE uid1 = 10 AND status = 'FRIEND'
UNION ALL
SELECT * FROM user_friend WHERE uid2 = 10 AND status = 'FRIEND'

Approve / Reject

// Approve
UPDATE user_friend 
SET status = 'FRIEND' 
WHERE uid1 = 10 AND uid2 = 15

// Reject
DELETE FROM user_friend WHERE uid1 = 10 AND uid2 = 15

Advantages:

• Easy to implement.

• Intuitive, the data looks tidy.

• Uses only 1 table.

• Data is guaranteed not to duplicate.

Disadvantages:

• The retrieval query still requires an OR or UNION statement

Option #3: Double Row

This solution is implemented by creating duplicate rows, such as AB and BA. Users who have become friends will have two rows in the database.

To make this approach possible, we need to add a new table called friend_request. Let's check the design:

Notes:

• I suggest we use the rule of uid1 < uid2 for the friend_request table.

• In the requestor column

  • UID1: if uid1 is the one who initiate the friend request.

  • UID2: if uid2 is the one who initiate the friend request.

Add Friend Request

// `id 10` add request to `id 15`
INSERT INTO friend_request (uid1, uid2, requestor) 
VALUES (10, 15, 'UID1')

// `id 10` add request to `id 4`
INSERT INTO friend_request (uid1, uid2, requestor) 
VALUES (4, 10, 'UID2')

Retrieve Pending Friend Request

SELECT * FROM friend_request 
WHERE (uid1 = 10 AND requestor = 'UID2') 
OR (uid2 = 10 AND requestor = 'UID1')

Retrieve Friend List

SELECT * FROM user_friend WHERE user_id = 10

Approve / Reject

// Approve
INSERT INTO user_friend (user_id, friend_id) VALUES (10, 15)
INSERT INTO user_friend (user_id, friend_id) VALUES (15, 10)
DELETE FROM friend_request 
  WHERE (uid1 = 10 AND uid2 = 15) 
  OR (uid1 = 15 AND uid2 = 10) 

// Reject
DELETE FROM friend_request 
  WHERE (uid1 = 10 AND uid2 = 15) 
  OR (uid1 = 15 AND uid2 = 10) 

Advantages:

• The data is tidy and intuitive.

• Indexing can work effectively.

Disadvantages:

• Data stored becomes duplicated.

• The friend_request table acts as temporary data but is required to implement this design.

Conclusion

There are many creative ways to solve the friend system. In the user follower friend system, such as a Twitter-like friend system, it is more straightforward, as we can simply match the user_id and friend_id.

In the two-way friend system, like the friend systems found in Facebook and LinkedIn, there are more options to choose from depending on your use case. Personally, I would suggest considering the 2nd option or the 3rd option.

Thank you for reading today's newsletter! If you find it valuable, don’t forget to:

Subscribe now

Share

Leave a comment

Welcome to The Scalable, blog and newsletter to help you faster in getting promoted into tech lead position. We are release new content 1-2x a week.

Before we start, kindly to subscribe, follow me on Twitter & Linkedin and share this content to your friends. Enjoy.

Subscribe now

Quick Links:

• Intro

• First Month: Adaptation

  • Do One-on-One

  • Gain Domain Knowledge

  • Listen and Observe

  • Build Relation

• Month 2-3: Getting Involved & Make Impression

  • Proving Expectation

  • Address Improvement

  • Take More Responsibility

• TL;DR

Intro

People achieve great careers (and getting promotions) not only because of their skillfulness but also because they gain trust.

This explains why sometimes crucial positions in a company are filled by individuals who may lack of skills.

When you join a new company, the first 90 days (3-month probationary period) are crucial for building a positive impression. Creating a good impression leads to trust. When people trust you, it enables effective collaboration, reliability, and accountability, resulting in successful project outcomes and professional growth. Consequently, this positively impacts your career.

Conversely, if you fail during your first 90 days, it's likely that you leave a negative impression. Reversing a bad impression becomes much more challenging once it has been formed. It may create skepticism even when you perform well, which can hinder your career progression.

In today's article, I will discuss how to have a strong first 90 days, allowing you to make a positive impression and propel your career to new heights.

First Month (Max 1.5 months): Adapt

In Tuckman's stages of group development, when you have just joined a new company, you are in the state of forming. Forming is the process of establishing the structure of the team. During this stage, members may feel uncertain and tend to avoid conflicts in order to be accepted into the group.

In this state, your focus is to learn and adapt to the environment. You need to be proactive and not expect others to adapt to you. Instead, adapt to others.

Here are some actions that you can follow to help you adapt well:

Do one-on-one alignment

It is important to align expectations because it often happens that you fail during your first 90-day probationary period due to having different expectations with your direct report, subordinates, and other co-workers.

Schedule one-on-one meetings with your direct reports to align goals and targets that need to be achieved.

If you are joining as a leader, it is essential to have a conversation with your subordinates.

• Assess their current state (whether they are happy or not)

• Assess team dynamics

• Inquire about preferred communication style

• Inquire about bottlenecks

Gain Domain Knowledge

Your goal is to become functionally capable of performing your job. This means that by the end of the month, you should have a comprehensive understanding of your working domain, such as:

• Familiarizing with the codebase,

• Understand end-to-end technical and user flows,

• Identify the users of the product

• Gaining insights into how users interact with the product,

• And more.

Gaining your working domain knowledge is important because it will set the foundation for a strong performance in the second and third months.

Here are some tips:

• Follow the rules:

  People generally hate changes, especially when you are new to the team. In the current state, your focus should be on following the existing rules, frameworks, code standardization, and tools that have been established. If there is something you are not satisfied with, make a note of it, but avoid making changes at this point.

• Read documentation:

  If your company has comprehensive documentation, take the time to study it. Asked to the existing employee if necessary.

• Read the code:

  Sometimes, reading the code provides a deeper understanding of how the product or features function. Personally, I find this to be particularly useful during my first week at a new company. Understanding the code helps me grasp the how it works both in technical and business.

• Experience the product as a user:

  Gain a different perspective by approaching the product or feature from the standpoint of a user, rather than solely as a software engineer. Ultimately, the users are the ones who interact with your product, so it is important to understand how they use it.

Listen and Observe More

Adapting well to the company and team culture is another crucial aspect. It is best to listen and observe more than talking or giving suggestions. Through active listening and observation, you will gain insights into the company and team norms, what is considered acceptable or not, as well as their preferences and dislikes. This will contribute to building trust with your co-workers.

Build Relation

It is essential to establish friendly relationships with your co-workers. I highly recommend finding the influential individuals in your team, often referred to as the "group leaders"

This person is typically the leader or manager (not always). Engaging in conversations with them will help you understand the team dynamics, develop rapport, and identify key individuals who can offer guidance, support, and valuable insights for navigating the team and organization effectively.

Building trust with these influential individuals will also facilitate gaining trust from others in the team.

Month 2 - 3: Getting Involved & Make Impression

After the first month, you are expected to have adapted well to the new environment. This is typically demonstrated by receiving more important projects, receiving positive feedback, and gaining the attention and respect of others.

During the second and third months (90 days), it's a showtime. According to Tuckman's stages of group development, it's time to transition from the Forming stage to the Storming stage. However, it's important not to rush and approach it with a softer, more collaborative approach. During this period, the key is to be highly involved and engaged.

Here's what you can do during this period:

Proving Expectations

During the first month, you received expectations from your superiors and colleagues (through one-on-one). Now it's time to prove those expectations. Typically, expectations revolve around delivering work on time and with accuracy. Ensure that you meet deadlines and deliver high-quality results. If necessary, go the extra mile to surpass expectations. Be honest about your strengths and weaknesses, and focus on demonstrating tangible results.

If you fail to exceed expectations during this period, it is likely that you have not fully adapted to the company or that there is a skill gap that needs to be addressed.

Address Improvement

You may want to make a list of areas that need improvement, whether they are:

• Technical (such as: tech stack),

• Procedural (such as: efficient code review),

• or even Related to team culture (such as: how to communicate in slack)

It is now your opportunity to address these issues, discuss their impact, and propose solutions.

Take More Responsibilities (Help Others)

If you have already proven yourself and met expectations, it's time to take on additional responsibilities. Discover a list of tasks that go beyond your main job but are essential for the team. For example:

• Assisting the operations support team

• Identifying and organizing bugs

• Establishing standards

• Updating documentation

• And more

Often, there are tasks that require extra hands and fall under the category of going the extra mile. Take the initiative to assume these responsibilities and contribute to the team's success.

Alternatively, if necessary, you can take over some of the tasks assigned to your direct reports. For instance, if your direct report is responsible for task breakdown, you can offer to take on that responsibility yourself.

TL;DR

In the first month (0-30 day), focus on adapting to your coworkers, teams, and company by aligning expectations and gathering knowledge.

In the 31-90 day period, prove yourself by meet (or even exceed) the expectations. Get involved, make a good impression by contributing to improvements, and take on more responsibilities.

By following these tips, you can leave a strong and lasting impression, which in turn builds trust. This will undoubtedly contribute to your career growth.

Thank you for reading today's newsletter! If you find it valuable, don’t forget to:

Subscribe now

Share

Leave a comment

Welcome to The Scalable, blog and newsletter to help you faster in getting promoted into tech lead position. We are release new content 1-2x a week.

Before we start, kindly to subscribe, follow me on Twitter & Linkedin and share this content to your friends. Enjoy.

Subscribe now

Quick Links:

• Intro

• Internal Factors

  • Dunning-Kruger

  • Not Making Impact

  • No One know your Achievements

• External Factors

  • No Open Position

  • It’s Hierarchy

  • Company Budget

• TL;DR

Intro

Why is Everyone Getting Promoted but Me? I have met many software engineers who ask this question. They feel that it is difficult to get a promotion in a Software Engineering career (especially below senior level). The career journey of these individuals typically unfolds as follows:

1. They join the company with high spirits and strive to become valuable assets.

2. 1-2 years pass, and they start feeling that they should be getting promoted, but they aren't. The reasons given by the company and their managers are unsatisfactory.

3. More year pass,

   1. Some of them leave the company and go back to square one.

   2. Others lose hope and accept their fate, becoming zombie engineers.

   3. Some choose to stay but become toxic to the company.

But, is it really difficult to get a promotion in a Software Engineering career? Or perhaps you just don't know how? I have also seen many people who easily get promotions, including those whom I mentored, helping them get promoted 4x in two years, from Mid Level to Staff level (equivalent to a tech lead and an entry-level engineering manager). Whats different?

In this article, we will discuss the fundamentals of why a software engineer gets promoted. I hope this will help you realize that growing your career requires a strategy. Essentially, I will break it down into two sections:

• Internal Factors. (Please focus on this section)

• External Factors.

Internal Factors

1. Dunning Kruger

The Dunning-Kruger effect is a psychological phenomenon that refers to the tendency of individuals with low ability and knowledge to overestimate their competence and believe they are more skilled and knowledgeable than they actually are.

Real example: Remember when the early version of Chat GPT was released? Many people suddenly labeled themselves as AI experts.

The Dunning-Kruger effect can create a gap where an engineer may feel they deserve a certain position while others, including their managers, may hold a different opinion.

Solution:

• Be honest to yourself

• Seek feedback

• Always improve yourself both hard skills and soft skills. As you acquire more skills and knowledge, the effects of the Dunning-Kruger phenomenon will gradually diminish

2. You are not making an Impact

You are not affected by the Dunning-Kruger effect and you are skilled in software engineering. Such as:

• You have completed numerous coding challenges,

• Obtained a master's degree in computer science,

• Your skills are respected by others.

However, you still have not been promoted while your friend has. How could this be?

To understand more, let’s consider this case study:

If you are a startup company focused on rapidly releasing new products to achieve Product-Market Fit (PMF), wouldn't it make more sense to promote SEB instead of SEA?

Solution:

• Expand your domain knowledge and understand the company's business, recognizing how your skills can make an impact.

• Be flexible and adaptable.

• Identify the requirements for the position you aspire to. If there is an engineering rubric or framework available, refer to it for guidance.

3. No One know your Achievements

Now that you have acquired sufficient skills and are making an impact in the company. What other reasons could be preventing your promotion? It's possible that your achievements are not being tracked, and you are unable to effectively communicate your accomplishments to others.

This type of situation often arises in larger companies where the decision-making process for promotions is more complex. .

• The manager may perceive the engineer as good but not quite good enough for a promotion.

• The engineer may believe they have met the requirements and performed well, yet they are not getting promoted.

• Both parties rely on assumptions. The engineer may only recall that they have done good work but forget the specific details.
  Consequently, the engineer struggles to effectively communicate and provide an explanation of their achievements.

There’s a gap here. But, is it you manager’s fault? It could be, but I believe that's a negative mindset. If you have a goal, it is also your responsibility to effectively communicate your accomplishments and the reasons why you deserve a promotion.

Solution:

• Document your achievements every time you complete projects or reach milestones. Don't wait for the performance review period.

• Mapped your achievements with the requirements needed for the next level

• Have dedicated sessions during 1:1 meetings to discuss your progress, seek feedback, and address any gaps more promptly.

External Factors

Assuming you have already addressed all the internal factors, I would say you have resolved 80% of the issues that may be hindering your promotion. However, there are still external factors that can prevent you from being promoted. In this case, I recommend you to focus on how to respond the situation.

1. No Open Position

This is a common situation that occurs in companies where you have to wait for your superior to resign in order to be promoted.

Let's get back to the fundamentals: "Why does a position exist?"

A position in a company is created when there is a job that needs to be done. From the company's perspective, if all positions are already filled, there is no need to add more people to the same position as it would result in having individuals who are not assigned any work or responsibilities.

That’s why company is more likely to seek an employee who fits the specific needs of role rather than hiring the best candidate in the industry.

How you should response:

• You can always create a new position if you can make the company realize that there is a job that needs to be done but has not been recognized yet. Focus on finding it

• Personal Story:

  • I worked at Tokopedia, the largest e-commerce marketplace in Indonesia, as part of the discovery tribes, with a focus on enhancing product discovery for users.
    During my time there, I developed a recommendation system, which was a novel concept at the time. This system had a significant impact on business metrics. As a result of this achievement, I was promoted to a team lead position and given the opportunity to recruit and build a team.

2. It’s Hierarchy

The typical career structure follows a hierarchy, where higher positions become increasingly scarce. It's natural that you are being compared to your peers in such a setting.

Both you and your superior are human, as are the other engineers. Subjectivity can arise when objectivity is no longer applicable, especially when there are two or more individuals vying for a promotion.

Here's how you should respond to this situation:

• Understand that your superior might have a difficult time making decisions.

• Avoid comparing yourself to others.

• Improve your relationships with other people, including your superiors. Be more open and actively build trust. This is an area that is often lacking among software engineers.

• If you feel that you are more deserving of a promotion, take a moment to reconsider. It might be attributed to your achievements being untracked or your inability to effectively explain your story.

3. Company Budget

I think this point is quite clear. The most challenging aspect is to have the company communicate these reasons to you.

If this situation arises, you have several ways to respond:

• If your company in hard situation:

  • Don't be egoistic; you need to consider your company's situation

  • You can request the company to promote you formally with a delayed salary increment until they have more profit or funds available.

  • Continue to make a positive impact to contribute to the success of your company.

• However, if the reasons for not getting promoted are unrelated to the company's financial situation, there may not be much you can do about it.

  • As a last resort, you may consider exploring opportunities with other companies. Don’t become toxic, maintain professionalism and explain your circumstances.

TL;DR

• Focus on internal factors first: improve your hard skills and soft skills, align them with your company goals, and effectively brand yourself by showcasing your achievements.

• Be aware that there are external factors to consider, such as the hierarchical structure, lack of open positions, and budget constraints within the company.

  • Be honest with yourself.

  • Understand the perspectives of the company, your superiors, and managers.

  • Avoid comparing yourself to others.

  • Communicate effectively with decision makers or superiors about the external factors. It may be possible to find solutions or alternatives.

Thank you for reading today's newsletter! If you find it valuable, don’t forget to:

Subscribe now

Share

Leave a comment

Welcome to The Scalable, blog and newsletter to help you faster in getting promoted to senior position. We are release new content 1-2x a week.

Before we start, kindly follow me on Twitter & Linkedin and share this content to your friends. Enjoy.

Quick Links:

• Providing Context

  • Provide background information

  • Talk in their languages

  • Use Analogy

  • Use Visual

  • Ask to re-explain

• Gathering Context

  • Active Listening & Observation

  • Breakdown the Discussion into Smaller Parts

  • First Principle Thinking

  • Summarize

• Grow Empathy

• Conclusion

Communication is an essential skill in software engineering. Efficient communication can result in better product quality and faster delivery. I have often observed that one distinct factor differentiating seniors from juniors is their communication skills. In my opinion, seniors tend to have good communication skills. One piece of evidence is that non-technical individuals often seek out seniors for assistance instead of directly approaching the engineer who developed the system. I have inquired about this and received responses such as, "I don't understand what the junior is saying, so it's better for me to ask the senior and wait for them to sync up with their mentee".

But what does good communication mean in terms of software engineering? It certainly does not involve sweet-talking or making empty promises about features. In simple terms, good communication means ensuring mutual understanding between parties. It means that "I understand what you mean" and "You understand what I mean."

From that definition, there are two components to having good communication:

• Being good at providing context.

• Being good at gathering context.

In one-way communication (sharing knowledge or ordered by superior) you might only need one component. However, in two-way communication (discussions), you definitely need both components.

In today's article, we will discuss various tips and techniques to help you excel at providing and gathering context, depending on the individuals you are communicating with. In software engineering, you typically interact with four types of people: peers, superiors, subordinates, and non-technical individuals.

Providing Context

In communication, providing context means offering relevant information and ensuring that it is understood by the recipients, conveying the intended message clearly. If you often hear phrases like "I don't understand what you mean", it may indicate that you have not effectively provided the necessary context for others to comprehend.

This skill is incredibly important because a failure to do so can lead to discussions filled with assumptions, resulting in increased time to address problems, making incorrect decisions and taking inappropriate actions, among other issues.

Here are some communication techniques to improve your proficiency in providing context.

Provide Background Information

Use this in situation: All situation (except you have already intensely communication with the person about the topics)

I often met an engineers that jump into a discussion without considering whether the other party is prepared for the discussion or not. Like this conversation:

Engineer 1 (E1): Hi, please revert back your formula just for my case. My feature got bugs because of it.

Engineer 2 (E2): Wait... What?

Compare it with:

E1: Hey, currently, one of your codes is impacting my feature, which is Feature A that has dependency to your endpoint X. It seems like you have implemented a new formula, but in my case, I still need the old formula. Can you implement a condition when my feature hits your endpoints?

Whether you are talking to fellow engineer or even non-tech person, it is important to provide the necessary background information. This includes explaining the situation, goals or problems, relevant information about the topic, and the rationale behind your decision.

By providing this context, you enable your audience to understand the current situation and make informed judgments.

Talk in their languages

Use this in situation: All situation

I have written a brief about this in the article, which you can check out here. In the article, I provide an example of how Tyrion Lannister from Game of Thrones is able to adapt and communicate effectively with different individuals.

Notes: Here, "languages" does not refer to English, French, or other spoken languages, but rather to the level or style of communication that can be understood by the other party.

A good communicator is able to adjust their language level, sometimes toning it down, changing their words, talking around the topic, or being straightforward, depending on the person they are speaking to.

Business Guy (B): Our user asked if we can do custom calculations for the tax.

Software Engineer (SE): I think it's difficult to implement that. All of our functions already rely on the current fixed calculations stored in our database.

Compared with:

B: Our user asked if we can do custom calculations for the tax.

SE: Didn't we agree in the past that custom calculations were not allowed due to government policy? Has there been any change? Have you researched this?

See the differences? If you are a fellow engineer, you might understand the first conversation. However, if you don't fully grasp the context and domain knowledge, the second conversation might be easier to understand

It may not be easy to communicate in a language that the other person understands, but you can follow these tips:

• Research and understand the audience: Consider the background, knowledge, and expertise of your audience. You may need to familiarize yourself with the domain knowledge that your audience understands, including the terms and phrases they are familiar with.

• Avoid technical jargon: Steer clear of jargon and technical terms, especially when communicating with non-technical stakeholders. Provide explanations when necessary. While using tech jargon looks cool, it often contributes to the perception of "bad communication" among engineers. Use technical jargon only if you are 100% sure that the other party already understands it (typically when communicating with peers).

• Experiment and adapt: It may not be easy to determine the appropriate level of communication that will be well-received by both parties. You can try using a specific language level and, if the other party doesn't understand, adjust your approach accordingly.

Use Analogy

Use this in situation: Mainly when converse with non-tech

You might encounter situations where it is challenging to find sentences that your audience can easily understand. In such cases, you can use analogies that are similar to the situation at hand to explain things, enabling the other party to grasp and visualize the concepts more easily.

Let's learn through an example:

Non-Tech Guy: Hey, tomorrow we are going to have a big event, and we expect the traffic to increase 5x. It should be easy to handle, right? Just make your server bigger.

Software Engineer: It's not that simple. Imagine you are running a restaurant with a capacity for only 20 people. Suddenly, you have 100 people waiting in line. It's not just a matter of expanding the physical space; you also need to hire more cooks, waiters, stock up on additional raw materials for food, maybe even pre-prepare some dishes so the chef can cook them upon order, and so on.

By using this analogy, it becomes much simpler for the non-tech person to understand the situation compared to explaining concepts such as horizontal scaling, caching, load balancers, and more.

This technique can still be used to communicate with fellow engineers, but you can utilize analogies related to technical concepts. Personally, I rarely use this technique with fellow engineers.

Use Visuals

Use this in situation: Explaining something hard to explain such as system design

Communication is not limited to verbal expression alone. Non-verbal communication, including the use of visuals, plays an important role. While visuals may not be suitable for every discussion, I highly recommend utilizing them when possible.

I usually employ this technique when communicating with my subordinates (mentees), especially when explaining system design. Utilizing charts or mind maps proves to be very helpful. I rarely discuss this with the managerial level and above, as we typically have a mutual understanding through verbal communication at a higher conceptual level.

Apart from that, when engaging in conversations with non-technical individuals, I frequently utilize this method in certain cases, such as providing infographics.

Ask for Re-explanation

Use this in situation: Converse with your mentee

Remember, the purpose of providing context is to ensure that your audience truly understands your message. However, there is often a bias where people think they understand, but in reality, they have misunderstood. To address this, you can ask them to re-explain the concept using their own words to ensure that both of you are on the same page.

"For clarity, can you please explain in your own words what I've just explained and let me know what actions you need to take?"

You can also summarize the conversation to double-check if both parties are aligned and have a shared understanding.

Gathering Context

Gathering context (in communication) is the process of actively seeking and acquiring relevant information in order to understand the intentions or messages of others. With good context-gathering skills, your communication becomes much more efficient because you can respond with relevant messages.

Let me provide you with a real-world example (which actually happened) of a situation where a software engineer was poor at gathering context.

Background Story:
- In the e-commerce industry, a product manager asks a junior software engineer to display transaction statuses on the website.
- In the database, there are already six transaction statuses: PENDING, VERIFYING, PROCESSING, DELIVERY, DONE, FAILED.

The conversation goes as follows:

Product Manager (PM): Hey JE, for our next project, we need to show transaction statuses in the user transaction history. Our users often inquire about the delivery status.

Junior Engineer (JE): So, I just need to display the 6 transaction statuses, right? Where exactly should I put them?

PM: Yes. You know, on the history page, below the total amount, there's a blank space. Just add a badge with the statuses inside it.

JE: Alright, I'll do it right away.

PM: How long will it take?

JE: Two days.

The product manager didn't create a requirement document because he believed it was just a matter of displaying the status, and other competitor companies have similar statuses implemented well. However, the result turned out to be far from what the product manager expected:

Of course, the product manager is not 100% right in this situation, but I want to focus on the software engineer instead of the product manager. Instances like this often occur where the engineer lacks domain knowledge and misunderstands, leading to a failure in grasping what the PM truly means and consequently working on incorrect requirements.

Note: The situation worsens when the engineer fails to gather any context and relies solely on assumptions.

So, here are some tips and techniques for gathering context to prevent occurrences like this.

Active Listening & Observation

Use this in situation: All situation

Engage in active listening by paying close attention to what others are saying (including small details). Focus on understanding their perspectives, concerns, and goals. Avoid interrupting and ask clarifying questions to ensure a thorough comprehension of the context being shared.

The purpose of active listening and observing your audience is to understand their main goal or point from the conversation. When you understand their goal or what they want, it becomes easier for you to respond effectively.

Breakdown the Discussion into Smaller Parts

Use this in situation: Have long & unstructured explanation

Often, when trying to gather context, you may receive long and unstructured explanations. In such situations, you need to intervene and structure the conversation. One suggestion is to break down the discussion into smaller parts. Here's an example:

S. Engineer (SE): Could you please explain the...

Product Manager (PM): So, the user flow starts with the user creating a loan request, and then the request will be curated by the superiors before...

SE: Sorry for interrupting, but let's focus on the first step, which is creating the loan request, before we proceed to the next discussion.

Breaking down the conversation into smaller parts allows for better focus when gathering context.

First Principle Thinking

Use this in situation: conversing with non-tech or geek engineers who use terms you don't understand and/or encounter ambiguity (something that makes you assuming things)

First principle thinking involves questioning every assumption you think you know about a given problem and creating new solutions from scratch. In first principle thinking, you question assumptions until they cannot be broken down any further.

In the example above, where the junior engineer built something that the PM didn't intend, there was ambiguity regarding the term "status". From the engineer's perspective, it referred to a status stored in the database, while in the PM's mind, it was about a status that the end user should understand. The problem arose because the engineer assumed the definition of "status" in technical terms.

In short, when you have any assumptions, clarify them right away. If there are terms you don't understand, ask until you gain a clear understanding.

Summarize & Explain the Result that Comes to Your Mind

Use this in situation: converse with non-tech individual and/or mentee

Similar to "asking for re-explanation" in providing context, summarizing and explaining the result helps ensure that your understanding aligns with the other party's.

"Hey, let me summarize today's discussion, and please correct me if I'm wrong..."

This approach serves as a double-check to prevent miscommunication and ensure that both parties are on the same page.

Share The Scalable

Grow Your Empathy

I have already provided you with some tips and techniques to improve your communication through providing and gathering context. However, there are many more techniques and tips beyond that. If you carefully examine them, you will there is a factor that serves as the foundation for the techniques I shared with you.

That factor is empathy.

Empathy is the ability to understand and share the feelings of others as if you were in their own shoes. All the techniques are related to the empathy, but it can be challenging to explain how to cultivate empathy. That's why I provided you with the techniques directly.

Let’s save about empathy in software engineering for another topics.

Conclusion

Effective communication is not a simple task. Throughout this article, I have provided you with tips and techniques to improve your communication skills. However, it is important to understand that communication is more than just exchanging information. Merely knowing about communication techniques does not automatically make you proficient in communication. It requires practice and consistent effort since communication skills are spontaneous and need daily practice. So, learn these skills, put them into practice, and you will undoubtedly become a better communicator.

Thank you for reading today's newsletter! If you find it valuable, don’t forget to:

Subscribe now

Share

Leave a comment

Welcome to The Scalable, blog and newsletter to help you faster in getting promoted to senior position. We are release new content 1-2x a week. Today we are going to discuss about the definition of Senior Engineer which very important before you make strategy.

Before we start, kindly follow me on Twitter & Linkedin and share this content to your friends. Enjoy.

Quick Links:

• What is Senior Software Engineer?

• What makes a Senior Software Engineer?

• Roles & Responsibility

The Scalable is a newsletter where we discuss how to advance to the Senior Level (including positions such as Senior Software Engineer, Tech Lead, and hands-on Engineering Manager). Many of you may aspire to reach the senior level in your careers. However, before you start planning or taking action, the first thing you need to do is define “what is Senior Software Engineers?”. It can vary because different companies have different standards. But, do you aim for the senior level solely for the title, or do you want to become a senior in both title and quality/capability?

When you obtaining the senior level but only the title, don’t assume that it’s without consequences. I've seen many people ruin their careers because their inflated titles do not match their capabilities. In the post-COVID era, where there have been significant tech layoffs, many senior and even management-level professionals are finding it difficult (at least in my country) to secure new jobs because they are overpaid and have inflated titles. There's a disconnect where employees feel like they're "ex-Unicorn A or ex-Unicorn B," but the new hiring company doesn't believe their capabilities will benefit the company.

In today's article, we will discuss my standards for defining what a Senior Software Engineer is, so you don't fall into the trap of title inflation.

So, What is Senior Software Engineer?

If someone asks me what a senior software engineer is, then my answer would be delivery and independence.

Delivery means that a senior software engineer consistently produces good results within a relatively short time frame. It's important to note that delivery is not just about writing code; it can encompass various aspects, for example:

• Asking the right questions to shape and refine scope and requirements, minimizing errors and unnecessary work.

• Choosing the appropriate technology to save time while achieving satisfactory results, especially from a business perspective.

• If you're a lead or manager with subordinates, your presence should enhance the development process, making it more efficient and effective.

• And more...

Independence (or autonomy) means understanding your role within the company and not relying on others to enable your performance. While having peers and superiors for discussion is valuable, you don't require constant micro-management. You do whatever it takes to ensure successful delivery. Although you may not make final decisions, you consistently provide options and influence the decision-making process.

What makes a Senior Software Engineer?

Now that we understand that being at the Senior Level is about delivery and independence, but it's still too broad to fully comprehend what truly makes someone a senior software engineer. To gain a deeper understanding, we need to break down the skills, knowledges and capabilities that support "delivery" and "independence" because I believe both of these qualities are a result of other skills, knowledges and capabilities.

Fundamental Skills

Undoubtedly, a solid foundation in software engineering is essential for every software engineer, especially at the senior level. This includes proficiency in programming languages, frameworks, code quality, databases, and more.

What sets senior-level engineers apart is their comprehensive understanding of the fundamentals for every technology and decision they make, as well as their ability to effectively implement them. For example, while a junior-level engineer may grasp the importance of indexing in a database, a senior-level engineer comprehends the intricacies of how indexing works, knows when it should and should not be implemented, and understands the potential side effects involved.

System Design

Senior software engineers possess the skills to design scalable, efficient, and maintainable software systems.

They understand different architectural patterns and can make informed decisions regarding the appropriate architecture for a given project.

They can analyze business requirements and translate them into technical solutions and system designs. They always consider the long-term relevance of the chosen design.

Balancing Design and Implementation Trade-Offs

Software engineering involves making trade-offs. While a good design often leads to a longer implementation time, a poor design may result in a quicker implementation. Senior-level engineers have the ability to assess options and understand the trade-offs when making decisions. They are pragmatic enough to consider both design and implementation trade-offs, sometimes sacrificing idealism for the sake of the company. If they are forced to make a poor design choice, they have strategies in place to improve it in the future.

Domain Knowledge

Senior-level engineers have a deep understanding of the domain specific to the industry or field in which they work. Combining technical proficiency with domain knowledge sets them apart from other software engineers. They no longer struggle with writing code but instead focus on aligning business and technical aspects.

If they are new to an industry, they are capable of independently acquiring the necessary knowledge specific to that domain. Consequently, they continuously expand their knowledge to effectively address the unique challenges and requirements of their industry.

Senior-level engineers often become the go-to person for domain-specific knowledge. For example, some of my friends who work at HR Tech companies even have a better understanding of their country's tax calculations than tax consultants

Communication

Senior software engineers collaborate with cross-functional teams, including product managers, designers, and quality assurance engineers. They possess excellent communication skills and can effectively convey technical concepts to both technical and non-technical stakeholders.

They can position themselves appropriately when communicating with non-technical person, technical leaders, or even mentees. They adjust their communication style to ensure the message is well received. They understand what to communicate and what questions to ask to unblocked the blockers and ensure successful delivery.

Project Management and Time Management:

Senior-level engineers excel in self-management, including time and task management. They can translate business requirements into technical requirements and break them down into smaller tasks. They accurately estimate timelines and prioritize tasks to prevent bottlenecks.

For roles such as tech lead and engineering manager, they can leverage their team members' skills to ensure projects run smoothly without bottlenecks. This is why having senior-level engineers on a team results in 1+1=5 not 1+1 = 2.

People Management:

In simple terms, at the senior level, you need to empower other team members, including mid-level and junior engineers. In most companies, there are typically two career paths for software engineers: the Individual Contributor Path (Pure Senior Software Engineer) and the Managerial Path, such as becoming a tech lead (a role that blends technical and managerial responsibilities) or an engineering manager (a purely managerial role).

The main difference lies in the fact that pure Senior Software Engineers may not require advanced people management skills. They primarily focus on being the go-to person to assist in the growth and improvement of other team members. They provide insights rather than direct answers, enabling others to develop. They may also delegate tasks to promote knowledge sharing and prevent siloed knowledge.

However, if you chooses to pursue the tech lead or managerial path, more advanced people management skills become essential. In these roles, being actively involved in people management is necessary, including conducting regular one-on-one meetings and creating growth plans for mid-level and junior engineers.

Contribution

Senior-level engineers always contribute in many ways, such as providing ideas for tech planning and project planning. They also contribute to code standardization, establishing standard procedures, and more. They go beyond simply writing code and actively contribute to making the work more efficient.

I have observed that some senior-level engineers are quite vocal and assertive, while others may be more reserved. However, regardless of their communication style, they consistently contribute in their own unique ways. Sometimes, even in meetings, they may voice out just one idea, but it proves to be on point. Whether one is outspoken or reserved, the measure of becoming a senior software engineer can be tracked by the level of contribution one makes.

Debugging Skills

Senior-level engineers always think ahead to prevent bugs by leveraging their technical proficiency and other knowledge. However, when a bug does occur, they are adept at identifying potential causes based on symptoms, debugging the issue, finding the root cause, and solving it with minimal information, often derived from logs. Their focus extends beyond solving the immediate bug; they also ensure that it does not recur in the future.

What are the Roles and Responsibilities of Senior Software Engineer

To answer the question of "what are the roles and responsibilities of a senior software engineer," it may vary across different companies. However, I can provide some common aspects that define the role of a senior software engineer:

One could say that a senior engineer is like a machine or driving force within the company. Therefore, it is likely that you will still need to be hands-on and actively involved in various tasks. Your main responsibility is to do whatever it takes, utilizing your skills and leveraging other team members, to deliver projects on time without constant supervision. As a senior software engineer, you should have a clear understanding of your role within the company.

Additionally, it is crucial to be an expert in at least one domain that is significant to the company. If you lack expertise in a specific domain, it is important to evaluate whether you are truly meeting the expectations of a senior-level role. To grasp the concept of domain expertise, consider the following example: In an e-commerce company, there are several domains that hold importance, such as search, product pages, transactions, ads and promotions, and more.

So, that's it for today. Defining a senior engineer is challenging, and every company has different standards. However, with the guidelines provided in this article, you can establish your own standard and avoid getting caught up in title inflation. If you are currently facing title inflation, this will help you identify areas that need improvement.

Thank you for reading today's newsletter! If you find it valuable, don’t forget to:

Subscribe now

Share

Leave a comment

Hello, I apologize for the delay in publishing. It was due to the extensive length of the content I wanted to write. Today, we will discuss the tools that have accelerated the growth of my career, technology that has greatly benefited me in my software engineering journey. It is Redis, we are going to learn redis real-world use cases including system design and pseudocode on how to implement it.

Follow me on Twitter & Linkedin

Quick Links:

• User Profile Cache (HTTP API Cache)

• Session Storage

• Log In Throttling

• Dynamic Hotel Pricing Update (Redis Distributed Lock)

• OTP (One Time Password) using Redis

• Waiting List in Help Desk System (Job Queue)

• Search History Feature

• Shopping Cart / Add to Cart

• Real Time Analytics using Redis

• Leaderboard Service

• Build Realtime Chat Using Redis (Direct Message & Group Chat)

• Realtime Notification

• Geolocation Distance (Find Driver Near Me & Employee Check In)

Subscribe now

If you asked about the tools I love the most, Redis is definitely one of them. Redis is a great tool for two reasons:

• Simplicity: Redis is simple to understand and use.

• Wide range of use cases: Redis can solve a lot of real-world use cases.

Take a look the infographic what redis capable of in solving real-world use cases.

Notes: use cases above just a few cases that often we met in real life, but of course there are more use cases that can be solved by redis

In almost every major tech industry, including e-commerce, ride-hailing, travel, and more, Redis can be utilized to solve various use cases. This truly showcases the power of Redis. Without further ado, let's go deeper into how Redis can be employed in real-world scenarios.

User Profile Cache (HTTP API Cache)

Redis Commands: GET, SET, EXPIRE

HTTP API cache refers to the caching of HTTP responses from an API (Application Programming Interface). It involves storing the response of an API request in a cache, which can be subsequently used to serve future requests without the need to re-fetch the data from the API server.

One of the common use cases for API caching is storing user profiles. In an authentication system, usually only the user ID or email (something unique) is stored in the authentication token. However, the frontend often requires the user's name and profile picture on every page. Retrieving the user profile repeatedly can become redundant, so api caching with Redis can greatly enhance scalability.

function GetUserProfile(user_id) {
    var cache_response = redis.Do(`GET user:{user_id}`)
    if(cache_response) {
        return json.Unmarshal(cache_response)
    }

    var response = getProfile(user_id)
    var marshalled_resp = json.Marshal(response)
    redis.Do(`SET user:{user_id} {marshalled_resp} EX 600`)
    return response
}

HTTP REST APIs typically return JSON responses. If we want to utilize Redis to cache the responses, we can store JSON string as the cached value. For subsequent requests, we can simply unmarshalled the string and return the cached JSON object.

Redis for Session Storage (Login & Logout)

Related Commands: GET, SET, EXPIRE, DEL

Session-based authentication is a widely used approach for user authentication in web applications. It involves generating a session token after login, which is then used to keep track of the authenticated user.

Similar to the issue with user profiles, the session token needs to be checked every time a user performs an action that requires authentication. Consequently, querying the database can easily become a bottleneck in high-traffic use cases. Therefore, using Redis for session storage is considered one of the best solutions.

function Login(email, password){
    var session_token = loginLogic()
    redis.Do(`SET user:session:{session_token} {email} EX 3600`)
    return session_token
}

function Logout(session_token){
    redis.Do(`DEL user:session:{session_token}`)
}

function VerifyToken(session_token) {
    var email = redis.Do(`GET user:session:{session_token}`)
    if(!email) {
        return null, errors(`token is expired or not exists`)
    }
    var user_detail = getUserDetail(email)
    return user_detail, null
}

Log In Throttling

Related Command: INCRBY, EXPIRE, TTL

Authentication has many interesting use cases, one of which is preventing users from hacking other users through brute force attacks. One of the easiest ways to achieve this is by implementing throttling. Throttling refers to the practice of intentionally limiting the rate or speed of a process or service. You might have seen messages such:

“There have been too many login failures. Try again in x seconds”

This is an implementation of throttling for login attempts to prevent brute force attacks. In a simple manner, throttling involves storing the number of login attempts made by a user. However, storing this data in databases like MySQL or PostgreSQL may seem overly engineering. Additionally, databases like MySQL and PostgreSQL do not have built-in time-based expiration, unlike Redis. Using Redis to implement throttling is a straightforward solution. Please refer to the system design below:

function Login(context, username, password){
    var guest_session = context.GuestSession
    var max_attempt = 5
    var current_attempt = redis.Do(`GET login_attempt:{guest_session}`)
    if(current_attempt >= max_attempt){
        var expire_lock = redis.Do(`TTL login_attempt:{guest_session}`)
        return null, errors(`There have been too many login failures. Try again in {expire_lock} seconds`)
    }

    var is_login_success, auth_token = login(username, password)
    if(!is_login_success) {
        redis.Do(`INCR login_attempt:{guest_session}`)
        redis.Do(`EXPIRE login_attempt:{guest_session} 300`)
        return null, errors("user not found / invalid password")	
    }
    redis.Do(`DEL login_attempt:{guest_session}`)
    return auth_token, null
} 

Dynamic Pricing in Hotel Industry (Redis Distributed Locking)

Related Command: GET, SET NX EX

When working with horizontal scaling or even microservices, it becomes necessary to implement distributed locking at the application level to address issues such as race conditions or thundering herd problems. Redis can be leveraged for distributed locking, offering several advantages including high scalability, fault tolerance, and strong consistency guarantees.

Consider a scenario where you are developing a hotel booking platform that fetches dynamic prices from a third-party API. In a situation where multiple users are requesting hotel information for the same date, you may want to avoid overwhelming the third-party API. Here, you can utilize Redis distributed locking to resolve this issue effectively.

function CheckHotelPrice(hotel_id, book_date) {
    var price_detail = null
    while(true) {
        price_detail = redis.Do(`GET hotel_price:{hotel_id}:{book_date}`)
        if(price_detail != null){
            break
        }
		
        var current_machine_name = os.GetHostname()
        var acquire_lock = redis.Do(`SET hotel_price:{hotel_id}:{book_date}:lock {current_machine_name} NX EX 5`)
        
        if(!acquire_lock){
            sleep(250) // waiting 250 ms
            continue
        }
		
        price_detail = getHotelPriceFromThirdParty(hotel_id, booking_at)
        redis.Do(`SET hotel_price:{hotel_id}:{book_date} {price_detail} EX 600`)
	break
    }

    return price_detail
}

OTP (One Time Password) using Redis

Related Command: SET NX EX, GET, DEL

"OTP" stands for "One-Time Password." It is a security measure used to authenticate users and verify their identity during online transactions or account logins. A one-time password is a unique and temporary code that is typically valid for a short period of time, usually for a single login session or transaction. Since Redis has time-based expiration using the EXPIRE command, it is well-suited for building an OTP (One-Time Password) system.

The OTP system consists of two functions:

• Generate OTP

• Verify OTP

Redis can be leveraged to build an OTP system. Below is pseudocode that demonstrates how Redis can be used to develop an OTP system:

function GenerateOTP(phone_number) {
    var otp_code = generate_otp_code(6)
    var is_success = redis.Do(`SET otp:{phone_number} otp_code NX EX 600`)
    if(!is_success){
        var ttl = redis.Do(`TTL otp:{phone_number}`)
        return errors("otp has been sent, try again in {ttl} minutes")
    }
    sendOtpViaSMS(phone_number, otp_code)
    return null
}

function VerifyOTP(phone_number, otp_code) {
    var stored_otp = redis.Do(`GET otp:{phone_number}`)
    if(!stored_otp){
        return errors(`Code has been expired`)
    } else if(stored_otp != otp_code){
        return errors(`Invalid OTP Code`)
    }
	
    redis.Do(`DEL otp:{phone_number}`)
    return null
}

Waiting List in Help Desk System (Redis for Job Queue)

Related Commands: LPUSH, RPOPLPUSH, LREM, LPOS

A help desk is a system designed to manage and streamline customer support and issue resolution processes within an organization. When the number of support request much bigger than the number of customer support it will generate a problem.

Imagine you only have 3 customer support officer and at one time there are 100 request to have chat support, how to solve it?

It’s a common where help desk system has waiting list mechanism. In technical, waiting list is similar to JOB QUEUE in data structure. Redis has a powerfull command to solve job queue problems. In a help desk system, there are at least two functions:

• Create Request (by User)

• Handle Support Request (by Customer Support)

function CreateRequest(payload){
    var request_id = createSupportRequest(payload)
    redis.Do(`LPUSH helpdesk {request_id}`)
}

function GetQueuePos(request_id){
    var my_queue_number = redis.Do(`LPOS helpdesk {request_id} RANK -1`)
    // Notes: "RANK -1" means you reverse the sort
    return my_queue_number + 1
}

function HandleSupportRequest(cs_id){
    while (true) {
        var request_id = redis.Do(`RPOPLPUSH helpdesk helpdesk:{cs_id}`)
        if(request_id == null) {
            sleep(60)
            continue
        }
        var request_detail = getSupportRequest(request_id)
        connect(cs_id, request_detail.user_id)
        redis.Do(`LREM helpdesk:{customer_support_id} 1 {request_id}`
    }
}

Search History Feature

Related Commands: LPUSH, LRANGE, LREM

Search history is a common feature that we often met in various website including e-commerce, news, etc. Everytime user searching some keywords, the keyword would be stored and will be pop up in the next searching.

Search history is basically a data structure problem, and with redis we can use list commands to build this feature.

function Search(user_id, keywords) {
    var resp = searchLogic(keywords)
    redis.Do(`LREM history:{user_id} 1 {keywords}`)
    redis.Do(`LPUSH history:{user_id} {keywords}`)
    return resp
}

function GetSearchHistory(user_id) {
    var histories = redis.Do(`LRANGE history:{user_id} 0 -1`)
    return histories
}

Redis for Shopping Cart (Add to Cart)

Related Commands: HGETALL, HINCRBY, HDEL

Shopping Cart / Add to Cart feature is commonly found on e-commerce websites or online shopping platforms. It allows users to select products they wish to purchase by clicking on the "Add to cart" button or a similar option. This action adds the chosen item to a virtual shopping cart, serving as a temporary storage before finalizing the transaction.

Once items are added to the cart, users can typically view the contents, make changes to quantities or options, and remove items if necessary. To implement the "Add to Cart" feature, a storage system is required, and Redis can be leveraged for this purpose.

See the pseudocode below on how redis can be used for add to cart feature:

function CreateAddToCart(user_id, item_id){
    redis.Do(`HINCRBY cart:{user_id} {item_id} 1`)
}

function ChangeQuantity(user_id, item_id, quantity){
    var current_qty = redis.Do(`HSET cart:{user_id} {item_id} {quantity}`)

    if(current_qty <= 0){
        RemoveAddToCart(user_id, item_id)
    }
}

function GetAllAddToCart(user_id){
    var shopping_carts = redis.Do(`HGETALL cart:{user_id}`)
    return shopping_carts
}

function RemoveAddToCart(user_id, item_id){
    redis.Do(`HDEL cart:{user_id} {item_id}`) 
}

Redis Real Time Analytics (View, Like, Transaction, etc.)

Related Commands: HGETALL, HINCRBY

Redis hash commands (with the prefix H) are commonly used by tech companies to track real-time analytics such as views, likes, transactions, and more. Implementing this functionality is straightforward and efficient using the HINCRBY command to increment the count of the data we want to track. To retrieve and display the tracked data, we can use the HGETALL or HGET command.

To gain a better understanding, let's imagine that we are an e-commerce company aiming to track real-time data on product page views, wishlists, and transactions. See the pseudocode below

function ViewProduct(product_id) {
    var product_info = getProduct(product_id)
    redis.Do(`HCINRBY product:tracker:{product_id} view 1`)
}

function Wishlist(user_id, product_id) {
    wishlistLogic(user_id, product_id)
    redis.Do(`HCINRBY product:tracker:{product_id} wishlist 1`)
}

function CreateTransaction(user_id, product_id) {
    createTransactionLogic(user_id, product_id)
    redis.Do(`HCINRBY product:tracker:{product_id} transaction 1`)
}

function GetProductStatistic(product_id) {
    var stats = redis.Do(`HGETALL product:tracker:{product_id} `)
    return stats
}

Redis for Leaderboard

Related Commands: ZADD, ZRANGE

Leaderboards are commonly utilized in gamification or competitive environments. They consist of several components, including:

• Users

• Score

• Rank

Redis sorted sets are an excellent choice for storing user data and their corresponding scores, which can then be sorted to determine ranks. Redis's exceptional speed makes it suitable for leaderboard use cases that require frequent read and write operations.

We have previously discussed the Leaderboard System Design. For more information, please refer to the article we discussed earlier.

But, Here is a sneak peek at how Redis can be used for implementing a leaderboard feature. Please find the pseudocode below:

function AddScore(user_id, score){
    redis.Do(`ZADD leaderboard {score} {user_id}`)
}

function GetTop10(){
    var top_ten_leaderboard = redis.Do(`ZRANGE leaderboard 0 9`)
    var resp = getLeaderboardDetails(top_ten_leaderboard)
    return resp
}

Redis Real Time Chat

Related Commands: PUBLISH, SUBSCRIBE

When discussing chat application, we often refer to WebSocket systems or protocols like XMPP (WhatsApp have using this in its early day). However, these solutions primarily address real-time communication challenges between the frontend and backend. While they may be suitable for single-machine systems, scaling the system horizontally can become problematic. Fortunately, Redis offers a powerful solution called PUBSUB (publish-subscribe). This mechanism allows us to leverage PUBSUB for building a chat system. Let's explore two use cases:

1. Direct Chat 1:1 Chat

2. Group Chat

Let's begin with the pseudocode for the 1:1 (direct message) chat feature.

Note: The key aspect of the 1:1 chat (direct message) feature is that the Redis key needs to be consistent, regardless of whether you are user_a or user_b. Both users should have the same Redis key string.

function generateRedisKey(){
    var user_a = your_user_id
    var user_b = target_user_id
    if(user_a > user_b){
        user_a = target_user_id
        user_b = your_user_id
    }
    return `directchat:{user_a}:{user_b}`
}

function JoinChat(your_user_id, target_user_id){
    var redis_key = generateRedisKey(your_user_id, target_user_id)
    var subscribe_handle = redis.Do(`SUBSCRIBE {redis_key}`)
    subscribe_handle.OnMessage((message) {
        if(message == "\quit") {
            return
        }
        // do something with message
    })
}

function SendMessage(your_user_id, target_user_id, message){
    var redis_key = generateRedisKey(your_user_id, target_user_id)
    redis.Do(`PUBLISH {redis_key} {message}`)
}

function CloseChat(your_user_id, target_user_id){
    var redis_key = generateRedisKey(your_user_id, target_user_id)
    redis.Do(`PUBLISH {redis_key} "\quit"`)
}

If you want to implement a group chat feature, the approach is quite similar, with the key difference lying in the structuring of the Redis keys. Let's take a look at the following pseudocode to understand it better

function JoinChat(user_id, group_id){
    var subscribe_handle = redis.Do(`SUBSCRIBE chat:group:{group_id}`)
    subscribe_handle.OnMessage((message) {
        if(message == "\quit") {
            return
        }
        // do something with message
    })
}

function SendMessage(user_id, group_id, message){
    redis.Do(`PUBLISH chat:group:{group_id} {message}`)
}

function CloseChat(user_id, group_id){
    redis.Do(`PUBLISH chat:group:{group_id} "\quit"`)
}

The chat system we've discussed so far is a simple implementation. Real-world chat systems like Twitch chat, Slack, and Discord have more complex features and requirements. However, I believe Redis can still be leveraged to build even these more complex chat systems. (Maybe later I will write special related to building chat application).

Realtime Notification

Related Commands: PUBLISH, SUBSCRIBE

Real-time notification is a useful feature that is typically used to engage your customers, such as providing announcements, promotions, and more. Marketers often utilize this feature to communicate their marketing strategies.

It is similar to how Redis can be used to build real-time chat features. By utilizing WebSockets and Redis, we can create real-time notifications. In the Redis component, we can employ PUBSUB commands to facilitate real-time notifications

function WebsocketConnect(ws_context, user_id){
    var subscribe_handle = redis.Do(`SUBSCRIBE notification:{user_id}`)
    subscribe_handle.OnMessage((message) {
        ws_context.Push(message)
    })
}

function Broadcast(user_id, message){
    redis.Do(`PUBLISH notification:{user_id} {message}`)
}

Geolocation Distance: Driver Distance & Attendance System

Related Commands: GEOADD, GEODIST, GEOSEARCH

Redis has another feature related to geolocation. This geolocation functionality is typically used in various scenarios. Here are some scenarios that you might related to:

1. Ride Hailing. You might need to find which driver that near the user and how is the distance

2. Employee Attendance System. In attendance system, checkin via mobile apps might requires geolocation checking to ensure the employee really come to the location.

3. Maps. I think we don;t need to explain what relation geolocation and map

Now we are going to focus on ride hailing and attendance system. In redis geolocation funciton can be implemented using commands with prefix GEO. Let’s start with solving ride hailing problem, which is retrieve all driver that near to the customer.

function DriverUpdateLocation(driver_id, lat, lng){
    redis.Do(`GEOADD ridehailing {lng} {lat} {driver_id}`)
}

function FindDriverNearMe(lat, lng){
    var driver_with_distance = redis.Do(`GEOSEARCH ridehailing {lng} {lat} BY BOX 100 100 KM ASC WITHDIST`)
    
    var resp = getDriverDetail(driver_with_distance)

    return resp
}

If you understand how ride-hailing services can utilize Redis geolocation to solve their problems, then understanding the usage in an attendance system becomes easy. The concept is similar, but the key difference lies in the location being searched. In ride-hailing, the location pertains to the driver, which is dynamically updated. However, in an attendance system, the location refers to the fixed company location. As a result, it needs to be pre-filled into Redis.

function PrefillCompanyLocation(){
    redis.Do(`GEOADD company_location {lng_1} {lat_1} {location_id_1}`)
    redis.Do(`GEOADD company_location {lng_2} {lat_2} {location_id_2}`)
    redis.Do(`GEOADD company_location {lng_3} {lat_3} {location_id_3}`)
}

function CheckIn(employee_id, location_id, lat, lng){
    var company_locations = redis.Do(`GEOSEARCH company_location {lng} {lat} BYRADIUS 10 M ASC`)
    
    if(company_locations[location_id] == null){
       return errors(`You are not in location range`) 
    }
    
    checkinLogic(employee_id, location_id, NOW())
    return null
}

That's all for today. It was quite a long list, but it truly highlighted the power of Redis. I suggest you learn the fundamentals of Redis and how to utilize it to solve problems in your professional life. However, keep in mind that while Redis is powerful, there may be cases where it's better to use another technology. Stay open-minded, don’t become fanatics to one technology and, in the end, remember “always get back to the fundamentals”.

Thank you for reading today's newsletter! If you find it valuable, don’t forget to:

Subscribe now

Share

Leave a comment

We will have 3 real-world questions about Software Engineers topics such as: system design, softskill, leadership, career advice and more…

To receive full access and support The Scalable, consider to subscribe us if you haven’t already!

Subscribe now

Quick Link:

• Annoying Rockstar Software Engineer

• Useless Engineer Manager

• Doesn’t Want to Grow

Annoying Rockstar Software Engineer

Question

Hi, I recently joined a company as a Senior Software Engineer. There is an Individual Contributor who has been with the company for quite some time. I categorized him as a rockstar since he has been capable of handling complex tasks in the past (based on feedback from our managers and head).

Initially, I didn't mind this Rockstar Guy until I realized that he constantly changes his approach to development. My codebase is always getting changed into a new style, which forces me to learn from scratch each time I want to improve the product. Additionally, he is uncommunicative, and I don't think I can resolve this issue by talking to my manager and head. What should I do?

Answer

From my perspective, it seems that your company lacks code standardization and a procedure for changing the standards. In larger companies, code standardization is crucial and not easy to change. Typically, there is a procedure, often referred to as an RFC (Request for Change), that needs to be reviewed and agreed upon by relevant stakeholders. Furthermore, there should be a rollout strategy in place.

If I were in your position, I would propose implementing code standardization and an RFC. However, I understand that you might not have the authority to make such decisions. That's why I believe it's still important to communicate with your manager and head. If you are hesitant to initiate communication with higher-ups, I don't think your problem can be resolved. Ultimately, you need authoritative individuals who can make decisions to address this kind of issue.

To approach the conversation, consider the following strategy:

1. Point out the problem: Highlight the need to start from scratch and the lack of communication as legitimate concerns to begin the discussion.

2. Focus on the impact in global: Emphasize the impact on the team or delivery rate, rather than simply expressing personal preferences.

3. Provide a solution: Explain how implementing code standardization and an RFC can address the issues. Elaborate on the benefits and potential positive outcomes.

In this case don’t forget to seek support from peers. Gather testimonials from other colleagues who may have also experienced these problems. Show that this is a shared concern among the team and that unity is necessary to address it.

Useless Engineer Manager

Question

Hi, I work at a small tech company and I'm currently part of a product development team, reporting to the engineering manager. Unfortunately, it seems that this EM doesn't seems understand any technical. I don't understand how this guy is able to advance his career to this level.

The most frustrating aspect is that he consistently agrees to requests from the business teams without fully comprehending the technical implications. As a result, I often have to work overtime to compensate for the poor decisions he makes. What should I do in this situation?

Answer

I have identified two problems in your story:

1. You are working overtime due to the engineering manager's reckless decisions.

2. You lack respect for the engineering manager because of his lack of technical knowledge.

Before I share my idea, let me ask you a question:

“Are you okay with his lack of technical knowledge if he doesn't burden you?”

If your answer is yes, then you need to have a conversation with the engineering manager.

• You need to let your manager know you expectation. It is clearly okay to set expectation to superior

• Let him know the situation and what really happen. If you have retrospective session then it is a good

Consider the following strategy for addressing the issue:

1. List down the specific incidents: Clearly point out instances where he made decisions without consulting the team.

2. Explain the impact on the team and the company: Highlight the inefficiency in delivery quality and the potential for burnout.

3. Propose a solution: Suggest establishing a clear scope of work and recommend that he consult with you for every decision. Ensure that all stakeholders, including other divisions such as the business team, understand that the engineering manager should not make any decision without involving the team.

However, if you have a problem with his lack of technical knowledge, it may be necessary to escalate the issue to higher authorities (such as the head or vice president) or involve HR. I understand that this situation is not ideal as it can take time and potentially damage the team atmosphere. If I were in your position, I would initially try to find a compromise with the engineering manager and gradually asking for raising the standards for the role.

Doesn’t Want to Grow

Question

I am a senior members in my team, there is a member (early mid-level) in my team doesn’t want to grow. have made several attempts to address this, such as providing examples and mapping out their weaknesses, but nothing has worked so far. But nothings worked. How to solve this issue?

Answer

If a software engineer doesn't want to grow, then they will not grow regardless of your efforts. Instead of focusing on a growth strategy, it is important to understand why they are not interested in growth and what motivates them to work.

Do they truly dislike working as a software engineer? Do they have personal problems in their life? What are their career goals? Is it primarily driven by money or a desire for a higher position?

Until the reasons behind their lack of motivation are clear, there is no need to invest time in a growth strategy. It is crucial to ensure that they understand that growth is their own responsibility. During performance reviews, the results will indicate whether they are a good fit for the company. If they are not, they may choose to leave or be let go.

Thank you for reading today's newsletter! If you find it valuable, don’t forget to:

Subscribe now

Share

Leave a comment