Forem: Jayant Bhawal

#developer #productivity #programming #career

1. Arrays 🧩: Your Go-to in State Management

Arrays are everywhere in React. If you need help understanding how .map() or .filter() work, you’re probably seeing this post a little too soon! But don’t worry—once you get comfortable with these array methods, you’ll see how essential they are for rendering lists, managing component states, and transforming data.

2. Objects and Hash Maps 🗺️: Normalized Data Store for Efficiency

In a React app, when you deal with a large collection of entities like users or posts, normalizing your data into objects (hash maps) can make reading and updating much more efficient. Instead of working with a deeply nested structure, you map entities by their IDs.

Example: Reading from a normalized store with IDs



const postsById = {
  1: { id: 1, title: 'First Post', content: 'Content of first post' },
  2: { id: 2, title: 'Second Post', content: 'Content of second post' }
};

const postIds = [1, 2];

function PostList() {
  return (
    <div>
      {postIds.map(id => (
        <Post key={id} post={postsById[id]} />
      ))}
    </div>
  );
}

function Post({ post }) {
  return (
    <div>
      <h2>{post.title}</h2>
      <p>{post.content}</p>
    </div>
  );
}

This pattern allows for efficient data access, especially with large datasets where updates or reads need to happen quickly without re-rendering the entire collection.

3. Doubly Linked Lists 🔗: Navigation with Context

Doubly linked lists are useful when you need context from both the previous and next elements—think of navigating a photo gallery where each image displays its neighboring images for reference. Instead of using an index, we'll store the current node directly in the component state.

Example: Doubly linked list for navigation between elements with context



class Node {
  constructor(value) {
    this.value = value;
    this.next = null;
    this.prev = null;
  }
}

class DoublyLinkedList {
  constructor() {
    this.head = null;
    this.tail = null;
  }

  add(value) {
    const newNode = new Node(value);
    if (!this.head) {
      this.head = newNode;
      this.tail = newNode;
    } else {
      this.tail.next = newNode;
      newNode.prev = this.tail;
      this.tail = newNode;
    }
  }
}

const imageList = new DoublyLinkedList();
imageList.add({ id: 1, src: 'image1.jpg', alt: 'First Image' });
imageList.add({ id: 2, src: 'image2.jpg', alt: 'Second Image' });
imageList.add({ id: 3, src: 'image3.jpg', alt: 'Third Image' });

function Gallery() {
  const [currentNode, setCurrentNode] = useState(imageList.head);

  return (
    <div>
      {currentNode.prev && (
        <img src={currentNode.prev.value.src} alt={currentNode.prev.value.alt} className="prev-image" />
      )}
      <img src={currentNode.value.src} alt={currentNode.value.alt} className="main-image" />
      {currentNode.next && (
        <img src={currentNode.next.value.src} alt={currentNode.next.value.alt} className="next-image" />
      )}
      <div>
        <button onClick={() => setCurrentNode(currentNode.prev)} disabled={!currentNode.prev}>
          Previous
        </button>
        <button onClick={() => setCurrentNode(currentNode.next)} disabled={!currentNode.next}>
          Next
        </button>
      </div>
    </div>
  );
}

In this React component:

The current node is stored in the state, and the UI updates based on whether there’s a previous or next node.
The buttons enable users to navigate the list both forwards and backwards, and disable if there’s no more nodes to move to.
This structure simulates real-time navigation with context from the surrounding elements, commonly used in UI components like carousels, media galleries, or playlists.

4. Stacks 🚀: Undo/Redo Functionality with Immutable Behavior

Stacks allow you to manage undo/redo operations efficiently using Last In, First Out (LIFO) logic. By using immutable operations (concat, slice), we can ensure state remains unmutated.

Example: Undo/Redo with immutable push and pop



const [undoStack, setUndoStack] = useState([]);
const [redoStack, setRedoStack] = useState([]);
const [formState, setFormState] = useState({ name: '', email: '' });

const updateForm = (newState) => {
  setUndoStack(prev => prev.concat([formState]));  // Immutable push
  setRedoStack([]);  // Clear redo stack
  setFormState(newState);
};

const undo = () => {
  if (undoStack.length > 0) {
    const lastState = undoStack.at(-1);
    setUndoStack(prev => prev.slice(0, -1));  // Immutable pop
    setRedoStack(prev => prev.concat([formState]));  // Move current state to redo
    setFormState(lastState);
  }
};

const redo = () => {
  if (redoStack.length > 0) {
    const lastRedo = redoStack.at(-1);
    setRedoStack(prev => prev.slice(0, -1));  // Immutable pop
    setUndoStack(prev => prev.concat([formState]));  // Push current state to undo
    setFormState(lastRedo);
  }
};

5. Queues 📬: Managing Sequential API Calls

Queues operate in a First In, First Out (FIFO) manner and are great for ensuring that tasks like API calls or notifications are processed in the correct order.

Example: Queueing API calls



const [apiQueue, setApiQueue] = useState([]);

const enqueueApiCall = (apiCall) => {
  setApiQueue(prevQueue => prevQueue.concat([apiCall]));  // Immutable push
};

const processQueue = () => {
  if (apiQueue.length > 0) {
    const [nextCall, ...restQueue] = apiQueue;
    nextCall().finally(() => setApiQueue(restQueue));  // Immutable pop
  }
};

6. Trees 🌳: Rendering Recursive Components

Trees are commonly used in React when dealing with nested components like comment threads, folder structures, or menus.

Example: Rendering a comment tree recursively



const commentTree = {
  id: 1,
  text: "First comment",
  children: [
    { id: 2, text: "Reply to first comment", children: [] },
    { id: 3, text: "Another reply", children: [{ id: 4, text: "Nested reply" }] }
  ]
};

function Comment({ comment }) {
  return (
    <div>
      <p>{comment.text}</p>
      {comment.children?.map(child => (
        <div style={{ paddingLeft: '20px' }} key={child.id}>
          <Comment comment={child} />
        </div>
      ))}
    </div>
  );
}

Another popular post that might be relevant to you:

Write Less, Fix Never: The Art of Highly Reliable Code

Dhruv Agarwal for Middleware ・ Jun 17

7. Graphs 🎯: Building Complex Data Relationships and Navigation

Example 1: Routing between multiple views
You can represent routes between pages as a graph, ensuring flexible navigation paths in an SPA.



const routesGraph = {
  home: ['about', 'contact'],
  about: ['home', 'team'],
  contact: ['home'],
};

function navigate(currentRoute, targetRoute) {
  if (routesGraph[currentRoute].includes(targetRoute)) {
    console.log(`Navigating from ${currentRoute} to ${targetRoute}`);
  } else {
    console.log(`Invalid route from ${currentRoute} to ${targetRoute}`);
  }
}

Example 2: User relationship modeling
Graphs are perfect for modeling social connections or any kind of relationship where multiple entities are interconnected.



const usersGraph = {
  user1: ['user2', 'user3'],
  user2: ['user1', 'user4'],
  user3: ['user1'],
  user4: ['user2']
};

function findConnections(userId) {
  return usersGraph[userId] || [];
}

console.log(findConnections('user1'));  // Outputs: ['user2', 'user3']

Note: We use graphs to show reviewer dependencies in Middleware.

TL;DR — Those School Lessons Pay Off

Those DSA classes might have felt abstract back in the day, but data structures are powering the world around you in React.

Objects, stacks, queues, linked lists, trees, and graphs are more than just theory — they’re the backbone of the clean, efficient, and scalable apps you build every day.

So the next time you manage state in a queue or handle complex UI logic, remember: you’ve been training for this since school. 💪

Let me know which data structures you’ve been using the most!

Is CSP Actually Helping with Your Security? 🤔

Jayant Bhawal — Thu, 29 Aug 2024 17:45:44 +0000

Content Security Policy (CSP) – sounds fancy, right? Like the shiny new toy in the web security playground. It’s supposed to protect your web app from all sorts of bad stuff, but is it really the superhero you think it is? Or is it more like that overhyped gadget that promises a lot but delivers… well, let’s just say it could use some work. Let’s dive in and see what’s what!

What is CSP Anyway?

For those of you who haven’t dived into CSP land yet, here’s a quick rundown: CSP is a security feature that helps prevent a range of attacks, such as Cross-Site Scripting (XSS) and data injection. It does this by telling the browser what content it’s allowed to load and from where. Think of it like a bouncer at the club of your web app – only the cool, verified sources get in.

Sounds great, right? But like most things in tech, the devil is in the details.

The Reality Check 🔍

CSP Is Only as Good as Its Configuration

Let’s be honest: a poorly configured CSP is like a half-baked pizza – not satisfying and probably going to give you trouble later. If you’re just slapping 'unsafe-inline' or a broad 'self' directive in there, you’re not really getting the full benefit. It’s like putting a Band-Aid on a bullet wound – not gonna cut it. The key is to be precise and intentional with your policy. If you’re just guessing, you might as well not bother.
It’s Not a Silver Bullet

Here’s a reality check: CSP isn’t going to save your bacon if you’re ignoring other security practices. It’s just one piece of the puzzle. You still need to do the basics: input validation, proper session management, regular security audits, etc. Relying on CSP alone is like using a bicycle lock to protect your car – it’s just not enough.
Real-World Impact and Limitations

Here’s the kicker: not all browsers fully support CSP, and even when they do, there’s a lot of variation in how they handle it. If your users are on older browsers (why though?), CSP isn’t going to do much for them. Plus, CSP can break legitimate functionality if you’re not careful. Ever set up a CSP and then spent hours debugging why your slick new feature isn’t working? Yeah, it can be a bit of a headache.
The Dev Workload

Setting up CSP correctly isn’t a one-time thing; it’s an ongoing process. You have to keep an eye on what scripts are being loaded from where and ensure they’re not doing anything sketchy. It’s like having a part-time job as a security guard for your own app. If you’re a small team or flying solo, it might be more hassle than it’s worth – unless you enjoy living on the edge.

So, Should You Bother with CSP?

In short, yes – but don’t expect it to solve all your problems. CSP can be a great tool to have in your security arsenal, especially for reducing the risk of XSS attacks on modern browsers. However, it should be just one part of a comprehensive security strategy. Think of it like a sidekick in your crime-fighting squad – helpful, but not the main hero.

Here’s my 2 cents: use CSP, but don’t rely on it exclusively. Make sure it’s properly configured, keep it updated, and use it as part of a layered security approach. Security isn’t a one-and-done deal – it’s a continuous process. Just like keeping up with all the memes, you’ve got to stay on top of it. 😉

Learn about what a CSP looks like, at the best source possible:

Content Security Policy (CSP) - HTTP | MDN

