The best part?

With the right approach, you can set yourself up for success and integrate into your new role while making great first impressions.

We will go over a 14-step plan that will help you ensure a smooth onboarding and that you’re set for success in your new job.

1. Clarify Your Role and Expectations Early

When you first start, it’s easy to get overwhelmed by new tools, workflows, and processes. But without clarity about what’s expected of you, it’s hard to sense if you’re heading in the right direction.

The best thing you can do early on is sit down with your manager and ask directly about the key goals for your role. This isn’t just about knowing what tasks you’ll be tackling but understanding the larger context of how your work fits into the company’s vision.

By aligning yourself with the broader mission, you’ll ensure that you’re adding value from the start and clearly understand what success looks like.

2. Get Comfortable with the Tech Stack and Tools

A new job can sometimes feel like an endless sea of tools and technologies to learn. Whether it’s a new programming language, a framework, or an internal tool, each piece plays a critical role in your daily workflow. The key here is to focus on getting comfortable, not mastering everything at once. Start by familiarizing yourself with debugging tools and the team’s daily-use tools.

As you go deeper, you’ll naturally identify areas that require more focus, but starting with a broad understanding will help you hit the ground running.

3. Absorb the Codebase Like a Sponge

Understanding the codebase is crucial for your long-term success. At first, it might feel overwhelming, especially if the codebase is vast or complex. Start by exploring the key modules and understanding how data flows through the system. Look at how the app handles requests, processes data, and communicates with external services. Instead of just reading through the code, try to visualize the structure. Over time, you’ll better understand the code’s architecture and how each part fits together.

4. Dive into Onboarding Documentation

Most companies provide some form of onboarding documentation, and it can be tempting to skim through it, especially when you’re eager to jump into the action. Spending time with these materials can save you hours of confusion later.

From company policies to technical workflows, onboarding docs are your go-to reference for understanding the company’s expectations and practices. Highlight important points, and jot down questions.

5. Build Relationships with Your Team

Tech is a collaborative field, and your success as an engineer is often tied to the relationships you build. Get to know your teammates, not just as co-workers but as people. Understanding their strengths, communication styles, and work habits will make it easier to collaborate. These initial relationships provide a support network when things get challenging, helping you navigate the tech culture and beyond.

6. Understand the Product Deeply

While diving into the technical side of things, don’t forget to get acquainted with the product you’re building. Take time to use the product as an end-user. Understanding the problems the product is solving gives you a solid foundation to make decisions that directly impact users. The product is more than just code; it’s what makes your technical efforts meaningful.

7. Get Familiar with Development Workflows

Each team has its approach to work. Whether you’re using Scrum, Kanban, or some hybrid model, understanding your team’s development workflows is essential. Get familiar with how the work is organized, and how tasks are assigned, tracked, and reviewed. Knowing how things move from one stage to another helps you understand where your contributions fit in.

8. Learn the Testing and CI/CD Pipelines

Tech is all about quality, and quality comes from great testing and continuous integration. Early in your journey, understanding how the team tests code and manages releases is invaluable. By aligning with these practices early, you’ll avoid unnecessary headaches down the road and contribute reliable code to production.

9. Participate in Code Reviews

Code reviews are one of the most effective ways to learn and improve. Observe how your colleagues approach different problems, structure their code, and follow patterns. Contribute feedback on other people’s PRs to develop a critical eye for good code. When it’s time for your code to be reviewed, be open to feedback and use it as a chance to grow.

10. Understand the Deployment Process

Knowing how your team deploys software to production is crucial. Understand the deployment pipeline, how rollbacks are handled, and what post-deployment monitoring looks like. Familiarizing yourself with these processes early on will make you confident about pushing code live and prepared to handle any issues that arise.

11. Ask Questions, Even the Obvious Ones

No one expects you to know everything right away. Asking questions shows you’re engaged and committed to doing your job well. Don’t hesitate to clarify anything that seems unclear; curiosity is a sign of dedication.

12. Tackle Small Wins Early

Look for smaller tasks you can complete to build momentum. Whether it’s fixing a bug, refining a piece of code, or improving documentation, these small wins will help you gain confidence and establish your place in the team.

13. Document What You Learn

As you learn new concepts, internal tools, and team practices, create your reference library. Over time, this becomes an invaluable resource for your growth and helps you onboard future colleagues more effectively.

14. Network Beyond Your Team

To thrive, you need to collaborate across teams. Connect with people from different areas of the company to build cross-functional relationships. This broader perspective will help you see the bigger picture and make your work more impactful.

Make the Most of Your Onboarding Journey

Onboarding is your launchpad in a new role, and how you approach it can shape your entire experience. Stay proactive, ask questions, and keep learning. Success doesn’t come from just showing up; it comes from actively shaping your path forward.

👉 Checkout my blog
🐦 Follow me on X

Every engineer should know how to build resilient systems. I learned this In the several fast-paced startup environments I worked at, where rapid iterations, shifting priorities, and limited resources are the day-to-day norm.

In startups, Growth and learning opportunities are huge, but this comes at the cost of having to wear multiple hats. Launching new features and growing the product are essential, but what determines the success or failure of a feature is system resilience. Without it, features will be a customer’s pain point rather than an added value. This can cost users, reputation, and even cripple the business.

In this article, We will explore what every engineer needs to know about Software Reliability Engineering (SRE).

Resilience Starts with the Engineer

Resilience is the ability of a system to recover from failure, and it’s a responsibility shared by every engineer, no matter their role or company size. Every decision, from design to deployment, impacts system reliability. Engineers must build systems that can handle failures gracefully.

Imagine facing a sudden traffic surge due to a marketing campaign. A third-party API integration begins to timeout, causing some functionality to fail. This leads to wasted marketing efforts, a poor user experience, and I am pretty sure it will cause an increase in bounce rates and a decrease in retention for first time customers.

If caching or a backup integration were implemented, we could have avoided these issues. This highlights the importance of designing for failure and how it ensures system resilience in the face of unexpected challenges.With resilience in mind, the next step is ensuring we have full visibility into the health of our systems.

Observability is all you need

Having comprehensive visibility into your system’s health is critical for early issue detection and prevention. Without proper monitoring, it’s easy to miss performance problems that can lead to downtime, and lost revenue. The sooner you can identify issues, the faster you can handle them before they escalate into bigger failures that affect the business.

In my experience, focusing on a few core metrics like response times, error rates, and uptime provides a clear, actionable view of system performance. By measuring these metrics, you get the visibility needed to understand how your system is performing and where to focus your attention.

Tools for Observability:

Log Management and Analysis OpenSearch and ELK Stack (Elasticsearch, Logstash, Kibana) help track and analyze system events, enabling deep insights into system behavior.

Performance Monitoring: Datadog, New Relic, and Prometheus provide comprehensive performance monitoring, tracking infrastructure health, application performance, and user interactions.

Visualization and Dashboards: Grafana offers real-time dashboards for visualizing system health, often used with Prometheus.

Edge and Deployment Monitoring:Cloudflare ensures optimal performance during high traffic, and Argo offers real-time visibility into deployment pipelines.

Incident Management and Alerting: PagerDuty provides real-time alerts and escalations, helping teams act swiftly during incidents.

These tools offers you the end-to-end visibility needed to have a faster issue resolution and a more reliable system. But we can’t prevent incidents, eventually one will catch us off guard.

Prepare to crash

Incidents will happen, it is just a matter of when, therefore incident management is important for maintaining system reliability.

One way we can prepare is by setting up a runbook in advance. A runbook is a guide that includes common issues, resolution steps, escalation procedures, and how to go back to normal operations.It helps ensure consistency, decreases mean time to recovery, and enables teams to handle incidents effectively and minimize downtime.

One other we can use to prepare is conducting regular “fire drills,” inspired by Netflix’s Chaos Engineering, where issues are introduced as a test to identify gaps and improve response capabilities.

Scaling Early and Often

Scaling should be considered from the start. Expecting growth, and peak traffic helps you build systems that scale as demands increase.

Stress-test your systems to uncover performance bottlenecks before real traffic hits, ensuring you optimize ahead of time. Design for resilience by focusing on core features and providing fallback options to minimize user impact during failures.

Lastly, be effective by avoiding overscaling and make sure to match resources to actual demand.

Building Resilience One Engineer at a Time

Every engineer has a role in making the system resilient. By preparing for failure, monitoring the system, handling incidents effectively, and learning from mistakes, we can ensure long-term growth and reliability.

👉 Checkout my blog
🐦 Follow me on X

In the early 2010s, Twitter became viral for real time news, and they acquired a lot more customers. The company was succeeding in the social media scene and became the talk in the tech scene. But Twitter was battling a silent threat: technical debt.

In this article we will explore Twitter’s “Fail Whale” and how technical debt can cripple even the most promising companies. We will discuss how to identify, prioritize, and tackle technical debt before it spirals out of control.

Origins of Technical Debt

We often take shortcuts to meet the demanding timelines, creating technical debt. Like financial debt, it accumulates interest over time. Growing from what started as a quick fix into a bigger issue if not addressed.

“Shipping first time code is like going into debt. A little debt speeds development so long as it is paid back promptly with a rewrite or refactor. The danger comes when debt is allowed to accumulate and is not paid back.”
- Ward Cunningham, The person who coined the term

In Twitter’s case, this debt was the result of rapid feature development, shortcuts taken to meet user demands, and an architecture that couldn’t keep up with the platform’s growth.

The Rise of the Fail Whale

In its early days, Twitter’s system couldn’t handle the unexpected, rapid growth. This led to frequent outages and made feature additions and bug fixes slow and risky, while engineers were stuck in a firefighting mode, focused on maintaining stability rather than improving the platform. Twitter accumulated a lot of interest which created a culture dominated by technical debt, and damaged morale.

The Cost of Ignoring Technical Debt

Technical debt is often looked at as a technical issue and dealing with it can be doomed as an unaffordable luxury but it’s a risk that could break the business. For Twitter, the Fail Whale wasn’t just an inconvenience; it was a brand problem.

1. User Frustration: users began to lose trust in the platform. Frustrated by the unreliable service, some stopped using Twitter altogether.

