Forem: Ravin Rau

🌐 HTTP Status Codes: A Comprehensive Guide to API Responses

Ravin Rau — Sat, 01 Feb 2025 21:05:43 +0000

"Is this just a 200 OK? No, maybe a 202 Accepted… or wait, is it actually a 201 Created? Or should it be a 204 No Content? Why does this feel like a philosophical debate instead of a status code?"

One moment, you are confidently returning a 404 Not Found, only to realize it was actually a 403 Forbidden situation. The next, you're staring at an error log, wondering if this is more of a 503 Service Unavailable or just your sanity slowly timing out.

Deciding on the HTTP status code for my backend REST API has always been a bit tricky. I have been reading through the RFC 7231 and httpstatuses.com, and I am overwhelmed by the number of status codes available. So, in this article, I would like to provide a comprehensive guide on when to use each type of status code.

HTTP status codes are essential for communication between clients and servers in web APIs. They provide quick insights into the outcome of a request, enabling engineers to diagnose issues and improve user experiences. These codes are grouped into five classes:

1xx (Informational): The request was received, and the process is continuing.
2xx (Successful): The request was successfully received, understood, and accepted.
3xx (Redirection): Further action is needed to complete the request.
4xx (Client Error): There was an error with the request.
5xx (Server Error): The server failed to fulfill a valid request.

1xx: Informational Responses

These codes indicate provisional responses while the request is being processed.

Code	Title	When to Use / Scenario
100	Continue	Use this when the initial part of a request has been received and the client should continue sending the rest.
101	Switching Protocols	Use this when the client requests a change in protocols (e.g., from HTTP/1.1 to HTTP/2) and the server agrees.
102	Processing (WebDAV)	Use this when the server is still processing the request but no final response is yet available.
103	Early Hints	Use this with the `Link` header to tell the client to begin preloading resources while the server prepares the final response.

Best Practices:

Use 100 Continue for large payloads (e.g., file uploads) to avoid unnecessary data transfers if headers are invalid.
Reserve 1xx codes for niche cases; most APIs don’t need them.

2xx: Successful Responses

These codes indicate the request was successfully received, understood, and processed.

Code	Title	When to Use / Scenario
200	OK	Use this when a request has succeeded. It is the standard response for successful HTTP requests.
201	Created	Use this when a request has been fulfilled and has resulted in one or more new resources being created (e.g., after a successful POST request).
202	Accepted	Use this when a request has been accepted for processing, but the processing is not yet complete.
203	Non-Authoritative Information	Use this when the returned meta-information is not exactly from the origin server but from a local or third-party copy.
204	No Content	Use this when the server successfully processed the request but does not need to return any content (e.g., a successful DELETE request).
205	Reset Content	Use this when the request was successful and the client needs to reset the document view (e.g., clear a form after submission).
206	Partial Content	Use this when only part of the resource is delivered, often in response to a request with a Range header.
207	Multi-Status (WebDAV)	Use this when multiple operations need individual status reports (commonly used in WebDAV).
208	Already Reported (WebDAV)	Use this when the members of a DAV binding have already been enumerated in a previous response to prevent duplication.
226	IM Used	Use this when the server has fulfilled a request and the response is a result of instance manipulations (related to HTTP Delta encoding).

Best Practices:

Prefer specific codes (201, 204) over generic 200 responses.
For 202, provide a way to check the async task’s status (e.g., a pollable endpoint).

3xx: Redirection Messages

These codes signal that the client must take additional action to complete the request.

Code	Title	When to Use / Scenario
300	Multiple Choices	Use this when there are multiple options for the resource, and the client (or user agent) can choose one of them.
301	Moved Permanently	Use this when a resource has permanently moved to a new URI. All future requests should be directed to this new URI.
302	Found	Use this to indicate that the resource is temporarily located at a different URI. (Originally “Moved Temporarily”.)
303	See Other	Use this when the response to a request can be found under a different URI, and the client should use the GET method to retrieve it.
304	Not Modified	Use this when the requested resource has not been modified since the last request (commonly used with caching mechanisms).
305	Use Proxy (deprecated)	Deprecated: Use not recommended. It indicated that a proxy should be used to access the resource.
306	Switch Proxy	Reserved: No longer used.
307	Temporary Redirect	Use this when the resource is temporarily located at a different URI; the client should use the same method for future requests to the original URI.
308	Permanent Redirect	Use this when the resource has permanently moved, similar to 301, but the request method and body will not change when reissuing the request to the new URI.

Best Practices:

Use 301/308 for permanent redirects and 302/307 for temporary ones.
Leverage 304 to reduce bandwidth via caching.

4xx: Client Error Responses

These codes indicate the client sent an invalid request.

Code	Title	When to Use / Scenario
400	Bad Request	Use this when the server cannot process the request due to a client error (e.g., malformed request syntax).
401	Unauthorized	Use this when authentication is required but has failed or not been provided. (Different from 403; the client can try to authenticate.)
402	Payment Required	Reserved: Not typically used; originally intended for future use related to digital payment systems.
403	Forbidden	Use this when the client’s request is understood, but the server refuses to authorize it (even if authentication is provided).
404	Not Found	Use this when the requested resource could not be found on the server.
405	Method Not Allowed	Use this when the request method is not supported by the resource (e.g., sending a DELETE request to a read-only resource).
406	Not Acceptable	Use this when the requested resource is only capable of generating content not acceptable according to the Accept headers sent in the request.
407	Proxy Authentication Required	Use this when the client must first authenticate with a proxy before proceeding with the request.
408	Request Timeout	Use this when the server times out waiting for the request from the client.
409	Conflict	Use this when the request could not be processed because of a conflict in the request (e.g., simultaneous updates causing an edit conflict).
410	Gone	Use this when the requested resource is no longer available and will not be available again.
411	Length Required	Use this when the server requires the request to specify the Content-Length header, but it is missing.
412	Precondition Failed	Use this when one of the request’s preconditions (using headers like If-Match) is not met by the server.
413	Payload Too Large	Use this when the request entity is larger than what the server is willing or able to process.
414	URI Too Long	Use this when the URI provided by the client is too long for the server to process.
415	Unsupported Media Type	Use this when the request entity has a media type that the server or resource does not support.
416	Range Not Satisfiable	Use this when the client requests a portion of the file (using the Range header), but the server cannot supply that portion.
417	Expectation Failed	Use this when the server cannot meet the requirements of the Expect request-header field.
418	I'm a teapot	Humorous / April Fools': Originally defined in RFC 2324, this is not expected to be implemented on actual HTTP servers.
421	Misdirected Request	Use this when the request was directed to a server that is not able to produce a response (e.g., wrong combination of scheme and authority).
422	Unprocessable Entity (WebDAV)	Use this when the request was well-formed but could not be followed due to semantic errors (commonly used with WebDAV).
423	Locked (WebDAV)	Use this when the resource being accessed is locked, preventing further operations.
424	Failed Dependency (WebDAV)	Use this when a request fails due to a failure in a previous request (e.g., one of the dependent operations failed).
425	Too Early (Experimental)	Use this experimentally when the server is unwilling to risk processing a request that might be replayed. (Not widely used in production.)
426	Upgrade Required	Use this when the client should switch to a different protocol (often seen when secure communication is required).
428	Precondition Required	Use this when the server requires the request to be conditional (usually by adding headers like If-Match).
429	Too Many Requests	Use this when the user has sent too many requests in a given period (“rate limiting”).
431	Request Header Fields Too Large	Use this when the request’s header fields are too large for the server to process.
451	Unavailable For Legal Reasons	Use this when the requested resource cannot be provided due to legal reasons (e.g., government censorship).

Best Practices:

Avoid vague 400 errors; use specific codes (404, 429) where possible.
Return 401 for authentication failures and 403 for authorization issues.
Provide actionable error details in the response body (e.g., { "error": "Invalid API key" }).

5xx: Server Error Responses

These codes indicate the server failed to fulfill a valid request.