Content Security Policy (CSP) is an added layer of security that helps to detect and mitigate certain types of attacks, including Cross-Site Scripting (XSS) and data injection attacks. These attacks are used for everything from data theft, to site defacement, to malware distribution.

developer.mozilla.org

Personal anecdotes with CSP

I’m okay with saying that I didn’t always know everything. 😛

The Time CSP Broke My App (because I didn’t understand CSP)
I thought I had our app running smoothly, and then we decided to use the Clearbit API to load company logos. Right after deploying, the logos weren’t loading, and errors were popping up everywhere. I immediately blamed adblockers, assuming they were causing the issue.

After some time tweaking things and going in circles, I realized the problem wasn’t adblockers at all. It was our existing CSP. We had a strict CSP that didn’t account for Clearbit, and I hadn’t updated it to allow requests to their domain.

It was a classic mistake, thinking everything would just work without understanding how our CSP needed to be adjusted for new features. It taught me to always check security settings whenever making changes to avoid breaking functionality.

Me trying to build software (used to be) like 👆

When I thought React was magic
Earlier in my career, when I was still new to React, and React was still new to the world (JSX had literally just come out), I made a pretty careless mistake that left our app wide open to XSS attacks.

I was rushing through a feature and didn’t bother sanitizing some user input. I mean, it was sanitized against DB attacks, but… I thought ‘It’s React; what’s the worst that could happen?’ Well, a lot, as it turns out. I was using dangerouslySetInnerHTML to render some rich-text user-generated content without realizing the potential risks. Our QA team managed to inject malicious scripts through a form input, and I learnt (kind of) the hard way how React wasn’t as magic as I thought.

It was a tough lesson on why you should never cut corners with security and always respect those “dangerously” warnings, no matter how fancy the framework."

What’s your take on CSP? Love it, hate it, or somewhere in between? Drop a comment below and let’s chat!

If you liked this, check out this post I wrote a while ago.

6 ways to turn your browser into super-debug-hero (ft. node.js + next.js!)

Jayant Bhawal for Middleware ・ Jul 3

#webdev #javascript #testing #frontend

And maybe check out some other work I'm involved with?
Open Source Dora Metrics ⚡️

Why You’re Getting Blamed for Delays (And How Open-Source Dora Metrics Can Help)

Jayant Bhawal — Thu, 08 Aug 2024 15:30:36 +0000

Hello there! 👋

📖 Story time! 📖

It’s Friday.
The feature was due yesterday.
The code review took longer than expected.
A couple of days ago, you submitted the PR for review.

Some change was requested, you update it and submit for another review.
Another small change was requested. You update and re-submit.
Wait, another change request? Why aren’t they reviewing thoroughly in one go?
Oh, they seem to be pretty darn busy too? I mean, what could you do eh?

Wind whooshes around you…

And suddenly, a tap on your shoulder.
You turn around, and it’s…
YOUR MANAGER! 😱
And you’re asked the dreaded question…
“Where’s the feature? You said it’ll be ready to go yesterday, yet here I am. 🤷”

Ever been in those shoes?
You're not alone.

Management often doesn’t want to hear about the blockers; they just want to know why the release didn’t go out as planned. You try to explain, but it feels like you’re just making excuses. It’s frustrating, especially when you know these delays aren’t your fault. Yet, you’re not sure what you can do to convince them otherwise.

You Can’t Fix What You Don’t Measure

Here’s the thing: It’s impossible to fix problems if you don’t know what they are. And it’s even harder to explain those problems if you don’t have the data to back you up. When your team’s performance is being judged solely on outcomes without considering the roadblocks, you’re set up to fail.

“You can’t fix what you don’t measure,” couldn’t be more relevant here. Without accurate metrics, you’re flying blind. But it’s not just about measuring; it’s about measuring the right things.

“But how do I know what to measure?”

Google Search: Did you mean, “What are Dora metrics?”

This is where Dora metrics come into play. Dora metrics were developed by the team behind the Accelerate book (if you haven’t read it, it’s worth your time) to provide a data-driven approach to understanding and improving software delivery performance.

(It used to be related to DevOps, but Google is changing that up now to be more generally applicable)

Dora focuses on four key metrics:

Deployment Frequency: How often you’re deploying code to production.
Lead Time for Changes: The time it takes from code committed to code successfully running in production.
Change Failure Rate: The percentage of deployments that result in a failure in production.
Time to Restore Service: How long it takes to recover from a failure in production.

These metrics are powerful because they don’t just focus on speed—they balance it with quality and reliability. It’s not just about pushing code out quickly; it’s about pushing code that doesn’t break things and can be quickly fixed when it does.

Resilience Against Goodhart’s Law

Goodhart’s Law says that when a measure becomes a target, it ceases to be a good measure. The beauty of Dora metrics is that they’re designed to avoid this trap. Because these metrics are interconnected, focusing on one to the detriment of others won’t help you game the system. For instance, increasing deployment frequency at the cost of a higher change failure rate isn’t going to make you look good. These metrics work together to give a comprehensive view of your team’s performance—balancing speed with stability.

Credits: AWS

How Open-Source Dora Metrics Can Help

This is where Middleware comes into play. Middleware is designed to give you the full picture, not just the highlights that management wants to see. By tracking Dora metrics, Middleware provides actionable insights into both your successes and the challenges that slow you down.

But here’s what makes Middleware truly stand out: it’s fully open-source and self-hostable.
You can run it locally using docker right now, and have your insights live in 5 minutes!

The Benefits of Open Source

Transparency and Trust: With open-source software, you can look under the hood. There’s no mystery about how your data is being handled because you can inspect the code yourself. No hidden telemetry, no data being siphoned off to some third-party service. What you see is what you get.
Total Ownership of Your Data: Since Middleware is self-hostable, your data stays exactly where you want it—on your own infrastructure. This means zero external telemetry, so your team’s performance data isn’t being sent off to someone else’s servers. You’re in full control of your data, from start to finish.
Flexibility, and Community Support: Being open-source means you can tailor Middleware to fit your exact needs. Whether it’s tweaking the dashboards, adding new integrations, or modifying how metrics are calculated, you’ve got the freedom to make it your own, and the community is there to help you out instead of waiting for an arbitrary roadmap.

How Middleware Helps You Measure What Matters

Capturing Blockers: Middleware doesn’t just track how fast you’re delivering; it captures the why behind any delays. Whether it’s a review blockage, deployment issues, or a critical bug that held things up, Middleware makes sure those blockers are visible and accounted for.
Avoiding the Goodhart’s Law Trap: By providing a balanced view of your performance, Middleware helps prevent management from zeroing in on a single metric. Instead, they see the full story, which leads to more informed decisions and fairer evaluations of your team’s work.
Turning Data into Action: Once you have the right metrics, you can start fixing the real issues. Middleware’s insights help you identify bottlenecks and inefficiencies, so you can focus on improving the process, not just chasing numbers.

Middleware Open-Source

Middleware: The Tool That Helps You Fix What You Measure

At the end of the day, you’re doing everything you can to deliver great software. But when things go wrong, it’s essential to have the data to show why—and to make sure you’re measuring what truly matters, not just what looks good on a report.

Middleware empowers you to do just that. By providing clear, actionable insights into your team’s performance and the challenges you face, Middleware helps you move from justifying delays to fixing the root causes. And because it’s open-source and self-hostable, you can do all of this with total control over your data. Your answers are literally a docker pull away!

Check out Middleware on Github today and start measuring what matters, while keeping your data exactly where it belongs—with you.

We’re early in our journey right now, and we’ll love to have the support of devs like you to present insights in a way that DEVS would love. 🤝

🌟 Maybe, leave us a star? 🌟

🙅 Why Hating TypeScript in 2024 Doesn't Make Sense

Jayant Bhawal — Sun, 04 Aug 2024 17:32:32 +0000

I've been seeing this trend lately: more and more developers bashing TypeScript. The gripes range from it being "too complex" to "slowing down development."

While not all concerns are unfounded, hating on TypeScript in 2024 just doesn't add up.

Let’s break it down. 🔍

TypeScript Isn’t Your Enemy, It’s Your Safety Net

I get it—JavaScript is flexible, dynamic, and lets you ship code fast. But that same flexibility is also what leads to bugs that are hard to catch until it’s too late. TypeScript's strictness isn’t there to slow you down; it’s there to save you from spending hours debugging issues that could have been caught early.

Here’s an example:



let id;
getUserByID(id);

In theory, id can be a number, a UUID, a random string, or a structured string. But depending on what type it is, you might get an error if you try to increment it or pass it to an API that expects it to have a specific structure and type.

And you can figure out what type it is by looking at how it’s used. But you know what makes this a non-issue?



let id: number;
function getUserByID(id: string) {...}
// and that's the most basic thing you could do
getUserByID(id); // boink, error!

When you add TypeScript to your project, you're adding a layer of security. It’s like putting on a seatbelt. Sure, you can drive without it, but why risk it when a simple precaution could save you from a crash? 🚗💥 In a time where software quality is more critical than ever, TypeScript’s type-checking is a safeguard that just makes sense.

It’s Not as Complicated as You Think

Another complaint I hear often is that TypeScript is "too complicated." But let’s be real—JavaScript can be a mess. Function signatures that accept any input, objects that morph shape, and code that’s one typo away from breaking in production. TypeScript isn’t adding complexity; it’s formalizing or standardizing it.

Think about it this way:

You’re working on the frontend side of a feature, and someone else might have some work overlapping with you. There’s also going to be backend APIs you need to incorporate, but those aren’t ready yet. You’ve been asked to begin the UI work anyway.

How do you ensure that the code you write right now is consistent with the data you’ll get from the APIs? And that if something does change on the APIs, there’s a source of truth that all parties need to adhere to?

That’s right.
By defining types.

With types defined before implementation begins, there should be no confusion about what data contracts are shared between the UI and APIs, and if something indeed is different, then all that needs to be done is to go and stick to the contracts defined earlier.

If you can learn React, wrangle with Webpack, or deal with async/await, then you can learn TypeScript. And here’s the kicker—it’s a skill that pays dividends. The learning curve is worth it because it forces you to think more critically about your code. Instead of hacking together a quick fix, you’re thinking about architecture, types, and long-term maintainability. 🛠️

Faster Development, Not Slower

There’s this myth that TypeScript slows down development. But in reality, the opposite is often true. By catching errors during compile time instead of at runtime, TypeScript helps you move faster in the long run. You’re not spending your days in the browser console, chasing down undefined variables or weird type coercions. 🚀

TypeScript’s tooling is also top-notch.
Features like autocompletion, refactoring tools, and inline documentation make the development experience smoother. You’re not just writing code—you’re navigating a well-lit, well-marked road instead of stumbling around in the dark. 🌟