2. Reputational Damage: The Fail Whale started as a fun mascot, but it soon became a public reminder of the platform’s technical struggles.

3. Slower Innovation: With engineers tied up in maintaining the system, features took longer to ship

As the Fail Whale became a clear threat to Twitter’s future, leadership realized the importance of addressing technical debt.

How to Deal with Technical Debt: Lessons Learned

Twitter’s experience offers key lessons for managing technical debt. Below are practical steps your team can adopt:

1. Identifying Technical Debt

• Codebase Reviews: Regularly audit your codebase to identify areas of complexity or fragile components.

• Tracking Debt: Use static analysis tools to track cyclomatic complexity and duplication.

• Continuous Monitoring: Use monitoring tools like Datadog or New Relic to track Mean Time to Recovery.

2. Prioritizing Debt Payoff

• Risk Assessment: Prioritize debt based on its potential impact on system performance and team productivity.

• Debt Register: Maintain a backlog of debt items and prioritize by severity and business needs. I have a monthly MOB session with the team to pair on these.

• Low-Hanging Fruit: Tackle small, high-impact issues that can be quickly resolved to build momentum.

3. Incorporating Debt Management into Workflow

• Debt Allocation in Sprints: Dedicate a percentage (e.g., 10%) of each sprint to refactoring or resolving debt.

• Continuous Refactoring Policy: Clean up code whenever modifying functionality to prevent future debt.

4. Long-Term Prevention Strategies

• Code Reviews: Implement thorough reviews to catch shortcuts and promote the refactoring policy.

• Architectural Planning: Regularly revisit architectural decisions to ensure it aligns with evolving business needs.

5. Communication and Stakeholder Alignment

• Cost-Benefit Analysis: Quantify the trade-offs between addressing debt and delivering features to align with business priorities.

• Narrative Framing: Use stories like the Fail Whale to convey the impact of unchecked debt to non-technical stakeholders.

• Advocate for Budget: Build a business case for dedicated resources to manage and reduce technical debt.

The Outcome: From Fail Whale to Resilience

technical debt can’t be prevented. But with the right strategies, it can be paid off. I have always considered twitter journey as a reminder of the impact technical debt has on a business. Make sure to consistently pay off technical debt to streamline shipping and avoid fixing.

Support me by subscribing here and following me on X

👉 Checkout my blog
🐦 Follow me on X

The reality of a developer’s day-to-day work doesn’t leave room for perfectionism. Refactoring is essential for maintaining healthy codebases as It ensures that software remains maintainable, scalable, and resilient to future changes. But in the real world, developers often deal with tight deadlines, business goals, and legacy systems.

Martin Fowler defines refactoring as :

The process of changing a software system in such a way that it does not alter the external behavior of the code yet improves its internal structure.

When done correctly, refactoring:

• Improves readability: Makes the code easier to understand.

• Enhances maintainability: Simplifies future changes and debugging.

• Reduces technical debt: Prevents long-term costs by addressing issues early.

In this article we will explore how to approach refactoring effectively and realistically, balancing principles like DRY (Don’t Repeat Yourself) and SOLID with the realities of our day to day, but let’s first explore how to identify the code that needs us to invest time in.

How to Identify Code That Needs Refactoring

I once inherited an e-commerce system from an outsourcing company that was terminated due to system quality issues. The main issues were that items frequently went vanished from the inventory, quantities were updating randomly and whenever a patch was made, some thing else broke.

I have dealt with a lot of similar cases to learn that this is a sign to refactor. The signals that I use to determine that are:

1. Frequent Bugs in same module: If the same module repeatedly causes issues, it’s a candidate for refactoring.

2. Hard-to-Read Code: If understanding a function feels like deciphering a riddle, it needs simplification.

3. Slow Development: Fixing bugs took forever due to high coupling.

4. Duplication: Functions were cloned everywhere.

5. Code Rot: Functions or modules with too many responsibilities.

It doesn’t make sense to strictly follow principles on a huge codebase when things are this bad. We need a balance that will maintaining a rational timeline while following best practices like avoiding duplication.

Balancing DRY and Simplicity

The DRY principle advocates eliminating duplicate code, but it can lead to over-abstraction. For example, pulling out shared logic into a single function can inadvertently couple unrelated modules. While DRY promotes efficiency, sometimes copy-paste is the better choice if it preserves clarity and independence.

For example imagine you have methods to send notifications The first example is focused a lot on the DRY principle, that it breaks single-responsibility.

function sendNotification(recipient, message, type) {
  const formattedMessage = formatMessage(type, message);
  const validatedRecipient = validateRecipient(type, recipient);
  send(type, validatedRecipient, formattedMessage);
}

function formatMessage(type, message) {
  if (type === 'email') return formatEmailMessage(message);
  if (type === 'sms') return formatSMSMessage(message);
  // other types...
}

function validateRecipient(type, recipient) {
  if (type === 'email' && !isValidEmail(recipient)) {
    throw new Error('Invalid email');
  }
  if (type === 'sms' && !isValidPhoneNumber(recipient)) {
    throw new Error('Invalid phone number');
  }
  // other types...
}

The second example strikes the balance between both only if you have to send two or more types of notifications. And we can argue that it would have broke the You Aint Gonna Need It (YAGNI) principle if done when having one type of notification to send.

class Notification {
  constructor(recipient, message) {
    this.recipient = recipient;
    this.message = message;
  }

  validate() {
    throw new Error('Validate method must be implemented.');
  }

  format() {
    throw new Error('Format method must be implemented.');
  }

  send() {
    throw new Error('Send method must be implemented.');
  }

  process() {
    this.validate();
    const formattedMessage = this.format();
    this.send(formattedMessage);
  }
}

class EmailNotification extends Notification {
  validate() {
    if (!isValidEmail(this.recipient)) {
      throw new Error('Invalid email address');
    }
  }

  format() {
    return formatEmailMessage(this.message);
  }

  send(formattedMessage) {
    sendEmail(this.recipient, formattedMessage);
  }
}

class SMSNotification extends Notification {
  validate() {
    if (!isValidPhoneNumber(this.recipient)) {
      throw new Error('Invalid phone number');
    }
  }

  format() {
    return formatSMSMessage(this.message);
  }

  send(formattedMessage) {
    sendSMS(this.recipient, formattedMessage);
  }
}

This brings us to the other challenge we need to stay aware of, over engineering.

The Cost of Over engineering

SOLID principles aim to make software more robust and flexible, but rigid adoption can result in needless complexity. In the example above, implementing an elaborate inheritance hierarchy for a single-use case might violate YAGNI (You Aren’t Gonna Need It).

Creating a balance between extensibility and simplicity is crucial, especially when refactoring. The focus should alway be on what we have now, as it is what will resolve business impacting side effects. Immediate business impact should be prioritized, and the technical goals should be aligned with adding business value. This will make it easier to get a buy in from stakeholders with all the competing priorites.

Competing Priorities

Deadlines often trump code cleanliness. Developers must weigh the costs of refactoring against delivering features on time. In some cases, the immediate business impact of shipping outweighs the long-term benefits of a cleaner codebase.

Strategies for Real-World Refactoring

1. Focus on Business-Critical Code Prioritize refactoring areas that directly impact business outcomes. For example, improving the performance of a payment processing module is more valuable than cleaning up an infrequently used admin tool.

2. Refactor Incrementally Big-bang refactors are risky and time- consuming. Instead, adopt the Boy Scout Rule: leave the code cleaner than you found it. Small, incremental changes accumulate over time, making the codebase more maintainable without disrupting ongoing development.

3. When to break DRY: If two pieces of code are similar but exist in different contexts, duplicating them might be better than introducing a shared dependency.

4. When to break SOLID: Violating the Single Responsibility Principle (SRP) might be acceptable in a stable, low-risk module where the cost of abstraction outweighs the benefits.

5. Test-Driven Refactoring: Before refactoring, write tests to capture the current behavior of the code. These tests act as a safety net, ensuring that changes don’t introduce new bugs. Refactoring is much safer when you can verify functionality at every step.

Practical Examples of Real-World Refactoring

1. Simplifying a Monolithic Function

Before:

function calculateOrder(customer, items) {
  let discount = 0;
  if (customer.type === 'premium') {
    discount = items.length > 5 ? 0.2 : 0.1;
  }
  let total = items.reduce((sum, item) => sum + item.price, 0);
  total -= total * discount;
  if (customer.hasLoyaltyCard) {
    total *= 0.95;
  }
  return total;
}

After:

function calculateOrder(customer, items) {
  const discount = getDiscount(customer, items);
  let total = calculateTotal(items, discount);
  return applyLoyaltyDiscount(customer, total);
}

function getDiscount(customer, items) {
  if (customer.type !== 'premium') return 0;
  return items.length > 5 ? 0.2 : 0.1;
}

function calculateTotal(items, discount) {
  return items.reduce((sum, item) => sum + item.price, 0) * (1 - discount);
}

function applyLoyaltyDiscount(customer, total) {
  return customer.hasLoyaltyCard ? total * 0.95 : total;
}

Breaking the function into smaller methods makes it easier to understand and test.

2. Avoiding Over-Abstraction

Suppose you have two similar but not identical processes:

function renderPDF(document) {
  // Render PDF logic
}

function renderImage(document) {
  // Render Image logic
}

Abstracting this might create unnecessary complexity if their shared logic is minimal. Instead, leaving them separate maintains clarity and independence.

When Not to Refactor

Refactoring isn’t always the right choice. Avoid it when:

1. Deadlines are tight: Focus on delivering functionality unless refactoring is necessary for the feature.

2. The code is stable: Refactoring low-risk, rarely updated code offers little value.

3. It adds complexity: Don’t refactor for refactoring’s sake; changes should simplify the code.

Balancing Effectiveness and Principles

Software engineering is as much about making trade-offs as it is about following principles. DRY and SOLID are excellent guidelines but shouldn’t be dogmatically applied. Effective refactoring is about balancing perfection with the real world challenges of time, resources, and business priorities. Remember, Better is better than perfect.

🐦 Follow me on X

👉 Checkout my blog

Support me in creating more content by subscribing!