Code	Title	When to Use / Scenario
500	Internal Server Error	Use this as a generic error message when no more specific message is suitable. Indicates an unexpected condition on the server.
501	Not Implemented	Use this when the server does not recognize the request method or lacks the ability to fulfill the request.
502	Bad Gateway	Use this when a server acting as a gateway or proxy receives an invalid response from the upstream server.
503	Service Unavailable	Use this when the server is currently unavailable due to overload or maintenance. This is usually temporary.
504	Gateway Timeout	Use this when a server acting as a gateway or proxy does not receive a timely response from the upstream server.
505	HTTP Version Not Supported	Use this when the server does not support the HTTP protocol version used in the request.
506	Variant Also Negotiates	Use this in cases of transparent content negotiation that result in a circular reference. (Rarely encountered in typical applications.)
507	Insufficient Storage (WebDAV)	Use this when the server is unable to store the representation needed to complete the request (mainly seen in WebDAV contexts).
508	Loop Detected (WebDAV)	Use this when the server detects an infinite loop while processing a request (common in complex WebDAV operations).
510	Not Extended	Use this when further extensions to the request are required for the server to fulfill it.
511	Network Authentication Required	Use this when the client needs to authenticate to gain network access (commonly seen in captive portal scenarios, such as in public Wi-Fi networks).

Best Practices:

Avoid 5xx errors in development; they signal unhandled exceptions.
Use 503 for planned downtime and include a Retry-After header.
Log 5xx errors for debugging but mask sensitive details in responses.

Conclusion

Hopefully now when I am designing my API or handling HTTP responses, I will be able to choose the status code that best fits the situation

Hope the article above gives some clarity to you too. Mastering these codes not only improves API reliability but also enhances the development experience for everyone using your API. 🚀

🛥️ Docker Architecture: The Docker Engine

Ravin Rau — Fri, 24 Jan 2025 21:52:40 +0000

Docker’s power lies in its architecture that works behind the scenes to make containerization feel effortless. In this article, we are going to dive deep into the heart of Docker Engine and uncover the magic behind it (Docker Daemon, Docker Client (CLI), and Docker Desktop). By the end, you will get a clear picture of how these components work together to give developers the seamless experience they crave.

Docker’s Client-Server Model

At its core, Docker uses a client-server architecture. Think of it like a restaurant:

The Docker Client is the customer who places an order (e.g., “Run this container!”).
The Docker Daemon (server) is the chef who prepares the meal in the kitchen.
Docker Desktop is the friendly menu and waiter that bridges your desktop OS to the Docker environment.

The Docker Client: Your Command Center

The Docker Client is the CLI (Command Line Interface) you interact with. It’s how you send commands like docker build or docker ps to the daemon. Key features:

Translates your commands into API requests.
Works on any machine that can communicate with the daemon (local or remote).

You can use docker help or docker --help to display all available Docker CLI commands at the top level.

Example Workflow:

docker run -d nginx

The client sends the run command to the daemon.
The daemon starts an Nginx container in detached mode.
The client receives confirmation and exits, while the container runs in the background.

The Docker Daemon: The Silent Workhorse

The Docker Daemon (dockerd) is the brain of Docker. It’s a background process that manages containers, images, networks, and storage. Here’s what it does:

Listens for requests from the Docker Client (via REST API).
Builds, runs, and monitors containers.
Manages Docker objects (images, volumes, networks).

How It Works:

When you run a command like docker run, the client sends it to the daemon.
The daemon checks if the image exists locally. If not, it pulls it from a registry.
It creates and starts the container using components like containerd and runc (OCI-compliant tools).

Docker Desktop: The User-Friendly Gateway

Docker Desktop wraps the Docker ecosystem into a sleek app for macOS, Windows, and Linux. It includes:

The Docker Daemon, Client, and CLI tools.
A GUI dashboard for managing containers, images, and volumes.
Kubernetes integration and development-friendly features (e.g., file sharing, networking).

Why Use Docker Desktop?

Simplifies setup (no manual daemon configuration).
Manages OS-specific quirks (e.g., Linux VM on Windows/Mac).
Great for beginners and GUI lovers.

Under the Hood: Containerd and runc

While the Docker Daemon handles high-level tasks, it delegates low-level container operations to specialized tools like containerd and runc

containerd is a daemon that manages the complete container lifecycle (pulling images, creating containers, managing storage, etc.). Docker uses containerd under the hood, but you can interact with containerd directly via its CLI (ctr).

runc is a lightweight CLI tool for spawning and running containers according to the OCI (Open Container Initiative) runtime specification. It is the underlying tool Docker (via containerd) uses to run containers.

# Pull an image (e.g., Alpine Linux)
sudo ctr images pull docker.io/library/alpine:latest

# List images
sudo ctr images list

# Run a container
sudo ctr run --rm -t docker.io/library/alpine:latest my-alpine-container sh

This will start a shell inside the container (/bin/sh by default). Exit the shell to stop the container.

If you want to dive deep into the OCI runtime specification you can check out this paper

How Components Work Together

Let’s break down what happens when you run docker run hello-world:

Docker Client: You type the command.
Docker Daemon:
- Checks for the hello-world image locally.
- Pulls it from Docker Hub if missing.
- Uses containerd and runc to create the container.
Output: The container runs, prints a message, and exits.

Example: Debugging with Docker Client and Daemon

Imagine your container is crashing. Here’s how the architecture helps:

Use docker logs <container> (Client fetches logs from Daemon).
Run docker exec -it <container> sh to inspect the container interactively.
Check resource usage with docker stats (Daemon provides real-time data).

Conclusion

Docker’s architecture is a symphony of components working in harmony. The Docker Daemon does the heavy lifting, the Client (CLI) is your control panel, and Docker Desktop makes it all accessible. Together, they abstract the complexity of containers, letting you focus on building amazing apps.

Next week, we will dive into docker run—the command that brings containers to life. You will learn flags, use cases, and pro tips to master container execution!

Cheat Sheet: Key Docker Architecture Commands

Command	Description
`docker version`	Show Docker Client and Daemon versions
`docker info`	Display daemon configuration and system info
`docker stats`	Live view of container resource usage
`docker system prune`	Clean up unused Docker objects

Github Challenge: Arise - Mindful Morning Planner

Ravin Rau — Sun, 19 Jan 2025 05:51:11 +0000

This is a submission for the GitHub Copilot Challenge : New Beginnings

What I Built

I believe every day is a new beginning, just like Amazon’s ‘Day One’ culture. My morning routine starts with some deep breathing. I take three deep breaths and then write down the three most important tasks I want to accomplish that day. This helps me stay focused on what really matters and what I can actually get done. I’m not a big fan of having too much on my plate and working nonstop. I think the best way to be productive is to focus on just three things and do them well. That is what I have tried to do with the GitHub challenge in a day.

Arise is a mindful morning planner. Start your day with a quick minute of deep breathing and writing down the top three important things you want to tackle for the day.

Demo

Check out the app: https://arise-31p.pages.dev/

Repo

Github Repo: https://github.com/RavinRau/arise

Copilot Experience

GitHub Copilot has been a game-changer for me! From the very beginning, it’s been a lifesaver. I usually spend a good hour setting up a new Next.js project with TypeScript and Tailwind CSS. But with Copilot, it was all done in seconds! It understood my needs and guided me through creating a functional and clean base project effortlessly.

Component creation was another area where Copilot really impressed me. Whether I wanted to make a button with fancy styling or add animations with libraries like Framer Motion, Copilot’s chat suggestions were spot-on. It helped me write beautifully styled components with animations that felt both intuitive and polished. In fact, the autocomplete feature often suggested animation types and transitions that perfectly matched what I had in mind—sometimes even better than I had imagined.

One of the most exciting moments was when I was creating a store. Writing application logic for state management can be a real pain, but Copilot made it a breeze. As I started typing, its autocomplete suggestions almost read my mind, offering exactly what I needed. With just a tap of the tab key, my code was seamlessly generated, saving me tons of time and effort.

Conclusion

This hackathon was an absolute blast! Working on ‘Arise’ with Copilot was a breeze. The autocomplete and the chat feature were like having a coding buddy. They helped me stay focused and keep coding without getting distracted. I could concentrate on the core logic and user experience, knowing that my super smart AI buddy was there to lend a hand. Thanks for the challenge and for giving me the confidence that I can complete apps in a day.