Here’s a personal anecdote.
Before I fully embraced TypeScript, I often found myself in the weeds of codebase archaeology. I’d encounter a function and have no idea what arguments it was supposed to take. Was it a string? An object? What params were needed in this object? Which ones were optional? Was something that was made to look optional actually required somewhere in the callstack?

Because devs aren’t perfect, poor variable names, inconsistent naming conventions, and coding preferences get in the way all the time…

So, I’d do the dance: scrolling back to the function’s declaration, digging through implementations, trying to piece together what was supposed to go where. And if autocomplete was supposed to save me? Forget it. It was useless. The code editor was just as clueless as I was. 😅

Sure, you could argue that JSDoc comments might help. But if you’re going through all that effort to manually document types and function signatures, then why are you doing that to yourself? You’re basically doing TypeScript’s job, but without any of the actual benefits. TypeScript eliminates all that guesswork, letting you code with confidence and speed.

TypeScript Is the Future (And the Present)

TypeScript is on its 5th version. It’s basically at 100k stars on GitHub. It has 55 Million+ downloads PER WEEK on NPM. More and more major projects and companies are adopting it. There’s a reason for that: TypeScript brings stability, scalability, and confidence to codebases. It’s not just about today’s project, but about building something that can grow and evolve without collapsing under its own weight. It’s about not having to write documentation and tests separately all the time (it doesn’t entirely replace them, of course).

So, let’s cut through the noise. The hate TypeScript gets in 2024 is largely misplaced. Sure, it’s not perfect — no tool is. But the benefits far outweigh the drawbacks. It’s time to stop viewing TypeScript as an obstacle and start seeing it as the essential tool it is.

Embrace it, learn it, and you’ll find yourself writing better code, faster. 💪

TypeScript Isn’t Perfect, but don’t let perfect be the enemy of good!

Of course, TypeScript isn't without its flaws. One legitimate gripe is the overhead of setting it up in a project that wasn’t built with it in mind. Converting a legacy codebase to TypeScript can be a time-consuming process, and it’s not always feasible for teams that are under tight deadlines. ⏳

Additionally, sometimes TypeScript’s strict type system can feel like it’s fighting you rather than helping you, especially when you're dealing with complex types or third-party libraries that haven’t been properly typed.

TypeScript is only as good as the dev configuring it.
I’ve worked on multiple TS projects, some of which had relatively lax configurations that would allow people to use any types or avoid strict or null checks. You mix untyped or loosely typed code into a typed codebase, and the situation could end up being bad enough.

Where do we go from here?

That said, these are short-term pains for long-term gains. Yes, it might slow you down initially, but the stability and maintainability you gain more than make up for it.

And these issues used to be a lot more severe a few years ago, but it’s arguably a lot better now.

In my opinion, put in the effort to learn TS. TS enables you to partially introduce it to an existing codebase—try that. Or perhaps create smaller pet projects that leverage TypeScript.

Plus, TS devs make a bit more money than JS devs based on the most recent StackOverflow survey.

And speaking of better code...

If you're curious about how TypeScript can level up a real-world project:

⚡️ Check out the Middleware repo ⚡️

It's a great example of TypeScript in action, and who knows—you might just pick up a few ideas for your own projects! 🚀

Even better, tell us how our code IS NOT the best!
If you have some solid suggestions, I'll amend the post to include them as examples!

Leaving Uber in 2022 was the best thing I did for myself 🚶💼

Jayant Bhawal — Thu, 18 Jul 2024 07:01:52 +0000

tl;dr 📖

I had a cushy job at Uber—decent work, great people. But the red tape was overwhelming. Too many approvals and permissions made it hard to get things done. I wanted to build and deliver great stuff, not wait for basic approvals from a dozen people every time something needed to get done. And Uber’s dev productivity measures at the time didn't make sense either.

When talking to managers didn't help and I couldn't make an impact soon enough, I decided to leave and tackle it from the outside.

“Free of the shackles!” They say…

Now, the longer version…

The Comfort of Uber 🛌

Once upon a time… as a tech lead, I had everything: Good income, interesting work, and recognition. But something was missing. The work, while important, wasn't fulfilling enough. It often took too long to deliver most things. And the metrics used to measure developer productivity felt gameable and inadequate, and didn't always reflect true impact.

Leaving that cushy, high-paying job at Uber was one of the toughest decisions I've ever made (I took months to decide).

The Uber Office S01E01 🏢

My first project at Uber was kickass, and all my managers at Uber were great. In fact, in my personal experience I loved all the people that I got to work with. Friendly. Skilled. Considerate.

And the project was something that I had to build with my small team almost from scratch. It had a great focus on accessibility, a lot of design effort behind it, just the kind of project I would love to be a part of.

And because it was something being built from scratch, there wasn’t a lot of past baggage to carry along. Not many “approvals” were needed from outside the core team. The planning, design, execution was contained within the “inner circle”. That meant collaboration was super fast, and so was the execution.

But it wasn’t meant to last.

And then the honeymoon period ended…

Not everyone’s experience was similar, and my subsequent projects were not that interesting either. For most people it was minor features or maintenance work. Even if they were mid-sized features, I was one among thousands of other devs and the initial awe wore off pretty quickly. It felt like if I was missing for a couple of says, or on leave for a week nothing would really be affected significantly. I didn’t like that.

It’s not like I was underperforming either. I must be performing great because it reflected uniformly in my feedback cycles, appraisals, and the fact that I was given an “impact award”.
It just felt like despite all that, I wasn’t doing the kind of thing I wanted to do.

The Red Tape 🔴

A large company is like a large heavy ship. It’ll go where it needs to but it’ll take time, and it’ll definitely change course super slowly.

At Uber, they had THOUSANDS of codebases. Over time the internal “reviewer” configuration would be updated to add new reviewers to the list, often without removing the older ones or those that aren’t relevant or involved in that codebase anymore only being handled on a case-by-case basis.

Uber also has the amazing concept of ERDs (not unique to them of course). Which are basically PRDs but very engineering and implementation specific. But this idea too was slowed down by the bureaucratic processes and the number of people that needed to be involved eventually.

Things would spend WEEKS in this phase! Sure, this allowed for some very solid and thought through implementations, and a company like Uber could suffer the delay for a more robust implementation. Except…

There was no one to verify if the implementation actually matched the documentation.
Good intention, but not well adhered to.

“One day, I want to be the kind of dev who goes through 5 steps of red-tape before delivering code!” — Said no one ever.

Everything changed when the Metrics Nation attacked 🔥

In the first half of my time there, annual reviews took a while to happen. Managers and other team leads would form a panel and manually try to gather data to evaluate devs by the numbers.
I did not know at this point what the metrics were, or how much they were weighted. What I know is that there wasn’t much in the way of automations involved, it was a fairly manual process (this changed later).

Interpersonal feedback and direct evaluation by the manager held a significant weight, and the whole process in general felt fairly transparent. I was okay with that. But then, efforts were made to automate this process…

Dashboards were created to track the stats of individuals across various teams.

And… One of the things being measured was line count and number of PRs per month. 😱
Yeah… it’ll take you 0.01234 microseconds to realize how this is a bad idea. Within days devs were artificially inflating PR count, splitting PRs when they didn’t need to be to inflate this count.

I don’t blame them. 🤷

So, I tried to sort it out 💪

I’ve always liked solving problems. I do puzzles in my free time, often play strategy games on my PC (when I’m not shooting Nazis in Wolfenstein, or save my cabbage patch in Stardew Valley).

I often solved problems that affected me or my team in terms or developer experience, productivity, documentation, etc. usually by going out of my way. I found it fun. 🤷

And I’ve always been a pretty passionate dev. I care about what I build, and I care about my fellow devs. Naturally that extended into caring about the evaluation process.

When automated dashboards came into play for evaluating us devs, naturally we started talking about it, increasingly frequently over time because the metrics used for that matter felt so flawed. And talking to leadership about it changed nothing in the time I remained at Uber.

Gameable Metrics

🗓️ At this point, we’re in the 2nd half of 2021 🗓️

The metrics used to measure developer productivity often felt more like a game than a true reflection of work quality. Promotions were sometimes based on these flawed indicators, leading to frustration. I felt super tempted to make smaller related changes in separate PRs when normally I may have not. It felt fake.

Some specific things measured were:

Number of PRs per month
- Devs started making smaller than needed or more frivolous PRs
- Devs started making PRs for older low priority things if their PR count was running low
- Some PRs started to be approved by friendly devs in the same team to inflate PR count
Line count per PR
- Devs started writing more verbose code
- Extra newlines
- Unnecessary refactors

Of course, not all devs were okay with doing this. But some were, especially those that had low numbers on these stats. Often the numbers might be low because they are working on something that involves more planning, design, or documentation involvement. But that wasn’t captured on these dashboards.

We talked to leadership about it, specifically about how this is possibly more harmful and the previous way of doing things seemed better and while it seemed like they agreed, nothing really changed.

And this was a time when I was already increasingly dissatisfied with my time at Uber…

That brings us to 2022 🗓️

The Idea of Middleware

Around this time, Dhruv pitched me the idea for Middleware. The concept was intriguing: a platform designed to enable developers to ACTUALLY do their work, highlight what prevents them from doing what they love, bottlenecks, process blockers, etc.

The first thing that jumped to my mind was…
“If I had something like this to show insights to my manager, it would be so much more helpful than whatever they are doing right now.”

After several months of discussions and consideration, in August 2022 I finally decided decided to take the leap and join the man on this journey. The decision wasn't easy, but it felt right. 🚀
This was just 2 days after my birthday too! 🎂

The Startup Hustle

Building a product from scratch is tough. We had to sift through tons of data and present it clearly. We understood that not every metric matters; only show what's useful and actionable.

Our goal was straight-forward?
Build something our past engineer-selves would find sensible.

Building the right team was crucial, and a continuous effort. Big lessons in leadership, team dynamics, and company culture were learnt. Turns out, NERF was the answer to almost everything. 😂 jk, jk.
Growing a company meant dealing with finances, marketing, compliances, and of course customers. It was a huge learning curve beyond my Uber days.

Reflecting on this journey, I can confidently say it was tough but gratifying. Building something meaningful outweighs the comfort I left at Uber, yet it would have been a LOT MORE DIFFICULT without the support from my wife, Mehak.

And yes, I'd do it again in a heartbeat. 💗

Psst.
If you want to check out what we've been building, here you go. It'll mean a LOT to me if you could leave a star on the repo. 😄

middlewarehq / middleware

✨ Open-source DORA metrics platform for engineering teams ✨

Open-source engineering management that unlocks developer potential

Introduction