This guide focuses on actionable steps to handle production bugs and implement hot fixes effectively, along with real-world use cases to illustrate best practices.

How to Decide If a Hot fix Is Needed

This is where fear usually takes over without a proper framework. I have seen cases where a hot fix was requested for a broken loader icon that had no impact on flow, Or for an issue that was affecting 2 users from our 500k monthly active users.

Bugs exist in every system and fixing them is essential for the user experience. But having hot fixes and late nights without the need to do so destroys team morale, and creates an unhealthy work environment.

To determine if a hot fix is necessary, I like to ask the following:

1. Is it costing us money?

2. Is it disrupting key user flows?

3. Is it harming trust or reputation?

4. Is it increasing operations effort or risking compliance?

If the impact is significant and the answer to any of the above is yes, I will prioritize the hot fix.

Be prepared before incidents happen

A framework to handle incidents does not look like something that would be prioritized until an issue actually happens. It is crucial to define a framework that guides the team on how to deal with a production incident. An effective framework ensures clarity and minimizes chaos when handling production bugs.

This is how to create an incident handling process

• Define Severity Levels: Create criteria to classify incidents as Critical, High, or Low based on user impact. For example, a payment gateway outage is Critical, while a minor UI glitch may be Low. Questions mentioned above can help.

• Escalation Workflows: Set clear paths for escalating issues, from on-call engineers to team leads or SRE teams.

• Prepare Run books: Document step-by-step responses for common issues to guide engineers during incidents.

Monitoring and Detection for Engineers

Early detection of production issues minimizes its impact and speeds up resolution. Monitoring is a core part of engineering, relying on real-time dashboards and smart alerts to catch issues before users notice is crucial for a brand’s image, user experience.

It also prevents revenue loss which can make or break a company in its early days.Be proactive and set up tools that will help in early detection and debugging. This can be done by setting up the following:

• Monitor Critical Metrics:
  Track latency, error rates, and resource usage with tools like Grafana, New Relic, or Datadog.

• Set Smart Alerts:
  Avoid alert fatigue by using actionable thresholds (e.g., “API error rate > 5% for 10 minutes”).

• Enhance Observability:
  Use structured logs, traces, and metrics that are easily searchable for faster debugging.

• Automate Anomaly Detection:
  Implement tools like Prometheus alert manager or ML-based systems to catch unusual patterns early.

  Debugging in Live Environments

  Begin by examining logs and metrics to identify anomalies and narrow down potential root causes.I usually need to look at logs from different parts of the system to be able to create a pattern and understand the issue. The key goal here is to create a sequence of steps or pattern of actions that once it occurs the bug happens.

  To do this we can use targeted debugging tools, such as trace analyzers or runtime loggers, to gather more insights directly from the production system.

  Once we have this understanding we should aim to replicate the issue in a staging environment If possible to validate the findings and avoid risky live experimentation.

  The following action items helps when debugging live:

  • Start with Logs and Metrics: Analyze structured logs and metrics to identify anomalies before making live changes.

  • Replicate Safely: Attempt to replicate the issue in a staging environment to confirm root causes without affecting users.

  • Use Feature Toggles: Temporarily disable problematic features or isolate the impact without rolling back the entire system.

  • Document Every Step: Record your debugging actions to create a clear trail for post-incident analysis.

  Communication During Incidents

  Keep updates clear and short. Share the issue, its impact, and when it will be fixed for example, “Payment processing is delayed due to a gateway issue; expected resolution in 30 minutes”. Use tools like Slack, PagerDuty, or StatusPage to communicate. Work closely with support teams to give users accurate updates. Make sure to only share confirmed details to avoid confusion.

  Post-Incident Reviews for Engineers

  A strong post-incident review is crucial for learning and preventing future issues. Following an approach of blameless postmortems, focus on system and process failures, not individual mistakes (e.g., “The alert threshold was too high to detect the issue sooner”).

  What makes a good postmortem

  A good postmortem should include a detailed timeline of events, root causes (technical, procedural, and human), and the incident’s impact. Ensure all findings are based on facts to avoid blame and to ensure a safe discussion environment.

  To make postmortems actionable, define clear tasks such as refining alert thresholds, improving test coverage, or updating runbooks, this will foster a culture of continuous learning and resilience.

  Define clear tasks: Refine alert thresholds, improve test coverage, update run books. Here is a guideline that I post about a production bug.

  • Standardize the process: define and use a common RCA templates that answers what happened, action taken, and how can we prevent it and lessons learned.

  • Prioritize tasks: Focus on high-impact action items first.

  • Track progress: Ensure all action items are completed.

  • Share insights: Distribute findings across teams to prevent similar issues.

  • Measure success: Use metrics like MTTR or incident recurrence rates.

  Conclusion

  Dealing with production bugs and hot fixes is as much about preparation and process as it is about technical expertise. By setting up robust incident response frameworks, leveraging monitoring tools, communicating effectively, and learning from incidents, software engineers can handle live issues confidently and minimize user impact. Embrace these practices to not only resolve issues faster but also build systems that are more resilient and reliable in the long run.

Support me in creating more content by subscribing !

The Backbone of a Smooth Release Process

The importance of a structured release process is unmatched. A structured process minimizes risk, enhances collaboration across teams, and allows for quick recovery when things go wrong. It also can make or break the work-life balance of your team.
I’ve seen firsthand how a lack of preparation can lead to disastrous results. In one instance, we had a major release planned, but we overlooked a critical dependency between services. The operations team wasn’t informed about the need to update a shared configuration before deployment.The result? The primary service failed to start in production

Pre-Release: Laying the Foundation

Code Freeze and Final Testing

The pre-release phase is critical. This is when your code is finally ready for deployment, and it’s time to ensure everything works as intended. For me, the first step in this phase was always the “code freeze.” I learned that the real power of a code freeze is in reducing risk.

Code freeze does not mean engineers stop writing code, But it simply means that for the tag being released, there will be no additions, just fixes. By halting all new feature development and put a hard limit on the scope of release which allows focus on testing. This is how we could ensure stability.

Final testing happens during this phase, where final integration and user acceptance testing happens.

Cross-Team Coordination

Releases require alignment across multiple teams, including developers, QA, product managers, operations, and other cross-functional teams. Poor coordination can lead to misalignment, rushed processes, and frustration.

To ensure seamless cross-team coordination:

1. Establish a shared timeline: Create a clear release schedule that all teams agree on and understand.

2. Host regular syncs: Schedule check-ins to track progress, surface blockers, and ensure alignment. This can be a slack channel, or an email thread.

3. Document everything: Maintain shared documentation with roles, responsibilities, and key milestones for full transparency.

4. Assign points of contact: Designate a representative for each team to streamline communication and resolve issues quickly.

By prioritizing cross-team alignment, you reduce the risk of last-minute surprises and create a foundation for a smooth and successful release process.

User documentation

In B2B software, comprehensive documentation is critical for ensuring smooth releases and minimizing confusion. It’s easy to assume that everyone, from internal teams to clients, knows what to expect from a release, but gaps in understanding can lead to disruptions.

To ensure effective documentation:

1. Internal Documentation: Share release notes, deployment steps, and rollback strategies with all relevant teams to align everyone on the process.

2. Client-Facing Documentation: Provide detailed guides, FAQs, and implementation resources to help clients quickly adopt and integrate new features.

3. Client Education: In B2B, user education can play a significant role in reducing support tickets, increasing feature adoption, and ensuring clients are fully equipped to leverage new functionality.

By focusing on thorough internal and client-facing documentation, you build trust and ensure a smoother, more successful release in B2B environments.

Post-Release: Monitoring and Response

1. Monitoring the System After Deployment

Once your release is live, the real work begins. I learned this lesson the hard way during a release where everything seemed fine during testing, but performance metrics after launch were disastrous. The system started to lag, and we realized that we hadn’t anticipated the volume of traffic the new feature would attract. It was an intense learning moment. Ever since, I’ve been a strong advocate for post-release monitoring.

Tools like New Relic, Datadog, and Prometheus have become a critical part of my workflow. They allow me to track key performance indicators (KPIs) in real-time. By monitoring things like uptime, load times, and error rates immediately after a release, I can quickly spot and address potential issues. Early detection is key to maintaining a positive user experience and preventing long-term problems.

2. Stakeholder Communication

In the rush of deployment, it’s easy to forget to keep stakeholders informed. However, I’ve found that timely communication is vital. Forgetting to keep the stakeholders updated on the status will get them caught off guard when users report bugs, and it will delay their ability to address issues.

I always ensure that communication channels are open, and all relevant stakeholders receive timely updates. Whether it’s a quick email or a formal meeting, keeping everyone in the loop ensures transparency, trust, and the ability to react quickly if things go wrong.

3. Success Metrics for Releases

Measuring the success of a release goes beyond tracking uptime or bug reports. We should evaluate whether the release met its objectives and delivered value to users.

Clear success metrics before every release could include:

• User Engagement: Metrics such as daily active users (DAU), feature usage rates, or time spent on key features.

• Customer Satisfaction: Net Promoter Score (NPS), customer feedback surveys, or support ticket volume post-release.

• Performance Metrics: Load times, error rates, or system performance improvements.

• Business Outcomes: Conversion rates, customer retention rates, or even revenue growth linked to the release.

By tracking these success metrics, you ensure that we’re delivering real value and can make informed decisions about future releases. It will improve your knowledge of the business and help you contribute more value when discussing future work.

Elevating Your Release Process

1. Feature Toggles and A/B Testing

This approach allows you to push code live without exposing it to users immediately. it also enables you to toggle features on or off without redeploying code, providing flexibility and a solid backup plan.

When Facebook launched the News Feed redesign, they relied heavily on feature toggles to control access to the update. This allowed the engineering team to roll out the feature gradually, monitor performance, and gather user feedback.

Coupled with A/B testing, they compared user engagement metrics between the new and old designs, using the insights to iterate quickly. By refining the design based on real-world data, Facebook ensured the final release met user expectations while minimizing risk.

Feature toggles and A/B testing together empower teams to make safe, data-driven decisions, enabling gradual rollouts, rapid experimentation, and continuous improvement.

2. Continuous Delivery and Deployment