🛥️ Introduction to Docker: Core Concepts

Ravin Rau — Mon, 13 Jan 2025 17:36:22 +0000

Docker is like a magic toolbox for developers. It lets them build, ship, and manage their apps in tiny, portable boxes called containers. Containers are like virtual rooms, but they are way faster and more efficient than traditional virtual machines (VMs). Thanks to Docker, containers have become super popular, and they’re now a must-have part of modern software development.

What is Docker?

Docker is an open-source platform that automates the deployment of applications inside containers. Containers are isolated environments that contain everything needed to run an application, including the code, runtime, libraries, and system tools. Docker provides developers with tools to build, manage, and distribute these containers.

What is the Open Container Initiative (OCI)?

The Open Container Initiative (OCI) is an open governance structure established in 2015 by the Linux Foundation. It aims to create industry standards for container runtime and image specifications, ensuring interoperability across container ecosystems.

Docker originally developed its own container runtime and image formats. However, the rise of containers and the need for broader standardization led Docker to contribute its container runtime technology, runc, to the OCI. Today, Docker’s ecosystem adheres to OCI standards, making Docker containers compatible with other OCI-compliant runtimes and tools.

By aligning with OCI standards, Docker ensures that its containers and images can run across various platforms and tools, fostering a more open and collaborative container ecosystem.

Why are Containers Useful?

Portability: Containers can run on any system that supports OCI-compliant runtimes, ensuring that applications behave consistently across environments.
Efficiency: Containers share the host system's kernel, making them lightweight and fast to start compared to VMs.
Scalability: Containers can be easily scaled up or down to handle varying loads.
Consistency: Containers reduce the "it works on my machine" problem by encapsulating all dependencies and configurations.

Containers vs. Virtual Machines vs. Bare Metal

Bare Metal:

Runs directly on physical hardware without any virtualization.
Offers maximum performance and direct access to hardware resources.
Best suited for high-performance workloads and applications that require complete control over hardware.

Virtual Machines (VMs):

Include a full OS, making them heavier.
Require more resources and take longer to start.
Suitable for running multiple OS environments on a single physical machine.

Containers:

Share the host OS kernel, making them lightweight.
Use less memory and start quickly.
Ideal for microservices and rapid deployments.

Aspect	Containers	Virtual Machines	Bare Metal
Resource Efficiency	High	Moderate	Highest
Startup Time	Seconds	Minutes	N/A
Isolation	Process-level	Full OS-level	Complete physical isolation
Portability	Very High	Moderate	Low
Performance	Near-native	Moderate	Native
Use Cases	Microservices, CI/CD pipelines	Legacy applications, OS testing	High-performance computing

Docker Terminology

Dockerfile: A text file with instructions for building a Docker image.
Image: A read-only template used to create containers. Images are built from a Dockerfile and follow OCI image specifications.
Container: A runnable instance of an image. Containers can be started, stopped, and deleted.
Registry: A repository for Docker images. Docker Hub is a popular public registry, and other OCI-compliant registries include Harbor and Quay.

Docker Command Line Cheat Sheet

0. Basic Docker Commands

docker --version: Check Docker version.
docker help: Show Docker commands and options.
docker info: Display system-wide information about Docker.

1. Images

docker images: List all local images.
docker pull <image>: Download an image from Docker Hub.
docker build -t <image_name> .: Build an image from a Dockerfile in the current directory.
docker rmi <image>: Remove an image.
docker tag <source_image> <new_image>: Tag an image with a new name.

2. Containers

docker run <image>: Run a container from an image.
docker run -it <image>: Run a container in interactive mode.
docker run -d <image>: Run a container in detached mode.
docker ps: List running containers.
docker ps -a: List all containers (including stopped ones).
docker stop <container>: Stop a running container.
docker start <container>: Start a stopped container.
docker restart <container>: Restart a container.
docker rm <container>: Remove a stopped container.
docker exec -it <container> <command>: Run a command inside a running container.

3. Container Management

docker logs <container>: View logs of a container.
docker top <container>: Display the processes running in a container.
docker stats <container>: Display a live stream of resource usage statistics.
docker inspect <container>: View details about a container or image.
docker rename <old_name> <new_name>: Rename a container.

4. Networking

docker network ls: List all Docker networks.
docker network create <network_name>: Create a new network.
docker network connect <network> <container>: Connect a container to a network.
docker network disconnect <network> <container>: Disconnect a container from a network.
docker network inspect <network>: View details about a network.

5. Volumes

docker volume ls: List all volumes.
docker volume create <volume_name>: Create a volume.
docker volume inspect <volume>: Display detailed information about a volume.
docker volume rm <volume>: Remove a volume.

Example: Creating a Simple Docker Container

Let's create a simple Docker container that runs a Python script.

Create a Python Script: Save the following code in a file named app.py:

   print("Hello, Docker!")

Create a Dockerfile: Create a file named Dockerfile with the following content:

   FROM python:3.9-slim
   COPY app.py /app.py
   CMD ["python", "/app.py"]

Build the Docker Image:

   docker build -t python-app .

Run the Docker Container:

   docker run python-app

This will output:

   Hello, Docker!

Conclusion

Docker makes building, deploying, and running apps using containers is a breeze. By following the OCI standards, Docker ensures everything works together seamlessly in the container world. Containers are super efficient, portable, and scalable, which is why they’re at the heart of modern software development. If you know Docker and how it works with OCI, you can use this tech to speed up your workflows and ensure your apps work on any platform.

Next week I will dive into the docker architecture, so stay tune.

My 2025 Roadmap As An Entrepreneur

Ravin Rau — Fri, 10 Jan 2025 11:38:49 +0000

This is a submission for the 2025 New Year Writing challenge: Compiling 2025.

This year is shaping up to be a transformative one for me. After seven years in a full-time job, I am making a significant leap by joining my close friend’s startup. It’s not just a career change; it is the beginning of an entrepreneurial journey that I have always dreamed of. Alongside this, I aim to grow as a stronger engineer, contribute back to the community, explore the future of AI, and pursue some personal adventures. Here’s my roadmap for 2025:

🚀 Starting Back My Entrepreneurial Journey
💪 Becoming a Stronger Full Stack Engineer
🪴 Contributing Back to the Community
🤖 Exploring the Future of AI
⛵ A Bit of a Personal Side Quest

🚀 Starting Back My Entrepreneurial Journey

I have always been fascinated by the idea of running my own business. During my university days, I made a few attempts at entrepreneurship, but they didn’t go as planned. Those setbacks made me hesitant to try again, so I joined a startup instead of a multinational corporation for my first job. Over the past seven years, I have gained invaluable experience, polished my skills, and learned how businesses operate. Now, I feel ready to take the leap and apply what I have learned by starting something. It is a mix of excitement and nervousness, but I am determined to embrace the challenges ahead.

💪 Becoming a Stronger Full Stack Engineer

My career so far has been heavily focused on frontend development, where I have built reliable and user-friendly web applications. In 2024, I began exploring backend and DevOps technologies, diving into areas that were unfamiliar to me. This year, my goal is to master these domains and become a proficient full-stack engineer.

Being a well-rounded engineer is not just about technical skills; it is about finding cost-effective solutions and building products that are reliable, scalable, and maintainable. These skills will empower me to approach problems holistically and make better decisions, especially in the entrepreneurial world where resources can be limited.

🪴 Contributing Back to the Community

As I dive deeper into backend and DevOps, I am committed to sharing my knowledge with others. I have been writing on Dev.to for a month now, and the community has been incredibly supportive, offering feedback that has opened my eyes to new perspectives.

In 2025, I plan to write more frequently, document my learnings, and participate in Dev.to competitions to win at least one. Sharing knowledge is a powerful way to solidify what I have learned and give back to the community that has helped me grow.

🤖 Exploring the Future of AI

Artificial Intelligence and automation are reshaping the world, and I am eager to be part of this revolution. One of my goals this year is to learn more about AI, particularly in areas like Retrieval-Augmented Generation (RAG) and fine-tuning models.