Middleware is an open-source tool designed to help engineering leaders measure and analyze the effectiveness of their teams using the DORA metrics. The DORA metrics are a set of four key values that provide insights into software delivery performance and operational efficiency.

They are:

Deployment Frequency: The frequency of code deployments to production or an operational environment.
Lead Time for Changes: The time it takes for a commit to make it into production.
Mean Time to Restore: The time it takes to restore service after an incident or failure.
Change Failure Rate: The percentage of deployments that result in failures or require remediation.

Table of Contents

Middleware - Open Source

6 ways to turn your browser into super-debug-hero (ft. node.js + next.js!)

Jayant Bhawal — Wed, 03 Jul 2024 16:10:36 +0000

Unlike some of my other posts, this one is going to be straight-forward.

I'll cover some of the less-frequently-used browser devtools features that I've used over my career.

Some basic things are excluded, so as to not completely waste your time.
Things such as using “console.log”, editing CSS in the styles panel, editing HTML in the Elements tab, $0 element reference, etc.

1. Breakpoints! [🔝]

My goodness this was the first debugging thing that blew my mind about why debuggers are actually useful.

The idea is simple. Code, is written line-by-line.
When you’re trying to spot bugs, you’re following the flow of execution line by line.
Variables are assigned values, functions are called, loops run, etc. which all reads or writes data from places.

You’ll find this thing in the SOURCES tab in DevTools.

And by placing breakpoints you can see the state of your code, and the data contained within to understand how your code is actually running.
Makes it a lot easier to find bugs! It’s a LOT faster than placing a million console.logs everywhere. You can even modify the values in memory at your breakpoint!

It’s literally as simple as double-clicking a value to change it! (in most cases)

For further reading: Pause your code with breakpoints | Chrome DevTools | Chrome for Developers

2. Performance Profiling [🔝]

“Why does this action take longer than it should? It’s not like I’m making any API calls here.”

Code (sometimes) works in mysterious ways.
Obviously it shouldn’t, but often you’ll find yourself in legacy codebases, or just repos that became a bit of a mess over time. Features or actions that should seem super straight-forward in how they work, somehow end up causing a lag on the UI, trigger re-renders, multiple API calls, or what not.

When you run into situations where user interactions (not async stuff) aren’t happening “near-instantly” on the UI, you’re probably putting the CPU under too much load.

Examples when this could happen:

Modifying a large list of items
Calculating some stats from a dataset, on the browser
Complex map/filter/reduce usages
Browser-side search over a dataset

One option is to understand where that “blocked time” is being spent.
Presenting, the “Performance Profiler”! Present in the “Performance” tab in your devtools! (who could have guessed?)

You’ve already seen the screenshot above, but did you know you could also set up limits on how fast your CPU should be, and how many cores can it used at the same time?

You can also open the "Sources" panel to literally look at the source files to understand exactly which lines all this time is being spent.

Unfortunately, if you have an intermediate build step, like webpack, rollup, etc. this feature might not be that directly useful, since your JS code would be “compiled” (or “transpiled” if you prefer calling it that) into something that looks pretty different.

Look at it! I clearly have some recursive call issues combined with some CPU heavy logic going on. And because of the “Sources” panel above, I can see it’s happening because I created a pretty large for loop just for the sake of this example. 😄

3. Responsive Mode (aka. Device Mode) [🔝]

There’s a 99.8765% chance you know what this is.
Most of the internet traffic comes from Mobile devices now. There’s no way you haven’t resized your browser window a million times to see how it looks on different devices.

But responsive mode is a lot more configurable than most people are aware of.
Generally people stick to the device presets. It’s a dropdown that looks kinda like this:

However, it often feels insufficient to tell you how to actually see how comprehensive your media-query handling is, what breakpoints your web-app uses, and just leaves it kinda complicated to understand how your app will work on all kinds of devices…
Again, I’m talking about what happens if you stick to only the presets.

Unlocking the full potential of “Responsive Mode”

See the small 3-dot menu at the top when you enable “Responsive Mode”?
Once you open that menu, just “show” all kinds of things that it lets you enable.
And finally, set the Dimensions dropdown value to Responsive.

This is what you can do now:

Media Queries
It’ll show you what media queries are used in your web-app. Clicking on them will resize the viewport to the selected width. I’m unsure if there’s a way to do this with height as well, but if you know, please leave a comment. 😃

Rulers
No guessing what your current viewport width is. A nice ruler along both axes tells you… well… exactly what you expect it to tell you.

Device Pixel Ratio
This is something that wouldn’t really bother you in your day-to-day, because the browser kinda automatically handles it.
But what this option is, is how many hardware pixels are needed to render a single software pixel.
Sorry, I won’t go too deep into that topic in this post, but MDN has you covered:
Window: devicePixelRatio property - Web APIs | MDN

This property particularly becomes relevant when you’re using the HTML Canvas for something.

Device Type
This is more of a useragent type thing. Changing this value tells the target server/website what kind of a device is the page being accessed from, and whether that device supports touch or not.

Various sites handle UIs for web and mobile very differently.

You can even resize it very conveniently without having to resize the whole window, by dragging the corner at the bottom-right.

4. Lighthouse (and Core Web Vitals) [🔝]

In case you missed it, Lighthouse is a tool to inform you about the overall “quality” of your webpage. You could NEVER guess what tab you’ll find this under. (Hint: It rhymes with Bright-house)

What’s covered under quality?

Page loading performance and experience
Accessibility of the page for people with certain restrictions
SEO (aka. how well it might show up in search results)
And other “best practices” stuff

The general idea is, the higher your lighthouse score is, the better:

The experience of your users will be
The visibility on search results will be

Better visibility + More users == Money (usually)
So, it might be important to you.

Lighthouse an give you pretty comprehensive data on how you can improve your page even further!

5. Layers Inspector [🔝]

“Why does my modal show up on top of this tooltip?”
“Why does this button show up on top of this overlay?”
Layers Inspector is one of the coolest looking features in your browser, that allows you to:

See the stacking context of your elements
Understand if there are elements unintentionally rendered under or over other elements
Identify performance issues in certain layers
View elements that may be getting partly or wholly rendered off-screen
And most importantly… Feel super cool about your work. I mean… look at this thing!

P.S.: Edge calls it 3D View, but it’s a slightly differently functioning feature as well that still achieves many of the same things.

Story-time:

Most recently we realized that our product landing page had a bug where each individual image and the menu item was rendered twice, exactly stacked on top of each other in a way that visually you couldn't tell anything was wrong.

I was investigating something in the menu that looked off as a result because I was introducing some transparency styling which made the menu look weird.

Decided to Cmd+Shift+C and check the element styles. Nothing particularly off. But I noticed that there were two instances of that element.

Now I decided to check the Layers Inspector, and wouldn't you look at that! Our static site builder caused there to be duplicate instances of a lot of other images too! Thanks layers!

6. Console.notJustLog [🔝]

Did you know…
console.log is such a 2015 way of debugging at this point?

There are a LOT of things that the console object allows you to do.
Here’s a screenshot of all the things included within it!

tl;dr: Go read this: console - Web APIs | MDN

I’m going to cover my top 5 features under console.

1. console.table is nuts!
This is hands down one of the nicest ways to visualize most kinds of basic objects. It kinda doesn’t work too well when it comes to deeply nested objects, but, you know, for most objects it works fine enough!

2. console.group helps with limiting logging overload for your eyes
Okay, no one is getting rid of console.log. But there are times when you might need to log a few too many things, and then the actually useful information starts to get lost in a sea of other not-so-useful logs.
console.group allows you to nest your logs within groups that may be multiple levels deep!

P.S.: There’s also console.groupCollapsed if you don’t want your groups to be open by default.

3. console.assert for conditional logging
If you’ve ever done something like:



if (mycondition) console.log('Log stuff')

You could make use of console.assert instead.

It only logs when the first argument is false.

4. console.count for “incremental” logging
Ever felt the need to check how many times a certain function got invoked, or just some logic ran, maybe understand how often a certain useEffect got triggered?
Here you go.

You don’t have to pass it a static string like count label either.
Pass it something like user.id or whatever is stored in your objects or variables, and you’ll see how many times your logic runs with those specific values.

For example, how many times did my useEffect get triggered while the user ID was 1001-1234? That’s something you can answer with console.count(user.id) instead!

5. console.trace to understand how your functions get called
Functions. They can get called anywhere, and everywhere.
Sometimes it can be confusing to understand how a specific function actually gets called. Where it gets called from. This is going to be helpful for that.

BONUS: console.log. With *flair!*
Sometimes the plain-old plain-text just isn’t enough for your needs… for those times, you have this:



console.log('%cRed Text', 'color: red;');
console.log('%cGreen Text', 'color: green;');
console.log('%cBlue Text with Larger Font', 'color: blue; font-size: 18px;');
console.log('%cStyled Text', 'color: white; background-color: black; padding: 2px;');

[BONUS] 7. Node.js Debugging, in Chrome?! [🔝]

You can do it for both Javascript AND Typescript files!
“What? Really? I had no idea!! But how is that even possible?!?”
Okay, too much, I know.
If this is already familiar with you, I would love to hear how YOU use node.js debugging in your browser, and if there’s an awesome new idea that I didn’t know about, I’ll add it to the post! (attributed to you of-course)

But for a lot of folks that don’t know that this is possible, here you go…

Start your node server using the --inspect flag. node --inspect index.js
1. If you’re using tsx by any chance, it works in the same way. tsx --inspect index.tsx
Go to chrome://inspect/#devices. If you’re on a chromium based browser (edge, brave, arc), this URL should work.
1. You should see something like this.
2. Click on inspect
3. You should see a new window open that looks something like this:
  - You’ll notice that I was able to print the value of process object.
  - That’s because this instance of devtools is running in the context of node.js

That’s it!
Just like how you can debug browser side code, you an also debug server side code with this.

Look at me placing a debugger and all!
Note: See the two xmas.ts and utils.ts files? One of each of those is a “sourcemap” file.
Curious about what THAT project is? Check it out!
jayantbh/xmas-cli: Christmas tree generator

[BONUS/2!] 8. Next.js Server Side debugging?! [🔝]

Oh yeah! You can use all the capabilities of your Chrome Devtools to debug your Next.js applications server side logic. And it’s as simple as 1, 2, 3!

Pre-requisites: You have a nextjs app set up locally and all packages installed.