Continuous delivery (CD) and continuous deployment practices emphasize automating the build, testing, and deployment pipelines to ensure smooth and consistent delivery of updates.

Google’s engineering teams are well-known for their robust releasing system. For instance, Google Search’s continuous delivery pipeline processes thousands of daily code changes all done on a huge mono repo.

Engineers push updates to production multiple times a day, relying on automated testing to catch issues early. The process ensures that every code change is thoroughly vetted before deployment, maintaining the quality and reliability users expect. Google’s strategy also includes extensive monitoring and rollback mechanisms, allowing them to address any issues.

By adopting continuous delivery, we can deliver features and fixes faster while maintaining high quality. The key lies in rigorous testing, seamless automation, and proactive monitoring.

3. Managing Large-Scale Releases

As projects scale, managing releases becomes increasingly complex, involving coordination across multiple teams and systems. Large-scale releases require careful planning, communication, and risk mitigation strategies.

A classic case study is Google Chrome’s rollout strategy. Given Chrome’s massive user base, updates must be flawless. Google employs a staged rollout approach, initially releasing updates to a small percentage of users.

They monitor feedback and performance metrics closely, scaling up the release incrementally. This method helps identify and address issues early, ensuring the broader user base isn’t impacted. For complex updates, Google coordinates across engineering, product, and customer support teams to ensure alignment and preparedness.

Key strategies for large-scale releases include breaking down releases into manageable chunks, staged rollouts, and having a clear rollback plan. Effective communication and dependency management are also critical to minimizing risks.

The Continuous Journey of Release Management

Release management is a dynamic and ongoing learning process. Each release presents new challenges and lessons, helping refine the approach for future launches. With a solid process, effective communication across teams, and a focus on monitoring and measuring success, every release can bring value to users and the team.

As seen in the examples of Facebook and Google, mastering release management goes beyond technical skills. It requires understanding the broader impact of each release on the product, team, and end-users. Whether you’re starting out or leading releases at scale, remember that each release is an opportunity to improve, learn, and grow as an engineer.

Start small perhaps by formalizing your code freeze procedures, improving your monitoring tools, or conducting regular post-release retrospectives with your team, with time your process will mature to fit product needs.

👉 Follow me on Medium
🐦 Follow me on X

Shipping High quality software that stays that way is a hard task. It’s easy to fall into the trap of writing code that works now but becomes a burden as your application grows.

To maintain consistent, high-quality code, you need to build the foundation that prioritizes testing, and code quality.

This guide offers practical steps to write high-quality tests by focusing on testing strategies, design principles, techniques to make your software scalable and maintainable, and tips for working with legacy code.

The Testing Pyramid: A Balanced Approach

Before diving into specific testing practices, let me start by introducing the Testing Pyramid.

This model helps us understand the importance of different types of tests at different levels:

1. Unit Tests: These test individual functions or components in isolation. They should be precise, small and cover the smallest units of code.

2. Integration Tests: These test how different modules or components interact with each other.

3. End-to-End (E2E) Tests: These simulate real user workflows to test the full system from start to finish. While they are comprehensive, they should be limited to critical paths.

The goal is to have a strong base of unit tests, a solid middle layer of integration tests, and a minimal set of E2E tests to cover critical features. Each level of the pyramid handles prevent a different set of issues that could happen. It helps in ensuring that your application is covered without being over-tested.The next step is to ensure your code is designed to be testable

Writing Testable Code: Principles and Examples

Good testing start with writing testable code. The easier it is to isolate and test your code, the more confident you’ll be in its correctness.

Here are some principles to follow:

1. Separation of Concerns: Each module should have a single responsibility.

2. Dependency Injection: Pass dependencies into functions rather than creating them inside.

3. Avoid Side Effects: Write pure functions wherever possible.

4. Modular Design: Break large functions into smaller, reusable ones.

Designing our code for tests

Let’s take a look at a real-world example of how refactoring code for testability can lead to more maintainable and testable components.

Before Refactoring:
In this example, the code directly handles business logic, sends emails, and calculates totals in one function.

function processOrder(order) {
  const discount = order.amount > 100 ? 0.1 : 0;
  const total = order.amount - order.amount * discount;
  sendEmail(order.email, `Total: $${total}`);
}

This function is difficult to test because it directly calls sendEmail. Also, the logic for calculating the discount and total is mixed into one function.

After Refactoring:
We can separate the concerns, making each function independently testable.

function calculateDiscount(amount) {
  return amount > 100 ? 0.1 : 0;
}

function calculateTotal(order) {
  const discount = calculateDiscount(order.amount);
  return order.amount - order.amount * discount;
}

function processOrder(order, emailSender) {
  const total = calculateTotal(order);
  emailSender(order.email, `Total: $${total}`);
}

Now, calculateDiscount, calculateTotal, and processOrder are all independent and can be tested individually. This makes the code easier to maintain and scale.

Now let’s explore tools to implement your tests effectively.

Jest : A Quick intro

Now that we have the testing pyramid in mind, and are able to write testable code, that is easy to refactor. let’s look at Jest, one of the most popular testing libraries.

Jest makes it easy to start testing your JavaScript code with powerful features such as mocking, snapshot testing, and more.

Core Concepts in Jest

Test Suites and Test Cases:

• A test suite groups related test cases in a single file.

• A test case verifies a specific piece of functionality.

Matchers: Methods used to validate the results of your functions.

• toBe(): Strict equality check.

• toEqual(): Deep equality check.

• toHaveBeenCalled(): Ensures a mock function was called.

Mocking with Jest

Mocks allow us to simulate external dependencies and isolate the functionality we want to test. This is especially useful when testing code that interacts with APIs, databases, or external services.

const mockApiClient = jest.fn().mockResolvedValue({ data: { temp: 25 } });

async function fetchWeatherData(apiClient) {
  return apiClient();
}

// Test
test('fetchWeatherData calls API and returns temperature', async () => {
  const data = await fetchWeatherData(mockApiClient);
  expect(mockApiClient).toHaveBeenCalled();
  expect(data.temp).toBe(25);
});

Handling legacy code

Testing legacy code can be intimidating, but it’s a critical step in maintaining and improving it. Here’s how to approach it effectively:

1. Identify Risky Areas

Start by identifying parts of the codebase that are most likely to fail or have the greatest business impact. Focus your testing efforts there first.

2. Characterization Tests

Characterization tests capture the current behavior of the code. They serve as a baseline to ensure that changes don’t introduce regressions.

// Legacy function
function calculateTotalLegacy(amount) {
  return amount * 1.2; // Includes tax
}

// Characterization test
test('calculateTotalLegacy returns correct total with tax', () => {
  expect(calculateTotalLegacy(100)).toBe(120);
});

3. Refactor for Testability

Refactor small, isolated pieces of the code to make them testable. For example, extract complex logic into separate functions.

4. Handling Legacy Code Isn’t always Possible
When direct testing is not feasible (for example, if the legacy code is too tightly coupled or involves external dependencies that are hard to mock), here are a few approaches:

• Integration Tests: Start by writing integration tests that cover critical paths. These tests can help capture the behavior of interconnected systems, even when individual units are hard to isolate.

• Refactoring in Stages: If direct testing isn’t possible due to complex legacy code, consider refactoring the code in stages. Break down large functions or components into smaller, testable parts. Test each small part incrementally as you refactor, ensuring that each change doesn’t introduce new issues. The proxy and strangler pattern can be great here.

• Don’t Aim for high testing coverage, rather focus on critical areas

5. Use Tools for Safety

Tools like code coverage analysis and static analysis tools can help identify gaps in your tests and risky dependencies.

6. Balance Tests and Development

While testing is crucial, balance it with your project deadlines. Focus on high-risk areas when time is limited

7. Utilize The Proxy Pattern

The Proxy Pattern can be useful in testing legacy code by isolating external dependencies and making components more testable.

Here’s how it helps:

1. Isolate Dependencies for Testing Legacy systems often rely on tightly coupled external services (e.g., databases, APIs). Using a proxy, you can simulate these dependencies, making it easier to test the logic in isolation.

Example:

class PaymentGatewayProxy {
  process(order) {
    return order.amount > 1000 ? { success: true } : { success: false };
  }
}

In tests, you can replace the real payment gateway with this proxy, avoiding external calls while testing.

2. Mock Behavior for Complex Operations: Proxies allow you to mock complex, slow, or resource-intensive operations (e.g., network requests, file I/O), speeding up tests.

Example:

class FileSystemProxy {
  constructor(realFileSystem) {
    this.realFileSystem = realFileSystem;
    this.cache = {};  // Cache results
  }

readFile(filePath) {
    if (this.cache[filePath]) return this.cache[filePath];
    const content = this.realFileSystem.readFile(filePath);
    this.cache[filePath] = content;
    return content;
  }
}

This proxy helps avoid hitting the actual file system during tests.

3. Incremental Refactoring: The Proxy Pattern allows you to refactor legacy code incrementally. You can introduce proxies to abstract complex or tightly coupled components, making them easier to test while refactoring in stages.

Example:

class LegacyServiceProxy {
  method() {
    // Proxy delegates to refactored, testable components
    return new RefactoredService().method();
  }
}

This makes testing easier and reduces the risk of breaking functionality during refactoring.

Recap:

• Isolate Dependencies: Simulate external services for isolated testing.

• Mock Expensive Operations: Avoid costly operations (e.g., file I/O) during tests.

• Incremental Refactoring: Introduce proxies to refactor legacy code without disrupting tests.

By using the Proxy Pattern, you make legacy systems more testable, ensuring that tests are focused, efficient, and easier to maintain.

Testing for Scalability

High-quality code isn’t just about correctness — it’s also about ensuring your code can handle increased complexity and growth over time, without introducing regressions or performance issues. Here’s how to integrate scalability with testing practices:

1. Test for Growth
   As your codebase grows, so do the number of edge cases and interactions between components. Write tests that anticipate how your system will handle increased load and complexity.
   Example: Write tests that simulate large datasets or increased user activity. This helps ensure that performance remains optimal under growing demand, especially when integrating new features.