AI agents fascinate me because of their potential to automate repetitive tasks, freeing up time for more creative and meaningful work. As an entrepreneur, leveraging AI will be a game-changer, enabling me to build innovative solutions efficiently. By diving into AI, I hope to create something impactful and add this valuable skill to my toolkit.

⛵ A Bit of a Personal Side Quest

This year, I also want to embrace the joy of travel. I recently returned from a trip to Bali, which left me inspired to explore more. In 2025, I would like to visit other Southeast Asian countries, India, and China. Immersing myself in diverse cultures and experiencing local lifestyles will not only broaden my perspective but also help me grow as a problem solver. Understanding people from different walks of life can offer fresh insights that are invaluable in entrepreneurship.

2025 is a year of growth, learning, and exploration for me. From taking bold steps in my entrepreneurial journey to mastering technical skills and giving back to the community, I am ready to embrace the opportunities and challenges ahead. Along the way, I will seek inspiration from new places and people, hoping to make this year truly transformative. Here is to a year of dreams, growth, and success! Wish me luck.

🎖️ The Dark Side Of Being An Engineering Manager

Ravin Rau — Fri, 03 Jan 2025 11:36:39 +0000

This is a submission for the 2025 New Year Writing challenge: Retro’ing and Debugging 2024.

2024 was a wild ride for me! It was a year of learning to accept things as they are and go with the flow. It was also a year where I saw the darker side of being an engineering manager in a startup. I was proud of being an engineering manager because I could make a real difference in people’s lives, boost team morale, and create a collaborative environment between teams. But during my second year of being an engineering manager in a startup, everything went completely upside down. Here are the challenges, lessons, and lessons I learned during the toughest year of my career.

💥 Challenges:

Balancing performance appraisals with financial constraints and no bonuses.
Keeping team spirits high during tough times and uncertainty.
Making the tough decision to lay off employees when things got even worse financially.
Leading the team through emotional ups and downs while meeting expectations.

📚 Lessons:

Being honest and open, even when delivering bad news, is super important.
Rebuilding morale means showing empathy, getting to know your team, and celebrating small successes.
As a leader, you have to make tough choices, but you can still support your team by being there for them.
Sometimes, the best way to grow is to face challenges and learn from them.

🎉 Achievements:

I helped the team get back on track by having one-on-one meetings and focusing on the little things that really matter.
I successfully led a restructured team as a proxy tech lead, and we had some amazing sprint performances! I played a key role in completing some important features that improved the company’s finances.
I came out of this experience stronger, more focused, and with a deeper understanding of what it means to be a leader.

Chapter 1: The Winds of January

The year 2024 began under a heavy cloud. January, the month of reflection and appraisal, felt unusually tense. It was the season for performance reviews—a time that typically brought a mix of anticipation and excitement. But this year, things were different. The company’s cash reserves had been significantly depleted, a harsh consequence of decisions made in 2023 that had not borne the fruits we had hoped for. Adding to this, global economic uncertainties and geopolitical conflicts had cast a long shadow over the leadership’s outlook, forcing them to take a more conservative stance.

One cold morning, my VP of Engineering approached me, his expression serious. He outlined the company’s risky financial position and explained the implications for the upcoming appraisal season: there would be no bonuses. Salary increments? Reserved only for those who had truly delivered exceptional results in 2023.

This was my second time leading performance appraisals as a manager. I knew it would be tough, but nothing could have prepared me for the weight of what lay ahead. My team had worked tirelessly—long nights, countless weekends—to ensure that the features we believed in were delivered on time. Despite our efforts, we had not achieved the outcomes we had hoped for. I braced myself for the conversations that awaited, fully aware of the disappointment that would follow.

Chapter 2: Facing the Team

I have always believed in honesty, even when the truth is hard to hear. As a manager, I refuse to make false promises, no matter how tempting it might be to cushion the blow. I gathered my team for a candid discussion, explaining the company’s situation and the reasons behind the tough decisions. Then, one by one, I conducted the individual performance reviews.

It was a delicate balance. I wanted to acknowledge their hard work and dedication while also providing fair and constructive feedback. Most of my team appreciated the transparency, even if the outcome left them disappointed. Some were disappointed, others visibly upset. A few expressed their frustration openly, their words held with resentment and sadness. I listened patiently, remaining calm and composed, even as the emotions in the room threatened to overwhelm me.

As expected, morale took a hit. The energy that once fueled our team’s collaboration and creativity seemed to dim. Some team members became quieter and less enthusiastic about their tasks. Others, to my surprise, remained optimistic, choosing to see the challenges as opportunities for growth.

Chapter 3: A New Perspective

Recognizing the drop in motivation, I decided to take action. I scheduled one-on-one sessions with each team member, not just to talk about work but to reconnect on a personal level. These conversations were crucial. They allowed me to understand their concerns, aspirations, and frustrations.

During these sessions, I tried to shift the narrative.

“Success isn’t just about titles or monetary rewards,” I told them. “It’s about growth, learning, and the impact we create. Every challenge we overcome makes us stronger.”

Some nodded in agreement; others needed more time to process. Slowly, I noticed a shift. While the sting of disappointment lingered, there was a renewed sense of purpose. We started focusing on smaller wins, celebrating progress.

Chapter 4: The Hardest Goodbye

By May, the company's financial situation had worsened. My VP of Engineering approached me again, his tone heavier than before. This time, the conversation was about reducing the size of the team. We discussed the company's state and the difficult decisions that lay ahead. By the end of the discussion, he delivered the crushing news: we had to let people go.

At first, I was in denial. This team has been with me through countless challenges. Each member brought unique strengths that contributed to our success. I pushed back, arguing passionately to protect them. But after several rounds of discussion, I came to understand the harsh reality—to keep the company afloat, sacrifices had to be made.

For the first time in my career, I faced the unbearable task of deciding who would stay and who would go. It was the hardest and most emotional decision I had ever made as a manager. Over three grueling rounds of SWOT analyses, I evaluated each team member’s capabilities, behaviors, and performance over the past two years. Eventually, I arrived at a list of names—a list I had hoped never to create.

After finalizing the list with my VP, I moved forward with the layoff conversations. These were some of the most challenging moments of my career. Letting someone go is never easy, especially when they have placed their trust in you as a leader. My team saw me as their protector, someone who shielded them from external challenges so they could focus on achieving our goals together. The weight of that expectation made the task even more heartbreaking.

Some of those I let go had families to support, and given the difficult job market, the impact was devastating. I prepared myself as best as I could, maintaining calm and composure during the conversations. Still, the immediate reactions—shock, sadness, and sometimes anger—were brutal. Even though most understood the rationale, I could not shake the feeling that I had betrayed them. It felt like I had robbed them of their drive and stolen their motivation.

Afterward, I became quiet and withdrawn in the office. The emotional toll was overwhelming, and I requested to work from home for a time. For two weeks, I wrestled with my decisions, replaying every conversation and second-guessing every choice. Sleepless nights became routine. I often found myself on my balcony, gazing at the stars, questioning the kind of person I was and whether I wanted to continue on the path of engineering management. The experience left me deeply reflective, forcing me to confront the complexities of leadership and the heavy responsibilities it entails.

Chapter 5: Stepping Into a New Role

The months of August to December 2024 marked another turning point. Following the recent layoffs, the team was undergoing a restructuring, and I was appointed as a proxy tech lead for one of the restructured teams. This role came naturally to me. Even as an Engineering Manager, I remained involved in sprints, regularly contributing as an engineer. Stepping into the tech lead position wasn’t a challenge but rather an opportunity to focus on something new while recovering emotionally from the earlier turmoil.

As a tech lead, I found the role both refreshing and rewarding. My responsibilities centered on delivery, and I quickly set about molding the team—a senior engineer and two interns or juniors—into a cohesive unit. Together, we tackled crucial features that played a significant role in helping the company secure deals and regain its financial footing. The pressure was intense, but it was also gratifying. The synergy within the team was remarkable, and for the first time in months, there was a sense of momentum. We consistently met our goals, breaking records since the company adopted Scrum.