Run NODE_OPTIONS='--inspect' yarn dev or NODE_OPTIONS='--inspect' npm run dev
- Wait till the logs say something like: Debugger listening on ws://127.0.0.1:9230/3473fa37-03ec-4dc9-9769-3fd97998f0b7 For help, see: https://nodejs.org/en/docs/inspector
Go to chrome://inspect/#devices and inspect the target that represents your app
- You might see something like this:
- In this case, the one with next/dist/server/lib/start-server.js is the one I need to inspect
- An instance of DevTools will open.
Load your app! Go to localhost:3000 or whatever you app is supposed to load on. That’s it!
- At the start you might not see any files related to your app in the sources panel, but as you load parts of your app, it’ll begin to show up in devtools.
- Once it does, you can place breakpoints, see in-memory values, change things, etc!

Hope you found this useful. 🎉
I would love to hear other awesome ways you use your browser as the worlds greatest debugger, client-side or server side, in the comments! 😃

🙅 Why I don't use AI as my copilot 🤖

Jayant Bhawal — Fri, 14 Jun 2024 20:08:54 +0000

Jesus, take the wheel. 🚗
And Github Copilot, take the IDE. 💻

Github says, 92% of US devs are using Copilot.
What. Seriously?!
When did you hear 92% of any demographic using a singular thing?

Unless of course... you say 100% of all people who ever existed, consumed di-hydrogen monoxide.
(There's exactly one way this line gets dark. Don't go there. 👀)

Join me on a quick journey as I talk about:

What my fears actually are.
How other experienced devs feel about this.
Maybe I'm worried about nothing?
And how WE are responsible for how we use LLMs!

🔥 When the machines took over the world in 2024

After a quick Google search, it seems like most devs are using AI assistance in writing code. I’d be lying if I said I haven’t used AI to write code at all. Of course, I have. I don’t live under a rock.

I've seen devs get oddly comfortable with the idea of sharing their code related data with third party cloud services, which are often not SOC2 (or something similar) certified, and make vague unprovable claims of privacy at best.

Things like Github Copilot (and Copilot chat), Bito.ai, and several other AI code extensions on the VS Code marketplace have more than 30 million installs. Crazy! 🤯

And then there's me. I’ve not made AI assistance a part of my regular code workflow. A couple of times I’ve taken help from GPT to get some boilerplate written, sure. But those times are an exception. Things like Github Copilot, or any kind of code review, code generation tool, PR creation, or commit-assistance, isn’t a part of my IDE or CLI flow.

Maybe it’ll change with time. We’ll see.

“But… why?”

😟 What I'm ACTUALLY worried about

The answer is simple. 👇

1. I fear my programming skills will get rusty

I am concerned that the way I write and read code will suffer if I get too used to AI assistance.

I’m concerned I’ll begin to overlook flaws in code that I can catch otherwise.
That I’ll start to take AI generated code for granted.
And looking up APIs, built-in methods, or other documentation will start to feel like a chore.

I fear… that I’ll start slipping.

2. I'm not comfortable enough with sharing all of my code with a third party service

Companies can be damn smart about inferring things from the data you provide. Sometimes they'll know about things that your family won't know about.

The idea that sensitive business logic may get leaked to a third party service, which may eventually be used to make inferences I'm not comfortable with or just... straight-up leak? I mean, software gets hacked all the time.

I think I'm being very reasonable thinking that I don't want to expose something as sensitive as code in an unrestricted manner to a third party company. Even if that company is Microsoft, because even they f*ck up.

👀 From the Experienced Devs' point of view

This isn’t a take that is unique to me either!

1. More-experienced devs tend to not want to lean on “crutches” to write their code.

I’ve even had the pleasure to work with senior devs who didn’t want to use colored themes on their IDEs because they thought it’ll hurt their ability to scan, read, or debug code! (that was a bit much for me too)

After all, “programming skills” is a lot more than just writing code.

2. Older devs have seen all kinds of software get hacked, data leaked, etc.

I mean, when haveibeenpwned.com sends you emails about your credentials, emails, and other data leaks every year for over 10 years... MANY TIMES from billion dollar corporations...
When you hear "When you're not paying for the product, you are the product" for the bazillionth time, which is then backed by yet another company selling that data to some third party...

Yeah... it gets tiring.
And it gets real easy to just disconnect as many wires as you can and go back to stone age.

“Older devs”? Am I… Am I getting old?
Nah, I’m still 22 and this is 2016 or something… right? Right??

Btw, the answer to the question in the title is 👆 this. Congrats! The post is over! Over to the next one…

Buuuuut… if you want to continue reading…

🚶 Let's take a step back for a moment...

I think my fears may be exaggerated.

Let's keep the whole data privacy angle aside for now, because that's a whole other topic on it's own that I feel about rather passionately.

I personally don’t have enough data to empirically say that using AI assistance will bring about the doom I fear… That it’ll downgrade me from what I am today, to an SDE1.

But I’ve seen patterns.

I’ve seen AI-generated sub-par quality code go through code reviews and end up on the main branch.
I’ve seen library functions being used without properly understanding what, or what alternatives exist just because an LLM generated that.
I’ve even seen code generated to solve a problem, for which a utility function already existed in the codebase but wasn’t used because knowing this utility existed was a lot more work than asking GPT to generate it for you.

💎 Diamonds are Bad code is forever

“Wait a damn minute… I’ve seen this movie before!”

LLMs are a pretty new thing… but 💩 code has been eternal!
Every. Single. Dev. Ever. Has used library functions without fully understanding it or looking at alternatives. You, and me, are both guilty of that. (What? You thought Array.prototype.sort was the best way to sort anything? It’s just sufficient in most cases!)
A piece of logic gets reinvented (re-copy-pasted) all the damn time! Just that before it used to be from StackOverflow, now it’s from ChatGPT.

🤷 So, what’s the big fuss about?

"Will using ChatGPT make me a bad programmer?"

I think, no.

The takeaway is that you just need to care about what you build.
Take pride in what you build.

🤖 Where the heck does LLM/AI fit in?

LLMs are not inherently evil.
In fact, they can be pretty damn useful if used responsibly:

Quality Code: An LLM might handle edge-cases that a less diligent developer wouldn’t consider.
Comprehensive Tests: LLMs might write tests that are more comprehensive than what some devs would produce.
Comprehensive Types: It might even write types more "completely" than an average dev might write on their own, or might have the skill to write.

However, the responsibility lies with the developer to ensure that the code output is guarded and well-monitored. Someone who doesn’t care would have done a shoddy job at any point in history. The presence of LLMs doesn’t change that.

😎 The art of actually giving a f*ck

There's a lot of devs out there who don't care.
But you’re no such dev. You DO care.
Else you wouldn’t be here on dev.to learning from people’s experiences.

I recently wrote about what new devs should care about to grow in their career. It’s a LOT MORE than just code.

Going from SDE1 to SDE2, and beyond! 🚀 What it actually takes.

Jayant Bhawal for Middleware ・ Jun 10

Maybe I’ll introduce some AI in my VSCode.
I think it’s a matter of when, instead of if.

What’s more important is… as long as I care about making sure my programming output is readable, performant, high quality, and easily reviewable, I think I’ll be fine, and so will you.

👇 P.S.

If you want an example of something I care deeply about, and has both great code 💪 and… less than excellent code 🤣, take a look at our open-source repo!

It’s something that lets you spot how long it takes for you to deliver your code, how many times PRs get stuck in a review loop, and just generally how great your team ships code.

middlewarehq / middleware

✨ Open-source DORA metrics platform for engineering teams ✨

Open-source engineering management that unlocks developer potential

Introduction

They are:

Deployment Frequency: The frequency of code deployments to production or an operational environment.
Lead Time for Changes: The time it takes for a commit to make it into production.
Mean Time to Restore: The time it takes to restore service after an incident or failure.
Change Failure Rate: The percentage of deployments that result in failures or require remediation.

Table of Contents

Middleware - Open Source

You can't grow in your career without feedback. 🗣️ Here's 5 ways for you to find some 📝

Jayant Bhawal — Wed, 12 Jun 2024 17:36:55 +0000

"This guy has 10 years of experience, but he works like a 4YOE one?"
"How do I talk to my manager about how I'm doing?"
"I don't know if I'm growing sufficiently in my career!"

Ever said or wondered these things? Then you're in the right place.

There are tons of people out there who have worked since so long... Yet somehow there's not much of a difference between how they work and what they ship, compared to someone with much lower years of experience.

It's because it's not the number of years you've worked that shows how far you've come. But the distance you've covered.

"Ooh that's deep."
Yes, I know. Thanks. 😂

Devs find it easy to write code. To zone into a problem and focus on fixing that to the best of their ability.
Best of their ability.
THEIR ABILITY.

Where does "their ability" even come from?

It comes from the learnings and growth they've acquired over the years. It comes from working with others to see what they do better, or do differently and why. It comes from receiving feedback on the work they do themselves, learning what they did well, what they could do better, why, and how.

You could totally work in a silo, but unless you're an exception genius of some sort (or even if you are), you'll benefit a lot from obtaining feedback from those you work with.

"Ah. I see. I'm ready for some feedback. But... how?"

Well, that's why you're here, aren't you?
Let's go.

1. Not all feedback is useful feedback.

Funny how before I'm sharing how to get feedback, I'm sharing how NOT to get feedback. Or more like, how to ensure you have good feedback.

Everyone loves sharing their experiences and opinions as solid fact. They love to act like their way is the best way, and sometimes the only way of doing things.
If you ask around, you'll find people passionately defending their stance on whether a Pull Request should be merged via Merge Commits, Squashing, or Rebasing or something else. But these opinions are often not backed by sufficient or sound reasoning.

Some examples of such feedback might be:

Don't use this library, write a util function instead.
All your changes must have tests.
Don't use list-comprehension. Use lambda functions instead.
Write your commits in this following structure.

I'm not saying this is BAD feedback. Maybe it isn't. But without elaborating further you wouldn't know. And it is common for especially new devs or introverts to NOT ask further questions.

When you request or are provided with feedback, whether it is on your code reviews, task completion, planning, collaboration, etc. Always ask, "why?" (in an appropriate tone and politely of course).

For each of the above pieces of feedback, here are some questions you might ask:

What risks do we face by using this library? It's open source, actively maintained, has a lot of stars. All good signs right?
ALL my changes need to have tests? Why? That feels overkill and might cause my tasks to be delayed.
But list-comprehension feels like a perfectly understandable way to write this code. I feel it's not really compromising readability either. Could you explain why I should be using lambda functions instead?
Could you help me understand why I need to write my commits in this specific way? What problems might we face if I do XYZ instead?

When offered with some feedback, you absolutely need to understand why that feedback is valuable and applicable to you.

Either convince, or get convinced.

2. Don't wait for it. Ask for it.

Everyone has their own jobs to do, and sharing feedback often feels like something you have to go out of your way to do.

Well, you can't wait for it forever. Every month that passes by without feedback, you might be ingraining the "bad practices" harder. Doing things in a worse way without knowing. Not doing something that might benefit you significantly for low effort.