2. Optimize and Test for Performance
   Scalability also involves ensuring your code performs well as it expands. Performance testing helps identify bottlenecks before they become issues in production.
   Example: Use load testing tools like Jest or other performance profiling tools to test how your application handles large volumes of data, such as stress-testing database queries or large API responses.

3. Test Caching and Data Access Patterns
   Caching is essential for scaling, but you need to ensure that your caching strategy doesn’t introduce bugs or inconsistencies. Write tests to validate that your caching mechanism works as expected.
   Example: Write unit and integration tests that check if cached data is updated correctly, ensuring no stale data is returned, and validate that caching doesn’t cause conflicts in concurrent requests.

4. Database Queries and Test Coverage
   With the increase in data, the performance of your database queries becomes critical. Ensure you’re writing tests that validate query optimization and indexing.
   Example: Write integration tests that simulate large query responses and measure their performance, ensuring that the indexes and database optimizations handle large-scale operations efficiently.

5. Modular Testing with Scalable Architectures
   In a microservices or serverless architecture, each service must be independently tested to ensure they can scale individually. Create modular test suites that can scale with your application’s growth.
   Example: Develop end-to-end tests that cover each microservice and ensure they function in isolation, as well as in combination with other services, without creating performance bottlenecks.

By incorporating these scalability-focused testing practices, you ensure that your codebase remains maintainable, high-performing, and robust as it grows. Always test for scalability, not just functionality, to deliver quality code that stands the test of time.

Final Thoughts

Testing is a critical practice for building high-quality software that lasts. writing tests improves your development process by:

Building Confidence in Code:
Tests act as a safety net, enabling you to make changes without fear of introducing bugs. For example, when adding a feature to apply discounts based on order amounts, writing tests for edge cases ensures the code behaves as expected under various conditions.

Encouraging Better Design:
Writing tests forces you to simplify and modularize your code, leading to better overall architecture and maintainability.

Accelerating Debugging:
Tests help identify and fix bugs early. For instance, if a negative amount is accidentally passed into the applyDiscount function, a test will catch it immediately, saving you hours of debugging later.

Supporting Refactoring:
Comprehensive tests give you the confidence to refactor. With tests in place, you can safely change or restructure parts of your code without worrying about breaking existing functionality.

This 4-step guide will show you how to plan smarter, build better, and deliver value. If you master the skills in this guide, you will become a multiplier builder, whether you're creating for yourself or on the job.

Step 1: Understand the Problem (Start With 'Why')

Before diving into writing code, we need to understand why we are doing this, what problem we are trying to solve. Getting these insights will allow you to evaluate the solution, add your input, or maybe argue that the proposed solution won't solve the problem and suggest a different solution.

Start with asking questions like:

• What problem are we solving?

• Who benefits from the solution?

• What is the impact of not solving this problem?

This clear understanding sets the foundation for you to understand what it is that we are trying to achieve and evaluate the effectiveness of the solution proposed, whether it will solve the problem at hand. Understanding the impact that will allow you to have a strong argument working on valuable items instead if it has more impact.

Step 2: Collaborate and Align

One of the important steps that gets missed all the time. The consequences of missing this can be severe: wasted time, unnecessary rework, and a final product that fails to meet its intended purpose.

To avoid this you should discuss with stakeholders to gather requirements, and ask about details. Make sure to think about constraints and edge cases.

At the end of this step, you should have a clear understanding of the following

• What happens if the input is unexpected?

  • Examples: Empty, invalid, or extremely large values.

• How does the system behave under high load or failure conditions?

  • Scenarios: Simulate heavy user traffic or resource limitations.

• What external factors could introduce variability?

  • Examples: Third-party APIs, fluctuating network conditions, or unexpected dependencies.

• What analytics events should be tracked?

  • Ensure key metrics are identified (e.g., success rates, failure patterns).

  • Determine whether to include an A/B test to evaluate feature impact or user behavior.

There should be a consensus between you and the stakeholders on what is going to be built.

Step 3: Translate High-Level Plans into Actionable Steps

Once you have alignment on the high-level plan, it's time to break it into smaller, manageable tasks. Translating an abstract idea into a clear roadmap is crucial to avoid confusion and ensure consistent progress.

How to Break It Down

1. Divide and Conquer:
   Break down the feature or project into logical phases, components, or milestones. Each should represent a distinct piece of work that adds value or aligns with a specific objective.

2. Define SMART Tasks:
   Make each subtask Specific, Measurable, Achievable, Relevant, and Time-bound (SMART). For example, instead of "Add authentication," create smaller tasks like "Implement login API," "Create UI for login page," and "Integrate OAuth."

3. Identify Dependencies:
   Understand the sequence of tasks—what needs to happen first, and what can be done in parallel. This helps prioritize work effectively and prevents bottlenecks.

4. Plan for Edge Cases:
   Include tasks for testing unexpected inputs, performance under load, and integration with external systems.

At the end of this step, you should have:

• A detailed list of tasks or subtasks organized by priority and dependency.

• Clear milestones for tracking progress and keeping stakeholders updated on steps, dependencies, and timeline.

Step 4: Create the Design Document

To prevent unnecessary rework, delays, and frustration, create a thorough design document. have team members review it, and accept and discuss feedback in a kind-hearted manner.

To create a design document, I usually follow this thought process.

1. Define the Project Overview and Goals: Start by summarizing the project’s goals, objectives, and scope, including what's in and out of scope. Clearly articulate the problem the project solves and the specific outcomes you're aiming to achieve. This step ensures everyone understands both the what and why, aligning the team on the purpose and intended results.

2. Find Dependencies, and Outline the Technical Approach: Identify task dependencies, and highlight potential risks and challenges. Detail the system architecture, components, and data flow. Include how different components interact, how you will deal with dependencies and the tools you will use.

3. Security and Performance Considerations: Identify security measures, scalability, and performance strategies to ensure the system’s robustness and long-term viability.

4. Testing Strategy: Outline the types of testing (unit tests, integration tests, UAT) and tools or frameworks you will use to ensure quality.

5. Timeline and Milestones: Provide a clear project timeline with key milestones and deadlines, breaking the project into manageable phases or sprints.

Make sure your solutions is broken down to subtasks that follow the SMART method (Specific, Measurable, Achievable, Relevant, Time-bound)

Once the Document is ready, you can share it with stakeholders where they will review, provide feedback, and be aligned on the approach. Once the solution is approved, you can move to the execution part.

Conclusion: Plan Smarter, Engineer Better

Engineering isn’t just about solving problems—it’s about solving the right problems effectively and building systems that endure. By following this six-step framework, you can become an engineer who creates meaningful, lasting impact.

Recap:

1. Understand the Problem: Start with 'Why' to ensure alignment with real needs.

2. Collaborate and Align: Plan thoroughly and bring everyone on board.

3. Break It Down: Translate high-level plans into actionable steps.

4. Create the Design Document: Build systems that grow and adapt.

Shift your mindset from output-focused to outcome-focused engineering. Start implementing these steps in your daily workflows today, and take the first step toward becoming a smarter, more effective engineer.

Effective sprint ticket management is the backbone of successful agile teams. Whether you’re a developer, or a team lead, how you handle tickets can determine whether your sprint delivers meaningful results or is it doomed for failure.

This guide explores strategies that will ensure success in sprint, it serves as a guide how to handle receiving and discussing tickets.

Understanding the Role of Sprint Tickets

Sprint tickets represent the granular tasks that collectively drive a project forward. However, they’re more than just to-do items. Each ticket embodies a slice of business value, and managing them well ensures that your efforts translate into tangible outcomes.

Why Ticket Management Matters

• Maximizing Business Value: Ensuring the team focuses on tasks that align with organizational goals.

• Enhancing Team Productivity: Minimizing bottlenecks and confusion with clear, actionable tickets.

• Gaining Credibility: Meeting expectations by prioritizing tasks effectively and delivering consistently.

Effective Communication Around Tickets

When a new ticket is introduced, the discussion around it sets the stage for success. Use these strategies to make kickoff conversations productive:

1. Ask Clarifying Questions: Ensure all ambiguities are resolved before work begins. For example: “What is the desired outcome of this ticket?” , “Are there specific edge cases we need to account for?”

2. Align on Acceptance Criteria: Define what “done” means. This avoids unnecessary rework.

3. Identify Dependencies: Highlight upstream or downstream tasks that could impact completion.

Documenting for Clarity

A well-documented ticket is a map, not a maze. Ensure tickets includes:

• A clear title summarizing the task

• A concise description outlining the problem and context.

• Acceptance criteria that set expectations.

• Attachments or links to supporting documents.

How to Handle Edge Cases During Ticket Creation or Refinement

Addressing edge cases early ensures robust implementation and reduces unforeseen blockers. Consider these practices:

1. Brainstorm Scenarios: Think through potential edge cases for the feature or bug fix.

2. Collaborate with Stakeholders: Involve product managers, designers, and QA in identifying possible challenges.

3. Document Clearly: Add explicit notes about edge cases in the ticket to guide implementation.

How to Size Tickets

Proper ticket sizing is crucial for planning and execution. Here’s how to approach it:

1. Break Down Large Tasks: If a ticket seems too big, decompose it into smaller, manageable tasks.

2. Follow the INVEST Principle: Ensure tickets are Independent, Negotiable, Valuable, Estimable, Small, and Testable.

3. Use T-Shirt Sizes or Story Points: Categorize tasks as Small, Medium, or Large, or assign story points based on complexity and effort.

4. Analyze dependencies: Identify whose work would be affected by this, what do you need from other teams or stakeholders to be able to deliver. This can be an API, a design, or a documentation.

How to Identify Dependencies

Dependencies can make or break a sprint. Identifying them upfront prevents delays and bottlenecks.

1. Analyze Inputs and Outputs: Check if the ticket depends on the completion of another task or delivers something required by another.

2. Consult Stakeholders: Discuss with other teams or individuals to uncover hidden dependencies.

3. Use Visual Tools: Create dependency maps or annotate your board to highlight task relationships.

4. Document Dependencies: Clearly note dependencies within the ticket to ensure visibility during planning.

How to Estimate Tickets

Accurate estimation helps you set realistic goals and avoid overcommitment. Here are steps to improve estimation:

1. Understand the Scope: Ensure everyone involved understands the task’s requirements and acceptance criteria.

2. Use Historical Data: Refer to similar tickets completed in the past to guide your estimates.

3. Involve the Team: Engage the whole team in estimation discussions to benefit from everyone’s experience.

4. Account for Risks: Add buffers for tasks with high uncertainty or external dependencies, or if it is ambiguous.

5. Choose an Estimation Technique: Planning Poker: A collaborative approach to assigning story points. Bucket System: Group tickets into predefined buckets of complexity.

When estimating, calculate an optimistic and a pessimistic estimation, and take the average.

For example let’s say the ticket will take 3 to 5 days to complete. You can communicate (3+5) days divided by 2 to take the average which is 4 days.

Communicating risks and Uncertainties

Uncertain tasks pose risks that can derail sprints. Handle these effectively:

1. Flag High-Risk Tickets: Clearly identify tickets with unknowns or technical challenges.

2. Schedule Discovery Tickets: Use smaller exploratory tickets to research and reduce uncertainty.

3. Document Findings: Share insights from discovery work to guide implementation.

4. Add Buffers: Allocate extra time in your sprint for high-risk items.

Prioritization & Negotiation: The Key to Delivering Impact

Not all tickets are created equal. Effective prioritization ensures that the your efforts are directed where they matter most.

Short-Term vs. Long-Term Goals

Balancing urgent tasks with strategic objectives is an art. Here’s how to strike the right balance:

• For Short-Term Wins: Focus on high-impact tasks that unblock other work.

• For Long-Term Success: Allocate time for technical debt, refactoring, and innovation.

Prioritization Frameworks: What should I pick first ?

1. The Eisenhower Matrix: Urgent and Important: Address immediately. Important but Not Urgent: Schedule for later. Urgent but Not Important: Delegate if possible. Neither Urgent nor Important: Consider dropping.

2. Weighted Scoring: Assign scores based on factors like business value, effort, and risk.

3. WSJF (Weighted Shortest Job First): Calculate priority by dividing value by effort, ensuring the team tackles high-impact, low-effort tasks first.

Clear Ownership and Responsibility for Every Ticket

Ownership is critical to ensure accountability and progress. Here’s how to assign and manage it:

1. Define Roles: Clarify who needs to provide input, review, or approve the task.

2. Follow up: Continuously align with people you need to work with to deliver, Ask for updates, and progress.

3. Be transparent: Continuously update your stakeholders on progress, blockers, and issues that could impact your delivery. If a change is needed in estimation, communicate it as soon as possible.

Technical Feasibility Discussions

Technical feasibility is a cornerstone of ticket management. Ensure alignment with these steps:

1. Review with your team: Conduct feasibility discussions during refinement sessions.

2. Align with Architecture: Validate that the solution fits within the existing technical architecture.

3. Assess Tooling: Confirm that the necessary tools and libraries are available and adequate.

4. Document Constraints: Capture any limitations discovered during your discussions.

Managing Stakeholder’s Expectations

Setting Realistic Timelines

Stakeholders often want everything done yesterday. Managing their expectations requires transparency:

• Explain Trade-offs: Highlight what can’t be done if a specific task is prioritized.

• Provide Data: Use metrics like velocity and cycle time to justify timelines.

• Offer Alternatives: Suggest phased rollouts for complex tasks.

Communicating Delays

Delays are inevitable. The key is how you communicate them:

• Be Proactive: Inform stakeholders as soon as risks emerge.

• Focus on Solutions: Highlight what’s being done to get back on track.

• Reaffirm Value: Emphasize the importance of quality over rushing.

Collaboration for Better Ticket Management

Effective ticket prioritization often requires input from multiple stakeholders. To align everyone:

• Facilitate Discussions: Use sprint planning or backlog refinement meetings to reach agreements.

• Visualize Priorities: Use tools like Kanban boards to make trade-offs visible.

• Document Decisions: Record why certain tickets were prioritized to avoid future disputes.

Leveraging Tools

Modern tools can transform how teams manage tickets:

• JIRA: A robust platform for tracking tickets and visualizing workflows.

• Trello: Simple boards for lightweight ticket management.

• Linear: Streamlined ticketing for modern product teams.

Common Pitfalls

Avoid overloading the Sprint packing too many tickets into a sprint leads to unfinished work. Do not over commit.

Avoid Ignoring Technical Debt: Prioritizing only new features while neglecting technical debt creates long-term issues. Allocate a percentage of each sprint for debt repayment.

Avoid Lack of Clear Ownership: When no one owns a ticket, it gets lost. Assign clear owners for each task and hold them accountable.

Key Takeaways

1. Communication is Key: Start every ticket discussion by clarifying goals, requirements, and dependencies.

2. Prioritize for Impact: Use frameworks like WSJF and the Eisenhower Matrix to balance short-term urgency with long-term goals.

3. Align Stakeholders: Manage expectations with transparency and data-driven decisions.

4. Leverage Tools: Platforms like JIRA and Trello can streamline workflows and improve visibility.

5. Avoid Overloading: Focus on achievable sprints, technical debt, and clear ownership.

6. Size and Estimate Effectively: Break tasks into manageable sizes, identify dependencies, and use team-driven estimation techniques.

7. Plan for Uncertainty: Use discovery tickets and buffers for high-risk tasks.

8. Review Feasibility: Align tickets with technical architecture and tooling requirements.

Conflict with your manager happen. Sometimes, things get out of control, it could be a tense one-on-one, or a mistake that damages trust. These situations are challenging, but they’re not irreparable.

Here’s a 4-step framework for repairing damaged relationship with your manager:

Step 1: Own Your Mistakes

The first step in resolving conflict is to own responsibility for your actions. Acknowledge where you went wrong and apologize sincerely, without making excuses. For example:
“I handled this poorly.”
“I’m committed to fixing our relationship and ensuring this doesn’t happen again.”

From there, shift the conversation toward solutions. Ask, “How can we fix this together?” Work wit your manager to agree on clear next steps, make sure you document them to prevent misunderstandings and ensure accountability, as it is the foundation for rebuilding trust.

Step 2: Focus on Adding Value

Once you’ve acknowledged your mistakes, let your actions do the talking. Re-establishing trust requires consistent effort. Focus on:
Delivering high-quality work.
Sharing updates proactively and documenting your progress.
Aligning your efforts with team goals to demonstrate reliability.

Consistency over time proves that you’re serious about rebuilding trust and adds tangible value to the relationship.

Step 3: Be Patient

Trust is not rebuilt overnight. It takes time and repeated positive interactions to restore credibility. Be patient with the process, even if it feels slow.
Every delivered result, constructive interaction, and demonstrated improvement is a step forward. Stay consistent, and the relationship will gradually improve.

Step 4: Follow Up

Resolution doesn’t end with a single conversation. Regular check-ins show that you’re committed to maintaining and strengthening the relationship. Use these opportunities to:
Ask for feedback on how things are improving.
Reaffirm your dedication to the relationship and team goals.

Follow-ups demonstrate your investment in long-term success, not just short-term fixes.

Final Thoughts

Relationships may not always return to what they were, but with effort and persistence, you can rebuild credibility and move forward stronger than before.

Sometimes, despite your best efforts, the relationship remains strained or the environment becomes untenable. In these cases, it’s okay to move on. Prioritize your well-being and growth over staying in a toxic or irreparable situation.

Walking away isn’t a failure; it’s a recognition that some situations cannot be fixed. It’s better to focus your energy on opportunities that align with your values and aspirations.
What strategies have worked for you when handling workplace conflict? Share your insights in the comments!

When I first started leading teams, I tried to observe what made a great software engineer. What characteristics should I focus on while mentoring to help my team level up? I came across many observations. In this article, I am highlighting the common skills I found in great engineers I have known throughout my career.

The Outcome-Oriented Engineer

A good engineer focuses on meeting requirements, writing code, and delivering functionality. While these tasks are important, they don’t always address the core question:

Does this work create value?

Great engineers, on the other hand, look beyond the immediate deliverable and consider the broader impact. They ask:

• Why does this feature matter to the user?

• How does it align with business goals?

They view their role not just as problem-solvers but as value creators. These engineers are always curious to understand the problem they are solving beyond the minimum required to deliver the ticket. This curiosity drives great engineers to observe their stakeholders, understand their needs and pain points, and contribute by designing systems and creating solutions that address these challenges.

What makes great engineers stand out is their customer-centric approach. Whether serving internal customers like product managers and quality assurance teams, or focusing on end users, they always consider the broader impact of their work. Their curiosity to understand the problem they are solving, paired with technical expertise, drives their ability to add value and be outcome-driven engineers.

“We’re not competitor-obsessed, we’re customer-obsessed. We start with what the customer needs and we work backwards.”
— Jeff Bezos

At Amazon, the concept of “two-pizza teams” exemplifies this mindset. These small, autonomous groups are structured to ensure accountability and ownership over entire projects. For example, the team responsible for Amazon Prime Video tracks metrics like video streaming quality, playback speed, and user retention, integrating these metrics with technical aspects such as performance and downtime. By focusing on outcomes, engineers ensure their work aligns with business objectives and enhances customer satisfaction.

Looking at the big picture

Great engineers think about problems in terms of the system as a whole. They know that no component of a system stands alone and realize that to create scalable, maintainable solutions, they need to consider how each part interacts with other systems.

System thinking is at the heart of this approach, where the focus shifts from optimizing isolated features to ensuring that the system, in its entirety, will work seamlessly — even while growing or changing.

I remember when I started working as an engineer, I was often focused on solving the immediate problem in front of me — fixing a bug or optimizing a feature. As I gained more experience, I realized that this approach was not enough. The more I worked with complex systems, the more I understood how individual parts are interconnected, amplifying or reducing issues across the system. It was then that I understood how important it is to think of how each component works together as part of a cohesive whole to build something truly scalable and maintainable.

Netflix invested in this concept by introducing Chaos Engineering, which pushes system thinking to the next level. They introduced tools like Chaos Monkey, which purposely triggers failures in their systems, simulating real-world disruptions. This kind of stress testing has made Netflix’s architecture remarkably resilient. It pushed their engineers to think: How will my change react to surprises and unexpected scenarios?