The experience of leading this team reaffirmed my love for building and delivering impactful solutions. It also reminded me of the power of teamwork and resilience, even in the face of adversity.

Chapter 6: A Bittersweet Farewell

As the year drew to a close and management began planning for 2025, I reflected my journey. The challenges, growth, and victories all painted a vivid picture of an insightful year. But as I reflected, I realized it was time for a new chapter. This chapter doesn't involve my current company in the picture—the company that I had been with for seven years, from an intern to becoming an engineering manager.

In December, I approached my VP of Engineering and submitted my resignation letter. It was a decision made with a heavy heart and a sense of clarity. My journey with the company has been transformative. I had grown immensely, both professionally and personally. The relationships I built, the challenges we overcame, and the milestones we achieved were unforgettable. Yet, I knew it was time to explore new horizons.

Final words

Thank you very much for taking the time to read this short novel-like article. If you dream of becoming an engineering manager, don’t let this discourage you. I hope I can give you a realistic glimpse into what it is like to lead a team. Right now, I am taking a little break from my leadership role to recharge and focus on the things I love doing technically. I enjoy solving meaningful problems using technology while I recover from my energy. Does this mean I will never take up the engineering manager position again? Haha, no way! I will always be up for the challenge of improving people’s lives, but I think it is important to take some time out to reflect and improve my skills in other areas. The goal is always to become a great problem solver.

✨ 10 Books For Every Software Engineer in 2025

Ravin Rau — Mon, 30 Dec 2024 19:07:09 +0000

Throughout my seven years in tech, from being a frontend engineer to an engineering manager, I have found some amazing books that have helped me grow and stay on top of things in this ever-changing field. Here are ten books that have really made a difference in my career, divided into three sections based on how they helped me at different stages of my journey.

Please consider purchasing the original book to support the authors and publishers. The PDF versions provided here are intended solely for educational and knowledge-sharing purposes.

1. The Pragmatic Programmer: Your Journey to Mastery

This was one of the first books I read when I entered the tech world, and it shaped my approach to coding and problem-solving. Its emphasis on writing adaptable, maintainable code taught me to think ahead and work smarter. I recommend it to every engineer starting their journey.

Download The Pragmatic Programmer Book

2. Clean Code: A Handbook of Agile Software Craftsmanship

Clean Code taught me the importance of making my code readable and simple—a skill that helps me and my teammates, as well as my junior engineers. It’s a must-read for anyone who wants to write code that’s both functional and beautiful.

Download Clean Code Book

3. Think Like a Programmer: An Introduction to Creative Problem Solving

If you’re into problem-solving and coding, this book is a must-read. It taught me how to break down tricky challenges and come up with creative, logical solutions. Whether you’re a seasoned coder or just starting, this book will give you a fresh perspective and help you approach coding with a logical mindset.

Download Think Like a Programmer Book

4. Algorithms Illustrated: Programmers Curious

Algorithms became a bigger focus for me as I started mentoring junior engineers. This book, with its clear visual explanations, helped me understand and teach complex algorithmic concepts. It’s perfect for anyone who wants to grasp algorithms intuitively.

Download Algorithms Illustrated Book

5. Designing for Performance: Weighing Aesthetics and Speed

Frontend performance optimization is an art, and this book gave me the tools to master it. Balancing speed and user experience can be tricky, but the strategies here helped me deliver high-performance websites without compromising design.

Download Designing for Performance Book

6. Frontend Architecture for Design Systems: A Modern Blueprint for Scalable and Sustainable Websites

Building scalable frontend systems is no small task. This book helped me to structure design systems and create sustainable workflows. It’s invaluable for frontend engineers looking to tackle large-scale projects.

Download Frontend Architecture Book

7. Domain Driven Design: Tackling Complexity in the Heart of Software

As I grew into senior roles, understanding complex systems became crucial. Domain-Driven Design helped me navigate and simplify intricate architectures by focusing on the business domain and its core logic. It’s a must-read for anyone dealing with large-scale systems.

Download Domain Driven Design Book

8. Designing Data Intensive Applications: The Big Ideas Behind Reliable, Scalable, and Maintainable Systems

As I advanced in my career, designing robust systems became a critical part of my role. This book delves into the foundations of data systems, teaching you how to handle scalability and reliability—a must-read for anyone working on backend systems or complex architectures.

Download Designing Data Intensive Application Book

9. The Phoenix Project: A Novel About IT, DevOps, and Helping Your Business Win

When I transitioned into management, The Phoenix Project provided a relatable and insightful look into improving team efficiency. It introduced me to the principles of DevOps and systems thinking in a narrative format that’s both engaging and educational.

Download The Phoenix Project Book

10. The Unicorn Project: A Novel About Developers, Digital Disruption, and Thriving in the Age of Data

This companion to The Phoenix Project digs deeper into the developer experience and the role of innovation. It inspired me to create an environment where my team could thrive, be creative, and deliver high-quality work.

Download The Unicorn Project Book

🚀 Accelerate Your Career Path and Professional Development

Ravin Rau — Thu, 26 Dec 2024 07:11:54 +0000

This article is a bit different from the technical topics I usually write about. Since it is the holiday season—a time to reflect, recharge, and plan for the future—I thought it would be a great chance to share something more personal.

This year, I hit an important milestone: seven years in the software industry. I started as an intern in March 2018, worked my way up, and became an engineering manager in August 2022. Over the past two years in leadership, I have learned a lot about what helped me grow my career path faster.

From the start, I was known as a high-performing team member. My managers valued how I always delivered on time, and my colleagues often said I was dependable and easy to work with. Looking back, I’ve identified the key things I did that made a difference. In this article, I will share those lessons to help you grow your career path too, whether you are just starting out or looking to take the next step. I hope it motivates and guides you on your journey!

1. Being Proactive

Winners don't wait, They create

I believe in taking initiative rather than waiting passively for instructions from my manager. When tackling a feature or project, I proactively communicate my thoughts and propose potential solutions. Instead of waiting for direction, I develop a plan and share my ideas with my manager, presenting a clear problem statement along with three possible solutions for consideration. This simple 1:3:1 approach—one problem, three solutions, and one recommendation—ensures thorough preparation and provides ample room for evaluation and execution. It has been invaluable in helping me clarify my thoughts, conduct comprehensive research, and present well-informed plans.

During my free time, I often check in with my team members to understand what they are working on. This allows me to learn from their approaches while fostering collaboration. Whether through discussions or exchanging ideas, this practice strengthens team chemistry and creates a foundation for future opportunities. Building these connections not only enhances teamwork but also opens doors for innovation and collective growth.

2. Master Prioritization

Focus on what truly matters and eliminate distractions. Delegate or schedule incomplete tasks.

When I became a senior engineer, I was given the opportunity to train and mentor junior engineers and interns. This came with increased responsibilities, including attending more meetings, tackling new projects, and devising solutions. Initially, I handled it well, but as my workload grew, it became overwhelming. I found myself losing focus under the weight of numerous tasks, struggling to ensure everything was delivered on time.

Recognizing this, I reached out to my manager for advice. His response was simple yet transformative: delegate effectively. He emphasized that as a senior engineer, my primary focus should be on high-impact tasks that align with the organization’s goals. For smaller, less critical tasks, I should delegate and plan them appropriately with the team.

He introduced me to a framework that has since become an essential part of my approach: prioritize and delegate based on urgency and importance. For tasks that are urgent and critical—especially those requiring a higher level of expertise—I take ownership. For everything else, I delegate while monitoring progress.

Delegation not only allows me to focus on what truly matters but also empowers my team to take on more responsibility and grow in their roles. This approach has helped me build trust, develop leadership skills, and create a more productive team. Ultimately, mastering prioritization and delegation played a significant role in my transition to an engineering manager role, enabling me to lead effectively and deliver impactful results.

3. Set Ruthless Goals

My goals inspire and drive me. I review them every three months.