You'll figure most of it out eventually, often the hard way. But that's also a slower growth path.

Ask your managers and some of your peers for feedback, between once a month and once a quarter. Learn how they feel about working with you. What can you do better as a teammate? As a dev? As an employee of the org?

If your org already does regular review cycles, then you might not need to do this manually. But in most orgs, the review cycles are either insufficient, or non-existent.

1:1s are a great way to get some regular feedback from your managers, and they are more commonly done between 1-2 times a month. But again, 1:1s aren't done very constructively in way too many places. If you've ever felt like skipping a 1:1, then you're a victim of poorly structured 1:1s. Maybe I'll write about that too soon.

3. Know where you want to go.

Most people have ambition. They want to be someone big, build big things, make big money, etc. And that's cool, obviously there's nothing wrong with that.

But whatever your goals are, have some level of clarity about them.
You don't need to have your whole life planned down to the moment. But you should know who you want to be and what you want to be doing in 5 years, and then 10.

Why is this important?
Because you'll receive all kinds of feedback, and people share feedback based on the things that are important to THEM.

Someone who intends to be a staff engineer someday might be highly focused on code/architecture/performance related feedback of your work. But if you intend to be a manager 5 years down the line, the more relevant feedback for you would be related to planning, collaboration, and high level design to some degree.

My last blog post might be relevant for SDE1/2's looking to grow in their careers:

Going from SDE1 to SDE2, and beyond! 🚀 What it actually takes.

Jayant Bhawal for Middleware ・ Jun 10

4. If you can't act on feedback, you might as well never have received it.

This means two things.

There's simply nothing you can or want to do about the feedback you received.
It isn't obvious, or you don't know how to can act on the feedback.
You straight-up forgot past feedback, or didn't make a plan of action.

If any of this is true, you need to do something about it.

Let's start with feedback that is clear to you.

If you know where you need to go, you know which feedback is going to be relevant, and if you don't actively act on such feedback then you're not really going to go anywhere.

Track the feedback somewhere.
It can be a spreadsheet, a document, some To-do app, or just a notes app. Log it down.

For each feedback item that you choose to track, you want to log the the following along with it:

When was this shared
What personal goal does it relate to
When do you want to see the results of this

For example, if someone shared feedback with me stating that I should be more involved in the planning phase of new features, then I might log it down like:

Feedback item	Goal	Shared	Target	Done
Actively participate in one feature planing phase	Being an EM	10 May	31 Jul	✅
Actively participate in 3 feature planning phases	Being an EM	10 May	30 Sep

Coming to feedback that isn't obvious to you, either in terms of how you can act on it, or what the feedback actually means.

Well, your only course of action here is to ask.
Ask for clarification on that feedback.
Ask for help with how you can work on it.

I understand depending on your work environment and culture, asking questions isn't always easy.
It's cool that you can often ask Google, or GPT about these things now, to some degree of success.

But... this highlights the last part, and a hard decision to make when it comes to feedback (or your career generally).

5. My work environment is straight-up not conducive for feedback.

I'm not going to pretend the whole world is utopian. There are places where your peers suck, your bosses suck, and everyone is too occupied in their own lives to care about you. After all, for someone to share meaningful feedback with you, they have to care about you in at least a professional capacity.

In such a scenario, maybe an option is to just... leave?

You should be at a job if you're getting at least 1 of the following:

Growth (personal/professional)
Money
Recognition

There isn't a "right answer" here. The right answer is whatever you deem to be right.
Feedback can play a crucial role in any, or even all of these, if acted upon properly.

But if there's no feedback, and you see no other reasonably fast path to any of this, then don't remain stuck. Keep moving. Keep growing. This post was basically about growing in your career. Feedback is one of the most useful tools as your disposal.
Seek it out. Use it.

⛳️ Some background on this post:
At this point I've worked at all kinds of places that have dealt with feedback in their own ways. Some made feedback a structured and regular thing, some others made it a more ad-hoc and casual thing, and sometimes there was hardly any feedback till it's been late.

Having deeply learnt the importance of feedback for myself and my peers the hard way, I decided to make sure there was a process and cadence to this chaos. I wouldn't say I practice this perfectly, else my team will have something to say about that. 🤣 But I'm sure they'll agree that we do a bunch of things right when it comes to feedback, and making sure they have a direction in which they can act in.

We at Middleware leverage feedback culture heavily! Make sure we have clearly set expectations from our roles, and are actively communicating differences and feedback clearly.

If this was interesting to you, you could check this post out, which was also linked above:

Going from SDE1 to SDE2, and beyond! 🚀 What it actually takes.

Jayant Bhawal for Middleware ・ Jun 10

#codereview #productivity #learning #testing

Going from SDE1 to SDE2, and beyond! 🚀 What it actually takes.

Jayant Bhawal — Mon, 10 Jun 2024 11:10:21 +0000

"I'm good at writing code. Just this month I shipped 11 PRs! I even updated most of my tickets on time. Didn't take that many leaves either! And I worked so many more hours than Sam, too! Why didn't I get promoted but they did?"

-- Some unfortunate person who didn't get the promo this time.

Does that sound relatable by any chance?

I've seen this before.

A LOT.

Sometimes the reason is office politics. 🤬

Sometimes it's simply expectations not being communicated well. That can suck. 🥲

Sometimes it's a mismatch between how you stood up to the defined expectations, and where the bar actually was. 🤔

You may not be able to control or change what your office environment is like. But you're certainly in control to ensure there's nothing on your end that prevents you from rising up the career ladder.

Cool! Could you speed-run me through what I need to do?

The first thing is to know what your responsibilities are as a software developer. I don't mean your responsibilities in your current org, I mean it as a holistic and individual dev.

I see there's 5 broad areas that a dev should aim to cover.
Click on the links to jump to that section.

Technical (code quality, lang. proficiency, testing, perf.)
Productivity (reliability & efficiency)
Collaboration (communications & reviews)
Ownership (responsibility & initiative)
Impact (system/product improvements & innovation)

"With that, we're halfway to making a D&D character sheet. Roll Nat 20! 🤣"

I'm going to only cover things that ARE in YOUR CONTROL.

I'm specifically mentioning this because one thing I've seen many orgs get wrong is, various areas of evaluation end up including things that you may not have control over.

Such as, you may not have control over how impactful your work was to the company. In most cases, you'll only get to work on the things you've been directly asked to do.

Alright! Let's go! I'm ready to get promoted!💰💰

The 5 areas I mentioned above aren't specific to SDE1's. It's something every dev needs to be on top of. But the bar and expectations from each of those areas change.

Let's talk about what the baseline expectation is from each area, and what you need to do to get to the next level.

Hold your horses. This is going to be long.
But remember, there's only 5 sections below... 👇

1. Technical Skills [🔝]

At SDE1, no one expects you to make a major splash, change the world, save billions!
They expect you to do your job in a way that needs minimal, or at-best occasional hand-holding, and for your delivered work to not need revisiting or fixes (as far as reasonable).

tl;dr
Write decent code that others can read, and doesn't break every 2 seconds.

There's a few ways to do that.

Write dumb code. Not "smart" code.

You might be the wizard of Leetcode, Hackerrank, or something similar. But unfortunately these sites encourage juniors to pursue performance so hard that it often comes at a cost of readability.
It's NOT a bad idea to use a nested loop, if you know both loops run only for small values of i and j.
It's NOT a bad idea to NOT use a map/dict instead of an array if that array is guaranteed to only have a few items at max.

Learn about all the tools the language offers you.