Looking at the big picture doesn’t just apply to technical solution design. It also means being adaptive to change and understanding the broader vision.

Adapt and Anticipate

In 2008, Netflix faced a major database corruption that prevented them from shipping DVDs to customers for several days. This experience led them to realize they needed to migrate from using their own data centers to AWS.

The migration took seven years to complete. They could have moved their data centers directly to Amazon as-is, cutting down effort and time. Instead, they anticipated the need for future scalability and rebuilt their infrastructure to support the scale they now operate at, which is ten times the size it was in 2008.

Great engineers know that problems never exist in isolation. They focus on the bigger picture and the impact of every part of the system — how they relate and how to prioritize efforts based on the system’s needs. It’s about designing for resilience, scalability, and flexibility. Building solutions that not only work now but can adapt as the system evolves.

Whether developing a product, scaling architecture, or leading a team, this way of thinking makes the difference between a mediocre product and a great one. A great engineer owns the product and understands that combining technical expertise with soft skills and collaboration allows them to influence engineering excellence.

Collaboration and Influence: The Multiplier Effect

Engineering isn’t a solo pursuit.

The best engineers understand that great things happen when they collaborate. They don’t just write code in isolation; they connect with teammates, share ideas, and build trust to create amazing products.

Great engineers lead without a title but with influence. Instead of relying on hierarchy, they guide the team by encouraging open communication, sharing insights, and ensuring alignment on the same goal. They build trust by being approachable, inclusive, and credible. They share knowledge and help others without blame or judgment.

Psychological Safety in Teams

The impact of these traits is significant — they strongly affect overall team performance by increasing psychological safety. This was proven in Google’s research, which found that psychological safety is the foundation for great teams. This is why these engineers are indispensable; their multiplier effect enhances their peers and stakeholders alike.

This is why it’s essential to engage in constant communication. Regularly check in with your teammates — whether they’re engineers, designers, or product managers. Make sure you are moving in the same direction. The more you share, the clearer the collective vision becomes. When you work closely with others, you create a stronger, more unified approach to solving problems.

Whenever possible, talk to your colleagues in other roles regularly. Ask questions, share challenges, and collaborate to align on priorities. This ensures everyone is on the same page and avoids miscommunication that could derail progress.

Conclusion

Engineers should adopt the traits discussed above by asking the right questions and building meaningful connections with their teams and stakeholders. This will not only elevate their own capabilities and keep them motivated as they add value, but also make them indispensable to their teams.

TL;DR:

• Collaborate effectively: Build trust, communicate openly, and foster psychological safety within your team. Diverse perspectives lead to better solutions.

• Deliver measurable value: Go beyond shipping features — focus on solving real problems and ensuring your work creates meaningful impact.

• Adopt system thinking: Design scalable, resilient systems that consider future growth and the interconnectedness of all components.

• Be outcome-oriented: Align your work with business goals and user needs, ensuring it delivers tangible results.

👉 Checkout my blog
🐦 Follow me on X

Every software engineer knows the drill. A new feature request lands on your desk with a deadline that feels like it was set yesterday. You roll up your sleeves, knowing that delivering on time might mean cutting corners — skipping tests, hardcoding a value, or hacking together a quick fix. It feels great when the feature goes live, but weeks later, when the bug reports flood in, you wonder: was moving fast worth breaking things?

The reality is that engineering is a constant tug-of-war between speed and quality. Move too fast, and you build a house of cards that collapses at the worst time. Focus too much on perfection, and you risk being labeled “too slow.” But here’s the thing: speed and quality aren’t opposites. You don’t have to choose one over the other. Let’s dive into how you can move fast and build maintainable systems that won’t come back to haunt you.

Why “Move Fast and Break Things” Doesn’t Work

“Move fast and break things” became the go to philosophy for innovation during the startup boom. But for anyone who has worked on a live production system, this philosophy often feels like a disaster waiting to happen.

I have worked at a startup where the default was to ship fast. I once did a hotfix to show a loading indicator in a page no one uses. Adopting this philosophy means you are turning away from solving problems and becoming a feature factory with no consideration of data. After a while, we ended up with a product that always had bugs, very hard to fix, and slow to add features to. Our focus became to get what’s on production to run, with time we lost purpose and that was our only focus. The startup went bankrupt.

A more sustainable approach that could have saved the company would have been to prioritize long-term velocity. High-quality code may take slightly longer to ship, but it pays off by reducing the time spent fixing bugs, cleaning up spaghetti code, or firefighting in production.

Plan for Refactoring From the Start

Here’s a truth every engineer needs to embrace: shortcuts are inevitable. Deadlines, pivots, and last-minute changes happen, and sometimes you need to cut corners to deliver on time. The problem isn’t taking shortcuts — it’s treating them as permanent.

To balance speed with quality, start with the mindset that every shortcut is temporary. Log these quick fixes as tech debt tasks in your backlog, and prioritize them like you would a new feature. When planning sprints, allocate time to clean up code.

Think of it like writing a to-do list. If you borrowed code from Stack Overflow to hit a deadline, make sure to revisit it later and implement a proper solution. Engineers who plan for refactoring from day one build systems that evolve gracefully instead of breaking down. From my experience , agreeing with product managers on 10% of sprint velocity for refactoring is reasonable and would help maintain the codebase quality.

Focus on Containing the Mess

If you have to cut corners, make sure the mess doesn’t spread. When writing quick fixes or hacks, isolate them within specific modules, components, or files.

For instance, if you’re hardcoding a value for a quick demo, keep it in a clearly labeled config file or a single function. This makes it easier to find and replace later. The key is to keep these shortcuts localized, so they don’t become landmines scattered across your codebase.

One of my former teammates called this “putting the mess in a drawer.” It’s still there, but at least you know where to find it.

I follow the same approach for A/B tests, as there is a chance we will remove them if the test failed. I try to keep them isolated for easy cleanup and less affected area when we do. I would recommend doing the same for urgent requests. It will make refactoring much faster, and less likely to break things.

Feature Flags for Safe Iteration

Feature flags are a game-changer when you need to ship fast without sacrificing quality. By wrapping new features in a flag, you can deploy unfinished work to production safely. This lets you test with a small group of users, gather feedback, and iterate without risking the entire system.

For example, if you’re rolling out a new search feature, a feature flag allows you to enable it for 5% of users while monitoring performance. If something goes wrong, you can turn it off instantly without needing a rollback.

Feature flags give you the freedom to experiment without turning your production environment into a testing ground.

Automate Testing and Use CI/CD Pipelines

Nothing kills speed like regressions. You’ve shipped a feature, moved on to the next task, and suddenly, an old bug reappears. Now you’re stuck fixing it instead of building something new.

Automated tests and CI/CD pipelines are your best defense against this chaos. integration tests ensure modules play nicely together, and end-to-end tests validate user workflows.

Think of these as a safety net. They might take time to set up, but they let you move quickly without fear of breaking things. Plus, they make you look like a rockstar when you catch a bug before it reaches production.

Manual Regressions from QA can take a day or 2 for them to be done properly, without automation a lot of corners will be cut when a request is urgent causing a domino effect of bugs and hotfixes

Dedicate Time for Refactoring (Refactoring Fridays)

One of the simplest ways to balance speed and quality is to schedule time for maintenance.We discussed the 10% block. I experimented with that by introducing “Refactoring Fridays” — a day dedicated to paying down technical debt. No feature work, no distractions — just pure cleanup.

This practice worked wonders. Developers looked forward to Fridays because it gave them the breathing room to tidy up messy code and fix things they’d been meaning to address. The result? A healthier codebase and a happier team.

We did not dedicate the entire day but each engineer blocked a couple of hours in their calendar to clean up.

We also had another practice where we did mob programming as a team once a month for an hour to refactor a part in the system. This increased collaboration, team morale and our code base health.

Set Clear Priorities with Stakeholders

Engineers often face pressure from stakeholders to deliver faster. But here’s a pro tip: speed and quality don’t have to be at odds if you communicate effectively.

When discussing timelines with stakeholders, explain the trade-offs of cutting corners. For example:

“We can deliver this feature in two weeks, but to meet that deadline, we’ll take some shortcuts that will require cleanup later. Alternatively, we can spend an extra week building it properly, which will save us time in the long run.”

By framing the conversation around business outcomes (e.g., reduced risk, better performance), you can gain stakeholder buy-in for balanced timelines.

Speed and Quality Are Not Opposites

Balancing speed and quality isn’t just possible — it’s essential for sustainable development. By planning for refactoring, isolating quick fixes, leveraging feature flags, and automating tests, you can deliver fast without sacrificing maintainability.

Remember, moving fast doesn’t mean rushing blindly. It means being intentional about where you take shortcuts and having a plan to address them. So the next time you’re tempted to just “get it done,” take a moment to think long-term.

Fast doesn’t have to mean messy. Quality doesn’t have to mean slow. With the right practices, you can have both — and become the kind of engineer everyone wants on their team.

Have you found ways to balance speed and quality in your projects? I’d love to hear your strategies — drop them in the comments below!

Enjoyed this article? Follow me for more insights on becoming an Effective Engineer.

🐦 Follow me on X

This guide breaks down the essential concepts of distributed systems — stripped of heavy theory — and connects them to practical, real-world scenarios.

What Are Distributed Systems (and Why Do Engineers Need Them)?

A distributed system is a set of computers working together as one unit. This setup helps engineers:

• Scale horizontally (e.g., adding more machines to handle traffic).

• Handle failures gracefully (e.g., replicating data across multiple nodes).

• Ensure high performance (e.g., optimizing for low-latency access).

A typical e-commerce platform relies on:

• Compute instances behind a load balancer.

• A relational database for transactional data.

• Durable file storage replicated across regions.

1. Fault Tolerance: Preparing for Failures

In distributed systems, failures (server crashes, network partitions, etc.) are inevitable. Systems must continue running without disruption.

Strategies for Fault Tolerance:

• Data Replication: Store copies of data across multiple nodes to ensure durability.