I have always been passionate about setting and achieving goals. From a young age, I’ve been obsessed with tracking metrics, setting clear targets, and working methodically to reach them. I take the time to learn and understand what is needed to achieve my objectives, which keeps me focused and motivated. For me, life feels like an exciting game where each goal is a new level to conquer.

Every three months, I review my goals, evaluate my progress, and identify what adjustments I need to make to stay on track. This regular check-in helps me maintain focus and adapt as needed to ensure success.

When I started working, I found that this personal habit aligned perfectly with professional practices like OKRs (Objectives and Key Results) and bi-weekly sprints. These structured frameworks allowed me to thrive, as they matched the way I’ve been operating for most of my life. Setting clear goals with a defined timeframe enables me to enter a state of flow, where I am deeply immersed in my work and highly productive.

This habit has also made me an effective planner. I have become skilled at creating actionable strategies to ensure that my team and I can deliver on our commitments. Reviewing and refining goals consistently not only fuels my motivation but also drives meaningful progress in both my personal and professional life.

4. Being Optimistic

Develop a gratitude practice and surround yourself with people who energize you.

One of the habits I developed early in life that accelerated my career growth is practicing gratitude. People are naturally drawn to those who appreciate others and work collaboratively rather than those who take all the credit or act like they’re always the best. My ambition has never been just about winning; it is about learning, exploring, and achieving broader goals. To do that, I need a team that motivates and energizes me.

When you work with people who inspire you, it creates a positive feedback loop. You push each other to perform better, learn more, and reach new heights. For example, every time my team completes a project or meets a tough deadline, we make it a point to celebrate and acknowledge each other’s contributions. It could be as simple as thanking a colleague during a meeting or writing a LinkedIn post highlighting the team’s success.

This approach not only strengthens team morale but also catches the attention of higher-ups. Gratitude and positivity can open doors to new opportunities and help you stand out as someone people want to collaborate with. In the end, it’s not just about what you achieve individually—it’s about what you achieve together.

5. Never Stop Learning

Learning isn't optional; it's a lifeline.

In the tech industry, things change fast. Languages evolve, frameworks come and go, and new tools pop up every year. The only way to stay relevant is to keep learning. Think of learning as your career's heartbeat—without it, progress stops.

I remember when React.js was first becoming popular. I had a solid foundation in JavaScript and thought I was good to go. But when my team switched to React for a new project, I felt like a beginner again. Instead of resisting, I took it as an opportunity to learn. I stayed up late, went through documentation, and even built small projects on the side to grasp the concepts. That decision not only helped me deliver in that project but also set me up for more opportunities in frontend development.

Successes, failures, and feedback are also your greatest teachers. I once led a feature rollout that failed miserably due to miscommunication. Initially, it stung. But when I sat down to reflect, I realized where we went wrong and implemented changes in our workflow. That failure taught me lessons I couldn’t have learned from any book.

6. Think Beyond Today.

Plan for tomorrow like your life depends on it.

If you want to grow, you need to think ahead—always be 10 steps in front of where you are now. Early in my career, I had a habit of just completing tasks assigned to me. It kept me busy, but it didn’t help me grow. Then one day, one of my mentor told me, “Good engineers solve problems, but great engineers foresee them.”

That stuck with me. Now, I don’t just plan my day; I strategize for the week, the month, and even the year. When I was leading a project migration to a new technology stack, I spent weeks identifying potential pitfalls and mapping out solutions before they even became problems. This forward-thinking approach saved the team countless hours and built trust in my leadership skills.

Life and technology are like a game of chess—always think a few moves ahead.

7. Be Accountable

Win or lose, own it.

Accountability is the hallmark of true professionalism. If something goes wrong, the last thing people want is finger-pointing. Instead, they respect someone who takes ownership and works to make things right.

I remember leading a project where an important deadline was missed because I underestimated the complexity of the task. Instead of making excuses, I told my manager, “This was on me. Here’s what went wrong, and here’s how I will ensure it doesn’t happen again.” I worked overtime, coordinated with the team, and we eventually delivered a solid product. My manager came up to me after that and congratulated me on a great comeback.

This incident taught me that accountability builds trust. People want to work with someone who takes responsibility for their actions and outcomes, whether good or bad. It also made me focus on improving my planning and risk management skills.

This is something I am currently focusing on, and sometimes I wish I had started earlier, as it has a powerful compounding effect over time.

8. Network Everywhere You Go

Opportunities are made in conversation, not cubicles

During university, I actively participated in events and community service programs. These experiences broadened my perspective and kept me informed about the world around me. However, when I entered the workforce, I shifted my focus entirely to developing my skill set and creating a meaningful career impact.

For five years, I dedicated myself to deliberate growth and eventually reached the pinnacle of my current role, becoming the most experienced member of my department. That is when I realized I needed to step outside my comfort zone again. I began networking, connecting with new people, and broadening my exposure to diverse perspectives.

Networking is not limited to just your team or department. Engaging with people from other teams, disciplines, or industries opens the door to fresh ideas and helps you understand the challenges others face. This expanded exposure allows you to contribute beyond your immediate role, making a broader impact.

More importantly, networking creates opportunities—not just for personal growth but also for career advancement. The relationships you build today could lead to exciting opportunities tomorrow. By actively connecting with others, I have not only revitalized my professional journey but also laid the groundwork for exploring new roles and challenges in the future.

The Dark Side of Accelerating Your Growth

Accelerating your career growth can be exciting, but it is important to acknowledge the challenges that come with it. Here are a few realities I’ve encountered on this journey, along with lessons I have learned along the way.

1. Risk of Burnout

When you are focused on growing quickly, it is easy to push yourself too hard. Early in my career, I had the advantage of fewer personal commitments, which allowed me to take on challenging projects and work long hours. However, without proper boundaries, I found myself physically and mentally drained at times.

Burnout is a real risk when you are constantly striving to outperform yourself. I have learned that it is important to prioritize self-care and set limits. Taking breaks, learning to say no, and focusing on tasks that truly matter have helped me stay productive without burning out.

2. Embracing Loneliness

As you grow, you will often find yourself moving to new teams or taking on roles that set you apart from your peers. This constant change can sometimes feel isolating. I remember switching teams frequently as I took on new challenges, and while it was exciting, it also meant that I wasn’t always able to form lasting bonds with colleagues.

Over time, I learned to embrace this loneliness as part of my personal development. It pushed me to build stronger communication skills and adapt to different work environments. It is not always easy, but finding ways to connect with others—even in small moments—can help you feel grounded.

3. Sacrificing "Young Enjoyment"

Focusing on career growth early in life often means sacrificing some of the carefree moments others enjoy. I skipped out on late-night hangouts and weekend trips with friends because I was prioritizing work and self-improvement. Looking back, I sometimes feel like I missed out on those memories.

That said, I don’t regret the choices I made. The work I put in has paid off, but it has also taught me to find a better work life balance. Now, I try to set aside time for personal relationships and experiences, realizing that career growth success doesn’t have to come at the expense of a fulfilling personal life.

Check out my linkiden where I often update about my career journey. Thank you for taking the time to read this! I hope the article gave you useful tips and ideas to help you succeed in your career. Feel free to share your own career growth advice in the comments!

🎄CSS Art: December Challange - Christmas In Malaysia ✨

Ravin Rau — Sun, 22 Dec 2024 18:01:41 +0000

This is a submission for Frontend Challenge - December Edition, CSS Art: December.

Inspiration

I’m from Malaysia, a tropical country where we celebrate Christmas as a festive holiday. The malls here are beautifully decorated, making it a magical time to enjoy the season. While we don’t have snow, every year there’s a fun celebration at the KL Twin Towers where fake snow is dropped from the top—it's such a cool sight! You can check it out here. Inspired by this, I imagine how amazing it would be to have the KL Twin Towers inside a snow globe!

And below is the result of the imagination.

Demo

Journey

So, I got the idea to create a snow globe using HTML Pug and Scss. I started by checking out what others had done with snow globes online. That’s when I found this cool codepen here. I was inspired by it and started working on my own project. It was really exciting when I finally reached the final result and could see the iconic KL Twin Tower in the snow globe. It took me about 8 hours to work on it, and I’m pretty happy with how it turned out. I’d love to spend more time on this challenge and try to make it even better by adding more details like Christmas lights.