You might be used to using for-loops for everything, but arrow/lambda functions could make your code a lot more readable.
[JS example] you might be used to storing things in an object {} for O(1) lookup every time, but set.has(thing) is a lot easier to read than !!obj[thing] (or even Boolean(obj[thing])

Understand why tests are valuable, and THEN write tests

Too often people just write tests because it's a "best practice".
Without understanding the WHY behind it, you may write ineffective or pointless tests.
The idea is, do whatever you need to, to increase confidence in the stability of your code. You need to use types? Sure. You need to hire a QA person? A bit inefficient, but cool. Maybe you need to write... TESTS? Okay, but... what do I aim for?
This can be a separate blog on its own. But here's a quick brief...
- It doesn't matter whether you need to write Unit tests, Integration tests, Acceptance tests, whatever you call them. People can get "religious" about it. But none of it matters as long as your test does the one fundamental thing... improves your confidence that your code will not break.
- Sometimes you may need to refactor your code so it's more testable, but once you do it a few times you'll begin thinking about code from a testability point of view.
- It's also a great idea to write the tests for your expected implementation before you've implemented anything at all! Resulting in a testing suite that completely fails at the start, and as you've implemented things it gradually keeps passing! This is basically what Test Driven Development (TDD) is btw.

Care about performance

No one's expecting you to run everything at 60 FPS all the time or sub 100ms latency for everything.
But be mindful of when your code may cause too many requests to the DB, or loads too much data. Don't let your component render 5 times because you couldn't figure out how to use useEffect and useState right. Ask for help where you need to, but care enough to not let this stuff reach production.

⏫ To get to SDE2:

Dive deeper into the internals of the languages and frameworks you use. 🧠 Know how React actually renders things. Understand how a browser handles multiple requests from the browser to a server. Learn how Postgres chooses to optimize a query or doesn't. Get into how your applications deployment pipeline is configured.
Ask questions about how the project, components, APIs, etc. were architected the way they were. Learn what these design patterns are called, and what their pros and cons are. Start contributing to architectural discussions and suggest improvements. Who knows? You might have ideas that more experienced people didn't consider.
Mentor others on best coding practices. You will often have people junior than you on the team. Review their code. Get your code reviewed by them and share what they should focus on. Like Yoda, your wisdom you should share. 🧠

2. Productivity [🔝]

As an SDE1, your productivity is measured by your ability to reliably complete tasks on time, manage your workload efficiently, and maintain consistent progress on your projects. You should also be able to handle minor disruptions and dependencies without losing focus or needing constant guidance.

You may often need to rely on tools or apps or scripts to do certain things more effectively. Sometimes you may need to MAKE these tools yourself.

It's okay if this feels like too much. It won't always be perfect. Even far more senior devs don't always nail this down.
You'll get there. The important part is, if you're not able to live upto your commitments, then communicate as early as you can.

tl;dr
Aim to get your tasks done well and on time. When you feel that you can't, let people know asap.

Know when do to what, and when to say NO 🙅

Learn to distinguish between what's urgent and what's important. Use tools like Eisenhower Matrix to prioritize effectively.
Focus on high-impact tasks, but don't ignore the small ones that keep the wheels turning.
LEARN TO SAY NO. Oh goodness this is a BIG one. This is so important that this could be a blog on its own. I got stories.
- You'll occasionally find yourself being overloaded with work if you're not good at saying no. People will often find it acceptable if you can simply and clearly explain what you're occupied with, and instead when you'll be able to pick up the next thing.
- If you find yourself pressured into a corner, you NEED to rely on your manager to prioritize things for you. Just ask them what's most important according to them. You saw this one coming, didn't you?

Manage your time, and don't burn yourself out

Use techniques like Pomodoro to maintain productivity without burning out. I've had many friends that use some kind of a digital or physical Pomodoro timer to manage their workday.
Track your time on different tasks to understand where you might be spending too much or too little time. A common pomodoro timer used by my friends back in the day

Automate boring work, by making your own tools if you must

Automate repetitive tasks to save time. Scripts and tools can handle a lot of the mundane stuff. I've created a whole bunch of scripts, Slack commands for internal debugging, etc. that has saved me and the team countless hours already at Middleware.
Familiarize yourself with IDE shortcuts, plugins, and other tools that can speed up your development process. If a majority of your team uses VSCode for dev, you can even agree on a common IDE config, and share that for that codebase by committing the .vscode directory to the repo!

⏫ To get to SDE2:

Start managing your projects more independently. Create realistic timelines and meet them. An SDE1 might miss timelines every now and then. An SDE2, less so. The higher you go, the more likely it should be that you finish your projects before time even!
Proactively identify and address bottlenecks in your workflow. Suggest process improvements to the team. Often you may not get the time or support to implement such improvements. A solid SDE2+ move is to just do it yourself in the bits and pieces of time you find between other work, and suddenly one day the team has some key workflow pain-points magically resolved! All because of you.
Balance multiple projects and tasks without losing track of deadlines, and understand that you don't always just meet deadlines by working 28 hours a day, you figure out ways to do the same thing more efficiently. As such, show that you can handle increased responsibility with the same level of productivity. Level up your multitasking game like Tony Stark managing his suit tech! 🦾

3. Collaboration [🔝]

At SDE1, you need to communicate clearly, share your progress, and be a helpful team member. Your ability to collaborate effectively with others is crucial to the team's success.

There are a lot of people relying on you to deliver things on time. They are your engineering manager, product manager, perhaps other managers they report to, and also your peers who are waiting for your piece of the project to be done.

People may often be understanding of something running a little late, especially if it's informed as early as possible. But what really causes issues is:

Not telling you'll be late till the last minute.
Not being clear or being VERY inaccurate about your estimates.

I still mess up on some of this. But overall things do get better. 👌

tl;dr
Be a good teammate and communicate well.

Speak early, speak often, but most importantly - listen

Keep your team updated on your progress. Regular updates in stand-ups and via project management tools like Jira or Trello help everyone stay on the same page. (I know, Jira sucks, but you have to understand that it's a pretty decent tool for your managers and higher ups to keep track of how things are running.)
Listen actively during meetings and discussions. Understand what others are saying before you respond.
Being a good listener will also get you a girlfriend/boyfriend sooner 🤣. If you don't, let's hope you pass Rule 1 & 2. 👀

Guard your production, review the code

Participate actively in code reviews. Provide constructive feedback and be open to receiving it. Care deeply about not letting poorly readable, or potentially risky (perf., UX, or security-wise) code from ending up in prod.
Learn from the feedback you receive and apply it to your future work.

If you need any convincing about why code reviews are critical, and how to do it right, maybe this will help:

The Senior Engineer's Guide to Code Reviews

Jayant Bhawal for Middleware ・ Jun 3

Keep your team up-to-date with your learnings

Share what you learn with your team. Whether it's a new tool, a coding trick, or an interesting article, keeping your team informed helps everyone grow. If you're on Slack, a #engineering channel is a great place for something like this. So is #memes. 😄
Write documentation and create guides for complex parts of the codebase or processes. This helps others understand and use your work more effectively. It's SUPER IMPORTANT to remember that this documentation needs to be searchable. Documentation that can't be searched for, doesn't exist. Glean could be a great tool to help with that, but it's a paid (and expensive) thing.

⏫ To get to SDE2:

Take on a mentoring role. Help junior developers navigate their tasks and challenges. Help them plan, estimate, document, etc. Help them write their first ERDs (Engineering Requirements Document)!
Lead small projects or initiatives. Show that you can coordinate efforts and bring a team together to achieve common goals.
Facilitate communication within the team. Help resolve conflicts and ensure that everyone is heard. Every team has introverts, and it's usually them that have the hardest time communicating, help them as you can. Be the Captain America of your team, uniting and leading by example! 🛡️

4. Ownership [🔝]

Taking ownership means being responsible for your work and its impact. As an SDE1, this means you should ensure your code works as expected, handle your tasks diligently, and follow through on your commitments.

Just as a founder, or CEO must do whatever it takes to ensure the company survives, thrives, and is profitable, you must do whatever you gotta do to ensure that your work meets the timelines set upon in, and is delivered in a way that not just meets, but exceeds the bar.

Understandably, there may be times when the set timelines or expectations are simply unrealistic. That's where your communication skill needs to shine.

tl;dr
Own your work, and its quality. Finish what you start.

Maybe not like... THAT.

Learn to commit

If you commit to a task, see it through to completion. If you encounter obstacles, communicate them early.
Don’t pass the buck. If there's an issue with your code or task, work to fix it rather than blame others.

Be proactive: See something, do something

Don’t wait for problems to be assigned to you. If you see something that needs fixing, take the initiative to address it. Of course you'll need to prioritize appropriately. Not everything that needs fixing requires you to park whatever you're working on and fix it first either.
Think ahead. Anticipate potential issues and address them before they become problems. For technical or engineering related work, ERDs (Engineering Requirements Document) can help tremendously with your work planning.
Your managers may be keeping an eye on your teams productivity from their point of view, but as a proactive dev you can do the same. After all, YOU are the one who truly understands what makes YOU productive. If you can come up with a way your productivity analysis to your managers, show them that your team is actually doing well, or is blocked on things that need their attention, that gets you some serious points. DORA metrics is a fairly popular way to measure team productivity among dev teams. If you're not sure how to start measuring something like this, maybe this blog would help: What are DORA metrics?

Everyday, be better than you were the day before

Reflect on your work. What went well? What could have been better? Use this reflection to improve continuously. This would be a more personal version of the Sprint Retrospective your manager would (or should) do.
Seek feedback actively and apply it. Strive to be better with every project you undertake. Sharing feedback is also a lot of work for the one providing the feedback. It might be a good idea to block some time quarterly, monthly, etc. if your org doesn't have a process defined for this.
Try and follow the Boy Scouts rule, which basically states that you should leave a codebase better than you found it. Read more here.

⏫ To get to SDE2:

Drive projects from start to finish. Take on tasks that require you to plan, execute, and deliver with minimal supervision. If you prove yourself to be self-capable enough, your manager might let you supervise a couple more devs to execute the project. Now THAT is some Senior Dev stuff. 💪
Identify and implement improvements in processes, tools, or codebases. It's been mentioned before too, but here the focus is slightly different. Show that you’re looking out for the bigger picture and contributing to long-term success of the org.
Advocate for best practices and ensure they are followed. Be the Batman of your projects—reliable, vigilant, and always delivering excellence. 🦇

5. Impact [🔝]

As an SDE1, your impact might be limited to the tasks and projects assigned to you. However, demonstrating a broader understanding and contributing beyond your immediate responsibilities can set you apart. Impact is not just about what you do, but how your work influences and benefits your team, your project, and the organization as a whole.

tl;dr
Make a difference. Don’t just do, but improve.

Don't be limited to "your job"

Learn about the business and the industry you’re working in. Understand how your work fits into the larger goals of the company.
Identify opportunities for improvement or innovation. Suggest enhancements that could benefit the team or product.
Pay attention to the end-users of your product. Understanding their needs and pain points can guide you in making more impactful contributions. Don't just build whatever you're asked, but also analyze how successful your efforts have been for the users, and the org.

Contribute to the Community

Participate in internal and external developer communities. Attend meetups, contribute to open-source projects, or write technical blogs.
Share your knowledge and expertise to help others grow and learn. Organize or speak at tech talks, webinars, or coding bootcamps.
Engage with other teams within your organization. Offer help and collaborate on cross-functional projects to broaden your impact.

You may not be "asked" to help your community at your job 🤣

Be Proactive in Problem-Solving

Look beyond the immediate requirements of your tasks. Think about how your solutions can benefit other projects or future work.
Develop a habit of thinking critically about the tools and processes you use. Propose and implement improvements that can save time, reduce errors, or enhance performance.
Don’t wait for someone to assign you impactful work. Seek out opportunities to contribute meaningfully, even if it means stepping out of your comfort zone. Sometimes you may have to rely on third party tools to identify problems in your processes. Tools like Middleware would let you spot issues in your software delivery. Now THAT is a senior dev move.

middlewarehq / middleware

✨ Open-source DORA metrics platform for engineering teams ✨

Open-source engineering management that unlocks developer potential

Introduction

They are:

Deployment Frequency: The frequency of code deployments to production or an operational environment.
Lead Time for Changes: The time it takes for a commit to make it into production.
Mean Time to Restore: The time it takes to restore service after an incident or failure.
Change Failure Rate: The percentage of deployments that result in failures or require remediation.

Table of Contents

Middleware - Open Source

Innovate and Improve

Stay updated with the latest trends and technologies in your field. Experiment with new tools and approaches that could benefit your projects.
Think about scalability and maintainability in your work. Design systems and write code that can grow and evolve with the needs of the business.
Encourage a culture of innovation within your team. Promote brainstorming sessions and hackathons to generate new ideas and solutions.

⏫ To get to SDE2:

Start thinking strategically. Identify ways to make a significant impact on your team’s goals and the company's success. Look for patterns in your work and the work of your team, and suggest improvements that could benefit everyone. Most people aren't too good at this, so if you can pull this off it'll absolutely set you apart.
Lead initiatives that drive innovation and improvement. Show that you can think creatively and come up with effective solutions. This might involve proposing new features, optimizing existing systems, or improving development processes.
Champion new technologies or methodologies that can enhance productivity or quality. 🚀 Take the lead in integrating these technologies into your projects and mentoring others on their use.

Remember, levelling up from SDE1 to SDE2 and beyond is a journey. Focus on what you can control, seek feedback, and keep improving. Your growth as a developer is a combination of technical skills, productivity, collaboration, ownership, and impact. With dedication and effort, you'll not only level up but also enjoy the process of becoming a better engineer and a valuable team member. Game on! 🎮

P.S.: Senior engineers are good at identifying all kinds of problems that prevent their teams from delivering on time, without compromising on their output quality.

Some of them use tools like Middleware.

middlewarehq / middleware

✨ Open-source DORA metrics platform for engineering teams ✨

Open-source engineering management that unlocks developer potential

Introduction

They are:

Deployment Frequency: The frequency of code deployments to production or an operational environment.
Lead Time for Changes: The time it takes for a commit to make it into production.
Mean Time to Restore: The time it takes to restore service after an incident or failure.
Change Failure Rate: The percentage of deployments that result in failures or require remediation.

Table of Contents

Middleware - Open Source

#codereview #productivity #learning #testing

Not 💩, here's how to write actually good commit messages (hint: It's not just adding commit-lint)

Jayant Bhawal — Thu, 06 Jun 2024 10:01:04 +0000

Update build file
Fixes dependency array
Refactor
Fix tests
The most famous: Update README.md (Thanks Github 🤦)

These are... some spectacularly amazing commit messages that I've actually seen in the last month. 👀
And... some of these are in our codebases too.
A bit embarrassing. I know. 😅

But this is not okay 🙅, and ideally I would want to rid the world of these.

"Sure, whatever. I don't think anything will change even after reading this blog."

For anything to change, I need to convince you that:

This makes a real difference that YOU can feel or measure
This makes a difference to someone else (which might be attributed to you later)

"Okay, get on with it. What do I do, and what do I get from it?"

Well written commit messages have some obvious benefits:

1. 🧑‍💻 Easier debugging

git blame makes it super easy to understand why a change was introduced, and makes it easier to ask the author relevant questions about it.

git blame isn't the first tool that's used during debugging, but for complex issues related to business logic, it's a tool that comes into play especially in medium to large sized companies. Some code simply evokes the question "Why was it written the way it was?" or "What purpose was this originally solving?". The answers to some questions don't lie in engineering, but in product decisions. And the author who wrote that has the best chance of knowing what decisions were involved.

Of course, git blame will tell you the author of a commit even without the need for fancy messages. So why is this part of this blog post?

Because how often do YOU as an author remember what a commit that you write 6 months ago was doing? Especially when it has a commit message like "Refactor"? Tough luck right?

I've seen more experienced devs write exceptionally helpful commit messages. I think some of them overdid it a little, but here's a rough example:



Fix crash on login screen due to null pointer exception.

- Checks for null values before accessing user profile data
- Adds unit test to cover this scenario
- Issue linked: BUG-5678

Maybe it's a bit too much, but damn if it isn't obvious AF.
Now when I need to debug an issue in this area, being able to git blame for the author and context can be a lifesaver.
I say this with confidence because I used to be both on the giving and receiving side of this at Uber.

This has a serious added benefit which you might overestimate as you read this blog:

Saves time for you and your team, and reduces frustration

Debugging in the absence of context is PAIN. It's not even the kind where you can say "What doesn't kill you, makes you stronger." Because it just frustrates you.

You know it. Your team knows it. And that's why you try to understand who introduced "that bug" anyway and talk to them, only to find out they left the company 2 years ago. Good luck. 🤝

With this, you're leaving behind a legacy that would make people remember you fondly and wish they could work with you again.

"What if I use merge or squash commits?"

Some people have strong opinions for or against them.

All I'll say is, merge commits help to contain the context of a PR contained within a commit to a degree, but the individual commits themselves may not have much context associated with them if they are not well written.

And because a PR might involve a variety of dissimilar changes that work together to ship a feature, and the constituent changes might have their own context for being written that way, squashing them might effectively muddle all that context making it difficult to draw inference from the commit history.

But perfectly functional software is written either way. As long as you and your team agree that your way of merging PRs works for you with minimal issues, who I am I interfere?

2. 🔍 Easier code reviews

If your org doesn't care too much about making code reviews be painless and not make it feel like a chore, you need to share this with your people:

The Senior Engineer's Guide to Code Reviews

Jayant Bhawal for Middleware ・ Jun 3

Now, how do better commit messages help with code reviews?

From Middleware's analyzed data, an average PR in a mature codebase (active repo, past its setup phase) can be around 300 lines.

That's a lot of lines. And most of these changes are not happening in the same file. Neither should they. 300 lines is on the upper end of a file being readable (it's not a rule set in stone though).
It's a near-guarantee that different kinds of changes are being shipped in these PRs that NEED to go together for the desired functionality to be shipped.