• Health Checks and Failover: Replace unhealthy nodes and reroute traffic to healthy ones.

• Monitoring and Recovery: Detect errors and trigger automatic recovery actions.

Real-World Example: During a data center outage, services can maintain access by replicating data across multiple locations. For instance, a streaming service might rely on alarms to trigger scaling or failover processes, keeping the stream uninterrupted.

2. Balancing Consistency and Availability (CAP Theorem)

The CAP theorem states that distributed systems can only optimize for two out of three properties:

• Consistency: All nodes return the latest data.

• Availability: Every request receives a response, even during failures.

• Partition Tolerance: The system continues operating despite network failures.

Because network partitions are unavoidable, you must choose between consistency and availability depending on the use case.

Examples:

• Eventual Consistency: IoT Data Ingestion: High-volume sensor data can tolerate slight delays in propagating updates to all replicas. Content Delivery: Product catalogs or social media feeds where slight delays are acceptable.

• Strong Consistency: Healthcare Systems ensures accurate patient records during concurrent updates. Order Processing Guarantees that inventory is updated immediately to prevent overselling.

3. Transactions in Distributed Systems

Distributed systems often need to handle transactions — groups of operations that must succeed or fail together but ensuring atomicity, consistency, isolation, and durability (ACID) across distributed nodes is challenging.

Common Approaches:

1. Relational Databases: Offer ACID guarantees for transactional systems like banking or inventory management.

2. NoSQL Databases with Transactions: Allow multi-item, ACID-compliant transactions for use cases like transferring funds.

Example: Imagine a payment app. When transferring funds, you need to:

• Deduct the amount from one account.

• Add it to another account.

Distributed transactions ensure atomicity — both updates succeed or fail together.

Challenges:

• Throughput Constraints: Transactions can introduce bottlenecks under high loads.

• Scalability: Limited to a specific number of items or data size in some systems.

Simplifying Distributed Transactions: Traditional distributed systems used techniques like 2-Phase Commit (2PC) to ensure node consistency. Modern solutions abstract this complexity with managed transaction support, making it easier for engineers to build reliable systems.

Pro Tip: Use idempotent retries to handle network failures during transactions without introducing duplicates or inconsistencies.

Concrete Example: Consider a distributed order processing system. If a network failure occurs after an inventory reduction, retry logic ensures the inventory reduction is not repeated.

4. Scaling

Scaling distributed systems is about increasing capacity by adding machines (horizontal scaling) while maintaining performance.

Techniques for Scaling:

• Dynamic Scaling: Automatically add or remove resources based on demand.

• Read Replicas: Scale database reads by adding replicas.

• Serverless Scaling: Tools like serverless functions (e.g., AWS Lambda) reduce operational overhead by automatically handling resource scaling for event-driven systems. This is particularly useful for workflows like image processing or real-time notifications.

For a global chat application:

• Replicate user messages across regions to ensure low-latency access.

• Use caching for frequently accessed messages.

• Scale message processing workflows dynamically during peak loads.

Multi-Region Benefits:

• Latency Reduction: Replicate data closer to users in different regions.

• Disaster Recovery: Provide redundancy so traffic can failover during outages.

Key Takeaways

To build reliable, scalable distributed systems:

1. Use RPC for inter-service communication and handle retries.

2. Design for fault tolerance with strategies like data replication and failover.

3. Balance consistency and availability based on your use case.

4. Handle distributed transactions with relational or NoSQL databases.

5. Scale your system horizontally with dynamic scaling, replicas, caching, and serverless workflows.

Distributed systems are complex, but the principles remain universal. Focus on designing systems that embrace failures, balance consistency vs availability, and scale effortlessly to meet user demands.

Enjoyed this article? Follow me for more insights on becoming an Effective Engineer.

👉 Follow me on Medium
🐦 Follow me on X

So, what does it take to achieve technical excellence?

Great engineers recognize that speed and quality aren’t at odds — they complement each other when approached thoughtfully. For example, a team might prioritize delivering an MVP quickly but still apply solid engineering practices, such as writing modular, testable code. This allows them to iterate rapidly without accumulating excessive technical debt, ensuring that early speed doesn’t compromise long-term stability. When speed and quality align, teams can move fast while laying a strong foundation for future growth.

Technical excellence goes beyond writing good code — it involves building systems that last, navigating trade-offs thoughtfully, and owning outcomes beyond the immediate task. It requires a mindset that values long-term sustainability, craftsmanship, and the ability to adapt when the constraints of reality come into play.

This series will explore the core pillars of technical excellence:

1. Balancing Speed and Quality: Learn to deliver results quickly without sacrificing maintainability or creating chaos.

2. Building Systems That Last: Explore how to design systems with maintainability, scalability, and resilience in mind, ensuring they stand the test of time.

3. Measuring and Managing Technical Debt: Understand how to identify, quantify, and address technical debt so it doesn’t cripple your team in the future.

4. Navigating Trade-offs: Gain strategies for making thoughtful decisions when you’re working with limited time, resources, or competing priorities.

5. Craftsmanship and Ownership: Discover the importance of owning outcomes, prioritizing engineering quality, and building with a sense of pride and accountability.

Each article will provide actionable advice, real-world examples, and practical frameworks — like strategies for managing technical debt, workflows for balancing speed and quality, and case studies of scalable system design — to help you build systems that stand the test of time while delivering value to your team and organization.

Technical excellence isn’t a destination — it’s a journey. Along the way, you’ll sharpen your craft, drive meaningful impact, and inspire those around you to aim higher. By embracing technical excellence, you won’t just build better systems — you’ll become a better engineer. Let’s get started.

Follow me here or on X at The Effective Engineer to keep up with the series

In the traditional engineering view, the focus has often been on technical expertise. From university courses to online tutorials, the emphasis is on mastering programming languages, understanding complex algorithms, and working with data structures. While these skills are undeniably valuable, they represent only one piece of the puzzle for today’s engineers.

In light of the growing influence of AI in the tech industry, this article challenges the conventional narrative of what it means to be a successful engineer. As AI reshapes the landscape, engineering success demands more than technical competence. It requires an approach that considers the broader ecosystem in which software operates. The role of engineers is expanding beyond coding to include critical areas such as product ownership, collaboration, and understanding the impact of their work. In this evolving landscape, engineers must adapt and embrace the intersection of technical skills and team impact to thrive.

In this article, we aim to challenge the conventional narrative. True engineering success extends far beyond simply knowing how to code or grasping the intricacies of algorithms.

This perspective shift takes us into three crucial areas that define engineering excellence:

1. Technical Excellence

At its core, engineering demands a solid foundation in technical principles. A deep understanding of fundamental computer science concepts — data structures, algorithms, software design patterns — is essential. Engineers need proficiency in programming languages, whether object-oriented or functional, as well as a clear understanding of system architecture, ensuring different components interact seamlessly in scalable and maintainable systems.

However, in today’s world, technical excellence goes beyond just coding proficiency. It’s about continuously learning, staying up-to-date with emerging technologies and methodologies, and dedicating oneself to writing clean, efficient, and well-documented code. Embracing best practices like unit testing, code reviews, and continuous integration helps ensure the codebase remains robust, adaptable, and maintainable.

2. Product Ownership

In today’s fast-paced, user-centric world, engineers need to be more than just code producers — they must become product owners. This means they need to understand the underlying business objectives and the needs of the users. Engineers must shift from a task-oriented mindset to a product-focused approach.

Active participation in product discussions with product managers, designers, and other stakeholders is key. Engineers must understand user needs, define product requirements, and translate those needs into effective technical solutions. A strong grasp of user experience (UX) principles is essential, as engineers strive to build products that are not only technically sound but also intuitive and user-friendly.

Moreover, successful engineers track the impact of their work by defining and monitoring key performance indicators (KPIs). This allows them to make data-driven decisions, prioritize efforts effectively, and continuously enhance their contributions.

3. Collaboration & Influence

Engineering is inherently collaborative. Successful projects almost always result from the effective interplay of diverse skills and perspectives. This part of engineering is about more than just technical output — it’s about relationships, influence, and building a positive, productive environment.

Building Strong Relationships

• Effective Communication: Clear, concise communication of technical concepts to both technical and non-technical audiences is essential. Whether it’s explaining complex systems to stakeholders or writing documentation, strong communication skills are a must.

• Active Listening: Listening to understand others’ perspectives fosters empathy and builds stronger relationships.

• Cross-Functional Collaboration: Engineers need to work effectively with various teams — product managers, designers, and marketers — ensuring that everyone is aligned and any conflicts are resolved.

Leading and Influencing Without a Title

• Mentorship & Guidance: Supporting junior engineers, sharing knowledge, and fostering a learning culture strengthens the team as a whole.

• Driving Positive Change: Engineers should take the initiative to improve processes, increase efficiency, and raise team morale.

• Building a Strong Engineering Culture: Contributing to a team culture that values collaboration, innovation, and a shared sense of purpose can have a lasting impact.

Expanding Your Impact: From Implementation to Influence

The traditional image of an engineer is often that of a lone coder, focused solely on writing code. While this picture still holds some truth, it misses the broader role that engineers play today. The journey from being a proficient coder to an outcome-driven engineer involves a fundamental shift:

• From Task-Oriented to Product-Oriented: Engineers need to engage in product discussions, understand strategic goals, and prioritize their work based on potential impact.

• From Individual Contributor to Team Player: Engineers should contribute to creating a positive team environment, share knowledge, mentor others, and collaborate effectively with cross-functional teams.

• From Code Producer to Problem Solver: Engineers should focus on solving real-world problems rather than just writing code. They must design solutions that meet user needs, address business challenges, and drive innovation.

• From Technical Specialist to Business Partner: Engineers should understand the business context of their work and communicate technical implications to both technical and non-technical stakeholders.

This shift is ongoing. It requires continuous learning, stepping outside of one’s comfort zone, and a commitment to personal growth. The engineers who thrive today are those who embrace these transformations and actively seek opportunities to expand their skills and influence.

By embracing this engineering approach — technical excellence, product ownership, and collaboration — engineers can unlock their full potential. They can move beyond just writing code and become indispensable contributors to their teams and the broader tech ecosystem.