Thanks for reading this and for those celebrating Merry Christmas and a Happy New Year.

6 Types of Git Branching Strategy for DevOps

Ravin Rau — Fri, 20 Dec 2024 18:56:15 +0000

Summary

In modern software development, Trunk-Based Development and GitHub Flow are often favored for their simplicity and support for continuous integration and deployment. Trunk-Based Development encourages rapid integration with minimal branches, promoting collaboration and fast iteration. GitHub Flow, with its straightforward feature branching and immediate deployment, aligns well with CI/CD pipelines, making it ideal for fast-paced projects. Both strategies require strong automated testing to ensure stability. For larger teams or complex projects, Gitflow offers a structured approach with clear workflows, though it demands strict adherence to processes. Ultimately, the best approach depends on team size, project complexity, and deployment needs.

Git branching strategies are like roadmaps that teams use to organize their work, keep track of different code versions, and work together smoothly in version control. And guess what? Having a consistent naming convention for branches is like having a secret code that makes communication and collaboration a breeze within the team. But here’s the thing, the best branching strategy for your team depends on what you need, how complex your project is, and how you deploy your code. So, let’s dive into the major Git branching strategies, their ups and downs, and when to use them.

1. Main-Only Strategy

The main branch is the only branch used for development and deployment. All changes are committed directly to it.

When to Use:

Small teams with minimal collaboration.
Projects with short lifecycles and low complexity.
Rapid prototyping or proof-of-concept work.

Pros:

Simple: Easy to understand and manage.
No merge conflicts: Since there are no additional branches, conflicts are minimal.
Ideal for small teams: Works well for projects with few contributors.

Cons:

Risky: Direct changes can lead to instability if errors are introduced.
Lack of history: It’s harder to track the development process for individual features.
No isolation: No separation for testing or experimenting with changes.

2. Feature Branching

Each feature or bug fix is developed in its own branch. Developers should follow best practices such as regularly merging changes from the main branch into the feature branch to keep it updated and prevent merge conflicts. Once the feature or fix is complete and thoroughly tested, the branch is merged into the main branch.

When to Use:

Teams working on multiple features at once.
Projects requiring clear tracking of features or tasks.
Scenarios where risk of breaking production needs to be minimized.

Pros:

Clear isolation: Changes for each feature are isolated from the main codebase.
Better collaboration: Multiple developers can work on different features simultaneously.
Easy rollback: If a feature is buggy, its branch can be discarded without affecting others.

Cons:

Merge conflicts: Frequent merging can lead to conflicts.
Overhead: Requires discipline to regularly merge and update branches.

3. Gitflow

Gitflow is a structured branching strategy that uses multiple branches like main, develop, feature, release, and hotfix. Branch naming conventions play a crucial role in maintaining clarity and consistency. For example:

Feature branches: /feature/{{author}}/{{card-number}}/{{short-description}} (e.g., /feature/john/1234/add-login)
Hotfix branches: /hotfix/{{issue-number}} (e.g., /hotfix/5678)
Release branches: /release/{{version}} (e.g., /release/1.2.0)

When to Use:

Teams with well-defined release cycles.
Large or complex projects requiring high stability.
Scenarios where roles and responsibilities are clearly defined.

Pros:

Well-organized: Provides a clear workflow for development, testing, and deployment.
Supports large teams: Effective for projects with many contributors.
Release isolation: Ensures stability during release preparation.

Cons:

Complex: Requires strict adherence to rules and workflows.
Overhead: Managing multiple branches can be time-consuming.
Slow pace: Not ideal for rapid or continuous deployment needs.

4. GitHub Flow

GitHub Flow is a simplified strategy focused on continuous delivery. To maintain consistency, teams can adopt a branch naming convention such as /{{author}}/{{short-description}} (e.g., /alice/add-login-button). This ensures clarity while keeping the approach straightforward. Developers create feature branches, merge them into the main branch, and deploy immediately.

When to Use:

Teams practicing continuous integration and deployment.
Smaller projects with fast-paced development cycles.
Cloud-based or SaaS applications requiring frequent updates.

Pros:

Simple: Easy to learn and implement.
Continuous deployment: Encourages shipping small, incremental changes.
Ideal for CI/CD pipelines: Works well with automated testing and deployment.

Cons:

No long-term branches: Lacks structure for handling long-term development or pre-release testing.
Potential instability: Main branch must always be production-ready, requiring thorough testing in feature branches.

5. Trunk-Based Development

In trunk-based development, all developers commit directly to the main branch or use short-lived branches that are merged quickly. For short-lived branches, a naming convention like /fix/{{bug-id}} (e.g., /fix/1234) or /task/{{id}} (e.g., /task/5678) can help maintain clarity and traceability during rapid iterations.

When to Use:

Agile teams practicing frequent releases.
Scenarios with strong automated testing and CI/CD pipelines.
Projects requiring high collaboration and fast iteration.

Pros:

Fast: Encourages rapid integration and deployment.
Minimal branches: Reduces complexity and merge conflicts.
Encourages collaboration: Promotes frequent communication and code reviews.

Cons:

Risk of instability: Main branch can become unstable if proper testing isn’t enforced.
High discipline required: Requires strict code review and testing processes.

6. Release Branching

Separate branches are maintained for each release version, often labeled with version numbers.

When to Use:

Projects with long-term support (LTS) requirements.
Scenarios where maintaining multiple release versions is critical.
Enterprise applications needing well-documented release histories.

Pros:

Version control: Clear history of all releases.
Stable main branch: Maintains a clean and production-ready main branch.
Supports patching: Allows bug fixes for specific releases without affecting others.

Cons:

Branch proliferation: Too many branches can become unmanageable.
Slower pace: Not ideal for fast-moving projects.

Choosing the Right Strategy

Here are some factors to consider when selecting a branching strategy:

Team size: Smaller teams may prefer simpler strategies like main-only or GitHub Flow, while larger teams benefit from structured approaches like Gitflow. Use consistent branch naming conventions, such as /feature/{{author}}/{{card-number}}/{{description}} for Gitflow or /{{author}}/{{short-description}} for GitHub Flow, to maintain clarity.
Project complexity: Complex projects often need more organization, making Gitflow or release branching ideal. For example, Gitflow can use /hotfix/{{issue-number}} for critical fixes or /release/{{version}} for release preparation.
Deployment needs: Continuous deployment works best with GitHub Flow or trunk-based development. Short-lived branches in trunk-based development can follow formats like /fix/{{bug-id}} or /task/{{id}} for traceability.
Testing and stability: If testing and stability are critical, Gitflow or release branching provides better control with clear branch naming practices.
Development pace: Fast-moving projects benefit from trunk-based development or GitHub Flow, where lightweight branch naming conventions like /{{author}}/{{short-description}} are effective.

Conclusion

No single Git branching strategy fits all projects. The key is to align the strategy with your team’s workflow, project needs, and goals. Start with a strategy that suits your current needs and be open to evolving it as your team grows and your processes mature.

Comment below what your favorite branching strategy is and how effective it has been with your team members.

Happy branching!

References

Branching Strategies Explained
Branching strategies: GitHub Flow and Git Flow

Clean Code Essentials: YAGNI, KISS, DRY

Ravin Rau — Tue, 17 Dec 2024 11:04:22 +0000

In the world of software engineering, where clean code and efficient design patterns reign supreme, three principles stand out as guiding lights: YAGNI, KISS, and DRY. These principles are not just buzzwords; they are the foundation of effective software development. Whether you're a seasoned developer or just starting your coding journey, understanding these concepts can transform the way you approach building software.

In this article, we'll dive into the heart of these principles. We'll explore how YAGNI (You Aren't Gonna Need It) helps prevent unnecessary complexity, how KISS (Keep It Simple, Stupid) encourages straightforward solutions, and how DRY (Don't Repeat Yourself) promotes code reusability. By the end, you'll see how these principles can lead to cleaner, more maintainable code and ultimately make you a more efficient software engineer. So, let's get started!