If you can't make a smaller PR for any reason, you can make smaller commits in the same PR. Make each commit contain the smallest piece of logically isolated change, such that the commit message can sufficiently explain what it contains. Because you don't want to write a commit message that's a paragraph long either, you'll need to create a commit that's small enough that roughly 50-60 characters can explain what it's about.

Now, the reviewer can review your PR commit by commit without having to follow up with you for everything or wondering why something was written the way it was (if they do, they'll have to ask you [the author], you know? Do you really have much time for that?).

3. 🚀 Better release notes!

Or if you're not generating "release notes" exactly, then it's still better documentation of the history of your project!

Github, specifically, also allows you to generate release notes for your project automatically from your commits. And release notes are seen by a LOT of people to get an idea of what fixes or features new releases contain.

See the releases section of the React codebase, and see how many reactions each release note has!

Clearly release notes matter to people. And by writing well written commits, you're saving yourself effort from writing release notes.

And finally...

4. 👥 Encourages better practices across the team

When team members see the benefits of well-written commit messages, they are likely to follow suit. This can lead to a more disciplined approach to code commits across the entire team, encouraging a culture of clarity and precision. This is the kind of stuff that makes an SDE1 act think and act like an SDE2.

Going from SDE1 to SDE2, and beyond! 🚀 What it actually takes.

Jayant Bhawal for Middleware ・ Jun 10

Here's another example of such a commit:



Update permissions routing layer to handle subroutes independently.

- TKT-1234
- The permissions routing logic was previously coupled with its nested routes
- This change will allow you to move subroutes to any other parent route without also having to make any changes to how the permissions for that subroute are defined

In environments where multiple people work on the same project, consistent and detailed commit messages can align everyone's understanding and expectations, reducing potential conflicts and misunderstandings, without needing as much time to block for context sharing.

And of course, if you can be the champion of better commit messages in your team or organization, you'd love to get the credits for any benefits that brings, won't you? 👀

Teams that can work asynchronously, is a team that can work efficiently. No one wants your teams to have bottlenecks on stuff like this. 👌

UPDATE:
I really should have covered this earlier, but if you're convinced about the idea of using good commit messages and are using it in some form regularly, you might be ready to take the next step.

The next step would be to have a standard way and structure of writing commits in your org. Adhering to standards can involve a bit of a friction in your experience, but it can prove to be fruitful in the long term.

Presenting, Conventional Commits!
Thanks @taosif7 for reminding me of this!

conventional-commits / conventionalcommits.org

The conventional commits specification

ConventionalCommits.org

This repo is the home of the Conventional Commits specification.

Repo Layout

We use HUGO as static site generator, so we use the directory structure HUGO proposes.

Our implementation

./content: contains all the versions of the specification.
./content/next/: contains the version of the specification (where all the changes SHOULD be made).
./content/**/index.[lang].md: contains the content of the specification, if a language is specified it's a translation.

Contributing

We'd love your help refining the language of this specification, fixing typos, or adding more translations. Please don't hesitate to send a pull request.

Adding a translation

Create a new file in ./content/version/index.[lang].md using the hugo command hugo new [version]/index.[lang].md.
Ensure all files have the appropriate fields required (see others as an example)..
Add the language to the config.yaml file (see others as an example).

Running project locally

There's a docker-compose.yml file ready that will help you to…

Conventional Commits is a specification for writing great commits in a standardised way. There are many tools which rely on commits written following this spec which may be able to automate even more things for you in terms of release notes, feature updates, separation of commits/PRs by the nature of the work involved in them (such as refactors, chores, fixes, features, etc.).

It's absolutely the next thing you should at least give a look.

Wrapping this up

Good commit messages have serious GAINS. 💪
Gains for you, and the teams that you're a part of.

Less time spent debugging, fewer frustration moments, better documentation, automatic release notes, etc.

As a side-effect of all those improvements, you might even notice faster code deliveries, lesser wait time in reviews, fewer rework cycles!

Go on! Take credit for all the efficiency improvements you introduced!

And see exactly how much of a gain it was for your teams by using a productivity intelligence tool, such as Middleware! 🚀

middlewarehq / middleware

✨ Open-source DORA metrics platform for engineering teams ✨

Open-source engineering management that unlocks developer potential

Introduction

They are:

Deployment Frequency: The frequency of code deployments to production or an operational environment.
Lead Time for Changes: The time it takes for a commit to make it into production.
Mean Time to Restore: The time it takes to restore service after an incident or failure.
Change Failure Rate: The percentage of deployments that result in failures or require remediation.

Table of Contents

Middleware - Open Source

The Senior Engineer's Guide to Code Reviews

Jayant Bhawal — Mon, 03 Jun 2024 11:03:42 +0000

Code reviews.

You know how important they are.

They are one of the pillars of getting reliable code out there.

Yet, it’s one of those things you need to squeeze out some time for in your super busy days.

If you’re not reviewing code, you might as well ship landmines to your users because you never know when it’ll blow up. 🤷

Obviously, you know that. You’re not here to be told “Hey! You should have code reviews! It’s a vital thing!”

My team already does reviews. Why should I care?

Code reviews processes handled without care and diligence can have serious consequences.

At one of my previous orgs, code reviews were often not done thoroughly, and hence needed multiple passes. They were also done by reviewers on the opposite ends of the earth! 🌏

So addressing any comment took almost a whole day. And again, because the reviews would usually not be comprehensive the rework time on a PR would be in days for trivial things.

“You can’t improve, what you don’t measure”

Often attributed to Peter Drucker, but I’ve not been able to actually find evidence for that.

But it’s a statement I found to be profound in my experiences.

I’ve made a case to my leadership in the past to make much needed organizational changes to enable all teams to have fewer inter-dependencies across time-zones to enable people to collaborate faster.

I understand how difficult it can be to do so, but it’s even harder to get any change in motion without a solid data-backed reason for why it’s needed.

P.S.: That’s part of why Dhruv & I started Middleware. 🚀

middlewarehq / middleware

✨ Open-source DORA metrics platform for engineering teams ✨

Open-source engineering management that unlocks developer potential

Introduction

They are:

Deployment Frequency: The frequency of code deployments to production or an operational environment.
Lead Time for Changes: The time it takes for a commit to make it into production.
Mean Time to Restore: The time it takes to restore service after an incident or failure.
Change Failure Rate: The percentage of deployments that result in failures or require remediation.

Table of Contents

Middleware - Open Source