YAGNI - You Aren't Gonna Need It.

It's a principle in software development that reminds us to only implement features when they are actually needed, not when we think they might be needed in the future. The idea is to avoid over-engineering and keep things simple.

Why Do We Need to Use YAGNI?

Using YAGNI helps prevent unnecessary complexity in your code. When you add features or code that you don't currently need, you increase the chances of introducing bugs and make your codebase harder to maintain. By sticking to YAGNI, you focus on what's essential, saving time and resources.

How to Use the YAGNI Principle

To apply YAGNI, always ask yourself if a feature is necessary right now. If it's not, don't build it. Prioritize the current requirements and resist the temptation to plan for every possible future scenario. This approach keeps your code lean and focused.

KISS - Keep It Simple, Stupid.

It's a principle in software development that encourages simplicity in design and implementation. The idea is to avoid unnecessary complexity and make things as straightforward as possible.

Why Do We Need to Use KISS?

Using the KISS principle helps make your code easier to read, understand, and maintain. Complex solutions can be difficult to debug and extend, while simple solutions are more robust and flexible. By keeping things simple, you reduce the risk of errors and make it easier for others (and your future self) to work with your code.

How to Use the KISS Principle

To apply KISS, always aim for the simplest solution that meets the requirements. Avoid overengineering and resist the temptation to add unnecessary features or complexity. Focus on clarity and straightforwardness in your code and design.

DRY - Don't Repeat Yourself.

It's a principle in software development that emphasizes the importance of reducing repetition in your code. The idea is to have a single, unambiguous source of truth for every piece of knowledge or logic in your codebase.

Why Do We Need to Use DRY?

Using the DRY principle helps make your code more maintainable and less error-prone. When you have duplicate code, any change or bug fix needs to be applied in multiple places, increasing the risk of inconsistencies and errors. DRY ensures that you only need to make changes in one place, making your code easier to manage and understand.

How to Use the DRY Principle

To apply DRY, look for repeated code or logic in your codebase and refactor it into a single, reusable component. This could mean creating functions, classes, or modules encapsulating repeated logic. Always aim to consolidate similar code to avoid duplication.

Conclusion

In the journey of software development, embracing the principles of YAGNI, DRY, and KISS can make a world of difference. By focusing on what's necessary with YAGNI, reducing repetition with DRY, and keeping things straightforward with KISS, you can create cleaner, more maintainable code. These principles not only help you write better software but also make your development process more efficient and enjoyable.

Remember, the goal is to build software that is easy to understand, modify, and extend. By applying these principles, you set a strong foundation for your projects and make life easier for yourself and your team.

Stay tuned for our next article, where we'll dive into the SOLID principles, another set of guidelines that can help you become an even more effective software engineer. Happy coding!

Reference

Do check out Clean Code to understand more in-depth on the best practices.
Comic Strip made possible by people from Open Peeps

🦸 Supercharge your debugging skills with the console.trace

Ravin Rau — Fri, 13 Dec 2024 18:34:50 +0000

Summary

🔍 What's your debugging superpower? Mine was discovering console.trace() - it turned hours of debugging into minutes by revealing the exact execution path in my code. Share your game-changing debugging tool that transformed your development workflow in the comment section below!

Skip the intro to go into the gist of the content

Introduction

When I first started coding, I relied heavily on console.log to debug and understand how my code was working. I think many of us have been there—sprinkling console.log statements everywhere to track down a pesky bug. But as our applications grow and we collaborate with larger teams, this approach can quickly become chaotic.

I remember one particular bug that had me stumped. It was related to a service I knew well, so I confidently took on the task. After two hours of diving into multiple files and littering my code with console.log statements, I was still no closer to finding the root cause. Frustrated, I reached out to a senior developer for help. That's when I was introduced to the magic of console.trace.

For the first time, I could see the stack trace of function calls, giving me a clear view of the execution flow. It was like having a map instead of wandering in the dark, guessing where to place my console.log statements.

Share your personal experience in the comment section below on which debugging tools help you to debug issues faster.

Debugging is a crucial part of software development, and JavaScript offers several tools to make this process easier. Two of the most common are console.log and console.trace. Let's dive into how these tools can be used effectively, using a simple bookstore application as an example.

If you want to play around with the services with the console.log and console.trace, visit my github repo link here.

What is `console.log`?

console.log is a method used to print messages to the console. It's often used to display variable values, track the flow of execution, or simply output information for the developer.

When to use it : Use console.log when you need to output simple messages or variable values. It's great for quick checks and confirming that certain parts of your code are executing as expected.

What is `console.trace`?

console.trace is a more advanced debugging tool that not only logs a message but also provides a stack trace. This stack trace shows the sequence of function calls that led to the point where console.trace was called, which can be invaluable for understanding the flow of execution and identifying where things might be going wrong.

When to use it: Use console.tracewhen you need more context about the execution flow. It's particularly useful for complex applications where understanding the call stack can help diagnose issues.

Scenario: 🦹 Debugging a Mysterious Order Total Calculation

Let's say we are getting a customer complaints that order totals are incorrect. Here's how we can demonstrate the power of console.trace() vs console.log():

First, let's modify the OrderService.js to include both debugging approaches:

class OrderService {
    calculateTotal(items) {
        console.log('Calculating total for items:', items);  // Traditional approach

        const total = items.reduce((total, item) => {
            const book = this.bookService.getBook(item.bookId);
            console.trace('Book price calculation');  // Using console.trace
            return total + (book.price * item.quantity);
        }, 0);

        return total;
    }
}

When you run this with an order that has incorrect totals, here's what you'll see:

With console.log():

Calculating total for items: [
  { bookId: 'book1', quantity: 2 },
  { bookId: 'book2', quantity: 1 }
]

With console.trace():

Trace: Book price calculation
    at OrderService.calculateTotal (src/services/OrderService.js:40)
    at OrderService.createOrder (src/services/OrderService.js:27)
    at Object.<anonymous> (src/index.js:27)

The console.trace() output immediately shows us the entire call stack, revealing that:

The calculation starts in index.js
Goes through createOrder
Then hits calculateTotal

This becomes particularly valuable when you have multiple services calling each other. For example, if we look at the order creation flow in:

    createOrder(userId, items) {
        // console.trace('Creating order');  // Using console.trace

        const user = this.userService.getUser(userId);
        if (!user) {
            throw new Error('User not found');
        }

        // Verify all books are available
        for (const item of items) {
            if (!this.bookService.checkBookAvailability(item.bookId, item.quantity)) {
                throw new Error(`Book ${item.bookId} not available in requested quantity`);
            }
        }

        const order = {
            orderId: Math.random().toString(36).substr(2, 9),
            user: user,
            items: items,
            total: this.calculateTotal(items),
            status: 'pending'
        };

        // Process billing
        this.billingService.processBilling(order);

        return order;
    }

If we add console.trace() in the processBilling method, we can see the complete chain of service calls:

// In BillingService.js
processBilling(order) {
    console.trace('Processing billing');
    return this.createInvoice(order);
}

This would output:

Trace: Processing billing
    at BillingService.processBilling (src/services/BillingService.js:3)
    at OrderService.createOrder (src/services/OrderService.js:32)
    at Object.<anonymous> (src/index.js:27)

This trace immediately shows us:

Which file initiated the billing process
The exact sequence of method calls
The specific line numbers where each call occurred

This is particularly useful when debugging issues in a complex system where multiple services interact, like in this bookstore application

Without console.trace(), you might need multiple console.log() statements across different files to understand the execution flow. With console.trace(), you get the complete picture in one go.

✨ Best Practice Tip

Add console.trace() at critical points where services interact with each other, especially in methods that:

Handle financial calculations
Process user transactions
Interact with multiple services
Have complex conditional logic

This way, when issues arise, we can quickly understand the exact path our code took to reach that point.

Conclusion

Both console.log and console.trace are powerful tools for debugging, each serving different purposes. By using them appropriately, you can gain better insights into your application's behavior and more effectively identify and fix issues. Share your game-changing debugging tool that transformed your development workflow in the comment below!