DEV Community: Adam Nathaniel Davis

Use Cases for IIFEs

Adam Nathaniel Davis — Wed, 13 Sep 2023 06:33:18 +0000

First, I'd like to lead this article with a confession:

Whenever I'm presented with a programming concept, I immediately start searching my brain for practical ways that I would use that concept. If I can't think of a practical application for that concept, I might technically "understand" it - but I'll never truly master it.

This can be a bit of a mental roadblock for me because someone says, "Hey, you should consider using [INSERT CONCEPT HERE]," and I nod and read a few basic articles about the concept. But unless I can envision a logical scenario where I'll use that concept, it just sits in the back of my brain, gathering dust, and doing me little good in daily programming endeavors.

For many years, the Immediately Invoked Function Expression (IIFE) was exactly this type of concept. Sure, I understood what an IIFE was. But they never really "clicked" for me because there was never any time when I thought, "Oh, wait. I should use an IIFE here!"

For whatever reason, I've actually started using IIFEs recently with some regularity. So I figured I'd write up this article because it might help others who've never really grasped their utility.

What is an IIFE?

The fully-articulated name of an IIFE basically tells you what it is. It's a function expression that's... immediately invoked. It differs from an anonymous function in that anonymous functions can still be called numerous times, like this:



[1,2,3].forEach(item => console.log(item))

In the example above, this is the anonymous function:



item => console.log(item)

It's "anonymous" because it's not stored in a variable. So it has no "handle" that we can use to manually call the function at other points in our code. But it's not an immediately invoked function expression because it's not run... immediately. Instead, it is run once for each item that's passed into the Array prototype function .forEach().

IIFEs have a special syntax that tells the JavaScript engine to run the logic inside them immediately after they're defined. That syntax looks like this:



const item = 1;
(() => console.log(item))()

In the example above, the IIFE will console-log the value of item (1). And that's fine, except... When I look at an example like the one shown above, the IIFE just feels utterly... pointless. I mean, if all you want to do is console-log the value of item, then why wouldn't you just do this?



const item = 1;
console.log(item);

Of course, for this (totally simplistic) example, there really is no logical reason to use an IIFE. And it's that basic bit of common sense that always led me to write off IIFEs as a near-pointless language construct.

To be clear, I've occasionally encountered IIFEs that were written by other devs. But sooooo many times, when I see IIFEs "in the wild", I still end up scratching my head as to why the original developer even chose to use it in the first place. My thinking went like this:

IIFEs are just a block of immediately-invoked code.
So if I want that code to be immediately-invoked, then why wouldn't I simply... write the code - without wrapping it inside an IIFE???

But as I stated above, I've found several scenarios where they can truly be useful. I hope that the following examples will help you to grasp their utility as they have for me.

Libraries

Let's say that you have a single file that contains a "library" of utility functions. That may look something like this:



// conversionUtilities.js
const convertUserDBToUI = userDB => {
  return {
    id: userDB.user_id,
    firstName: userDB.first_name,
    lastName: userDB.last_name,
  }
}

const convertUserUIToDB = userUI => {
  return {
    user_id: userUI.id,
    first_name: userUI.firstName,
    last_name: userUI.lastName,
  }
}

The functions above simply take objects that are formatted for the UI and converts them into objects that are formatted for the DB (and vice versa).

Of course, if these are truly meant to be "utility" functions (meaning that you'll probably need to call on them from various places throughout your application), you'll need to export these functions so they can be imported at other places in the app. That would look like this:



// conversionUtilities.js
export const convertUserDBToUI = userDB => {
  return {
    id: userDB.user_id,
    firstName: userDB.first_name,
    lastName: userDB.last_name,
  }
}

export const convertUserUIToDB = userUI => {
  return {
    user_id: userUI.id,
    first_name: userUI.firstName,
    last_name: userUI.lastName,
  }
}

The code above would work just fine. However, it may lead to some extraneous import statements throughout your code, because anytime you need to use two-or-more of these functions in a single file, you'll need to include two-or-more import statements in those files. When you're creating "library" files that contain many related utility functions, it can often be useful to have them contained within a single export.

One way you could accomplish this is with a class:



// conversionUtilities.js
export const Convert = class {
  userDBToUI(userDB) {
    return {
      id: userDB.user_id,
      firstName: userDB.first_name,
      lastName: userDB.last_name,
    }
  }

  userUIToDB(userUI) {
    return {
      user_id: userUI.id,
      first_name: userUI.firstName,
      last_name: userUI.lastName,
    }
  }
}

Once again, the code above works just fine. Here are some benefits of the above code:

We no longer need to repeat convert in every one of the method names, because it's implied in the name of the class.
All of our utility functions are "bundled" inside a single entity - the Convert class - so they don't need to be imported individually.

But there are also a few "downsides":

Some (nay... many) JS/TS developers simply abhor using the class keyword.
Anytime you need to use these utility functions, you first need to call something like const convert = new Convert(); before using the utility functions like const userUI = convert.userDBToUI(userDB);. That could become... cumbersome.

You could solve the second "problem" by exporting an instance of the class, rather than exporting the class itself. That would look like this:



// conversionUtilities.js
const Convert = class {
  userDBToUI(userDB) {
    return {
      id: userDB.user_id,
      firstName: userDB.first_name,
      lastName: userDB.last_name,
    }
  }

  userUIToDB(userUI) {
    return {
      user_id: userUI.id,
      first_name: userUI.firstName,
      last_name: userUI.lastName,
    }
  }
}

export const convert = new Convert();

That saves us some keystrokes whenever we're importing the Convert class. But it still rubs some devs the wrong way because we're relying on classes. But that's OK. Because we can accomplish the same thing with a function:



// conversionUtilities.js
export const Convert = () => {
  const userDBToUI = userDB => {
    return {
      id: userDB.user_id,
      firstName: userDB.first_name,
      lastName: userDB.last_name,
    }
  }

  const userUIToDB = userUI => {
    return {
      user_id: userUI.id,
      first_name: userUI.firstName,
      last_name: userUI.lastName,
    }
  }

  return {
    userDBToUI,
    userUIToDB,
  }
}

Here are the benefits of this approach:

No more "yucky" class keyword.
Again, we no longer need to repeat convert in every one of the function names, because it's implied in the name of the exported function.
All of our utility functions are "bundled" inside a single entity - the convert function - so they don't need to be imported individually.

But there's still at least one "downside":

Anytime you need to use these utility functions, you first need to call something like const convert = Convert(); before using the utility functions like const userUI = convert.userDBToUI(userDB);. That could become... cumbersome.

You could solve this "problem" by exporting the invocation of the parent function, rather than exporting the parent function itself. That would look like this:



// conversionUtilities.js
const Convert = () => {
  const userDBToUI = userDB => {
    return {
      id: userDB.user_id,
      firstName: userDB.first_name,
      lastName: userDB.last_name,
    }
  }

  const userUIToDB = userUI => {
    return {
      user_id: userUI.id,
      first_name: userUI.firstName,
      last_name: userUI.lastName,
    }
  }

  return {
    userDBToUI,
    userUIToDB,
  }
}

export const convert = Convert();

Honestly, this is the primary way that I usually see this done. But there is another way - with an IIFE - that we could do this without having to first 1) define the Convert function, and then 2) export the invocation of that function. That would look like this:



// conversionUtilities.js
export const convert = (() => {
  const userDBToUI = userDB => {
    return {
      id: userDB.user_id,
      firstName: userDB.first_name,
      lastName: userDB.last_name,
    }
  }

  const userUIToDB = userUI => {
    return {
      user_id: userUI.id,
      first_name: userUI.firstName,
      last_name: userUI.lastName,
    }
  }

  return {
    userDBToUI,
    userUIToDB,
  }
})()

Notice here that we didn't have to define the parent function, and then export the invocation of that function. Instead, we used an IIFE to do it all in one statement. Now, whenever someone imports convert, they'll get an object that already contains all of the utility functions inside convert.

Is this some rock-solid no-brainer use case for IIFEs??? No. As stated above, you can accomplish the same thing by:

Exporting every single utility function individually.
Encompassing the utility functions inside a class, and then exporting an instance of that class.
Encompassing the utility functions inside a parent function, and then exporting the invocation of that function.

Nevertheless, I find the IIFE approach to be just a little bit cleaner. And it's at least one valid use case for IIFEs.

Swallowing Promises

Async/await can be powerful tools when dealing with data calls and other asynchronous actions. But they can also cause a bit of a cascading headache in your code - especially in strict TypeScript code.

await can only be used inside an async function. Imagine that you have three cascading functions that do the following:

FunctionA handles the result of a user action (like clicking a "Submit" button).
If the right conditions are met, FunctionA then calls some validation logic in FunctionB.
Based on the results of the validation, FunctionB may then call FunctionC, which transmits the data to the server via an asynchronous REST call.

You want to use the await syntax in FunctionC, which means that you need to define it as an async function.

But this means that FunctionB will now be expecting a promise from FunctionC. So... you change FunctionB to be an async function.

But that means that FunctionA will now be expecting a promise from FunctionB. So... you change FunctionA to be an async function.

But now the event handler that originally called FunctionA is also expecting a promise. And depending on how strict your TypeScript environment is configured, that simply may not be an option.

The "cascading" effect of async/await would look something like this:



export const App = () => {
  const submit = () => {
    const result = await someApiCall(values);
    // handle API result
    return result;
  }

  const doValidation = () => {
    // check some validation
    if (isValid) {
      return submit();
    }
  }

  const handleSubmit = () => {
    // set some state vars
    if (someCondition) {
      return doValidation();
    }
  }

  return <>
    <button onClick={handleSubmit}>
      Submit
    </button>
  </>
}

In the example above, the TypeScript compiler will start complaining because callApi() is not an async function. So you set callApi() to be async but... that also requires doValidation() to be async. So you set doValidation() to be async but... that also requires handleSubmit() to be async. So you set handleSubmit() to be async but... TypeScript might still complain because the onClick event handler is not configured to handle the resulting promise.

At this point, you've started to shove async into a lot of places where you really never wanted it to be. And to make it even worse, TypeScript will still complain about the fact that your onClick handler is not handling the resulting promise.

[NOTE: In plain ol' vanilla JavaScript, you can simply ignore the resulting promise. But you can't convert your entire project from TypeScript to JavaScript just because you don't wanna deal with all of these cascading usages of async/await.]

Luckily, an IIFE can do a load of good here. That would look like this:



export const App = () => {
  const callApi = () => {
    (async () => {
      const result = await someApiCall(values);
      // handle API result
      return result;
    })()
  }

  const doValidation = () => {
    // check some validation
    if (isValid) {
      return callApi();
    }
  }

  const handleSubmit = () => {
    // set some state vars
    if (someCondition) {
      return doValidation();
    }
  }

  return <>
    <button onClick={handleSubmit}>
      Submit
    </button>
  </>
}

In the code above, we can now use async/await inside callApi() without ever having to declare callApi() as an async function. This works because the asynchronous call is happening inside an async function. It just so happens that the async function is... an IIFE inside the callApi() function.

This is actually a use case for IIFEs that I use a lot.

In-place Logic

Finally, I wanna illustrate a scenario where in-place logic (i.e., the kind of logic that's provided by an IIFE) can make a lot of sense.

I've recently been helping a friend with a bunch of EDI data transformations. On the surface, the work is pretty simple. You get a big data object that's supposed to be in a given format - maybe something like this:



const rawData = {
  fee: 'fee',
  einz: '1',
  fie: 'fie',
  zwei: '2',
  foe: 'foe',
  drei: '3',
  fum: 'fum',
}

Then you have to write some transformation routine that will extract (and "massage") certain values and return a new data object in a different format, like this:



const getGiantSpeak = data => {
  return {
    fee: data.fee,
    fie: data.fie,
    foe: data.foe,
    fum: data.fum,
  }
}

The "problem" arises when you realize that many of the vendors supplying the data will format that data in many different ways. For example, the simple logic above works just fine as long as you assume that the values in rawData are simple scalar values.

But then you find that your data transformations are intermittently failing. When you investigate the intermittent problems, you realize that sometimes the vendor is submitting rawData.fie as a simple string. And other times they're submitting it as an array of strings. So to fix this, you need to insert a little bit of logic at the point where getGiantSpeak() is returning the fie value.

In this scenario, I find that a simple IIFE works wonders:



const rawData = {
  fee: 'fee',
  einz: '1',
  fie: ['fie', 'fiddler'],
  zwei: '2',
  foe: 'foe',
  drei: '3',
  fum: 'fum',
}

const getGiantSpeak = data => {
  return {
    fee: data.fee,
    fie: (() => {
      if (Array.isArray(data.fie))
        return data.fie.join(',');
      else 
        return data.fie;
    })(),
    foe: data.foe,
    fum: data.fum,
  }
}

[NOTE: I realize that you can also accomplish the above logic with a simple ternary operator. But the "real life" examples usually require some more "nuanced" logic that doesn't lend itself to a ternary operator.]

In this scenario, the logic needed to build the new object is truly single-use, and it can be much cleaner to encompass it in an IIFE.

The Communication Shortcomings of Programmers

Adam Nathaniel Davis — Thu, 31 Aug 2023 20:02:24 +0000

In my previous article (https://dev.to/bytebodger/most-managers-have-no-clue-what-we-actually-do-k07) I railed about my assessment that most organizations have no real concept about what programmers actually do. In that article, I spelled out many depressing truths about the many ways in which devs' efforts are often discounted. So I'm following that article up with some advice.

As frustrating as it can be to deal with people who don't really grok the process of software development, I do honestly believe that we, as programmers, often bring this problem on ourselves. You see, the simple (and painful) truth is that most programmers are pretty piss-poor communicators. If we were great communicators, we wouldn't have chosen a career field where vast portions of our day are spent silently clacking away on a keyboard. And while we can't make everyone else "see the light" about software development, we could do much more to ensure that we're effectively communicating with everyone outside our dev team.

Mimicking Communication

The first thing I want to point out is something that any salesperson knows very well. One of the most effective ways to communicate with others is to mimic the style in which they already communicate.

No, I'm not talking about trying to copy someone's voice or mannerisms. I'm talking about carefully observing how others choose to communicate, and then, whenever possible, communicating with them in their chosen style.

Devs can be really crappy at this because they tend to have mastered a given communication channel - their preferred communication channel - and then they blow off anyone who doesn't prefer that particular channel.

For example, maybe you hate Slack. Maybe you constantly set yourself as "Away" - even when you're right there at your desk working on code. And to be clear, on occasion, this can make perfect sense. But sometimes there are those who simply refuse to communicate in any way other than Slack. If you know someone like this - especially if it's someone who has input on your work - then you may want to consider getting off your Slack high horse and swapping a few chat messages with them. You won't like it. It may not feel comfortable. But in the end, it will keep that person from seeing you as a non-communicative jerk.

In my last job I had a manager who wanted nearly everything to be written up in a Quip doc. It didn't matter if I'd put copious notes on all my commits and pull requests. It didn't matter if I wrote a tome of detail in the ticket. It didn't matter if I sent him 12 Slack messages and 39 emails. He wanted things written up in an endless stream of Quip docs.

I could spend 20 paragraphs griping about this guy. But the simple fact is that, if I really wanted to "get through" to him, it wasn't going to happen unless I started putting data in the tool of his choice. Most developers despise this. I despised this. But getting angry about it didn't do me a damn bit of good.

Avoiding Face-Time

When I've joined a new company and I find myself in a group video conference, I can usually identify the programmers in the meeting even before they've introduced themselves. They're the ones who stubbornly refuse to to turn on their cameras.

To be clear, I'm not claiming that you always need to have your camera on. But when you remove the video from video conferencing, you undercut a huge portion of its utility. There are soooo many visual cues that we're subconsciously trained to pick up that fly out the window when one of the key participants just can't be bothered to turn on his camera.

Because of this, the inability to match a face to a voice fosters the mental image that some have of programmers as antisocial urchins. If you think this has no impact on your social standing in the company, you're probably deluding yourself.

Technobabble

Programmers are notorious at failing to read a room. If you're sitting in a dev meeting - with nothing but other developers - it's fine to debate various approaches to dependency injection or to talk about the possibility that a given bug may be caused by a race condition. But if you're sitting in one of your "normal" business meetings and talking about these concepts, you're almost certainly losing your audience. You may even be guilty of being... a jerk.

One of the reasons why "the business" can be so clueless about what we actually do is because, when they ask us directly, we revel in drowning them in technobabble. When this happens, we often feel smug in believing that we've explained exactly what we're doing. But in reality, we've only made the situation worse.

Have you ever been frustrated when an inferior programmers gets promoted (or some other type of recognition) while your efforts go unnoticed? It's probably because that doofus can describe his work (even if his work is subpar) IN BUSINESS TERMS.

Voluntary Isolation

Lemme tell you something that some may see as "underhanded". I've known plenty of devs in my career who simply hated talking to some (or, nearly all) of the "business types". They didn't wanna be in meetings. They didn't wanna have to present (demo) any of their work. They didn't wanna participate in any broader company activities. In some of those cases, they would literally ask me to handle the communication overhead. And you know what? I did it.

Months later, they'd be looking for a new job. (Or even, rage-quitting.) Why were they so frustrated? Because I had received a ton of recognition while their efforts went unnoticed.

Now to be clear, I've never claimed anyone else's work as my own. And I've always gone out of my way to try to attribute credit wherever it's due. But when those "business types" come to see me as the "voice of dev", it's only inevitable that they eventually put great value in my position - and they see others as being "expendable".

It's fine to "hunker down" when you're up against a tight deadline. But if you're going out of your way to avoid any contact with anyone outside the dev team, don't go crying in your beer when those non-dev folks fail to understand your contributions.

Combativeness/Defensiveness

Show me a dev who doesn't enjoy a good fight and I'll show you a purple squirrel. And yes, I'll freely admit that I've too often been guilty of this myself.

I find that most devs have a decent "survival instinct" when it comes to avoiding fights outside the dev team. But when it comes to matters that are code-specific? Matters that are only debated and adjudicated between software engineers...? Well, let's just say that things can get messy.

It's easy to assume that the other devs are "on your side". It's even easy to assume that "normal" disagreements between devs are understood and tolerated as the typical process of building applications. But I've seen far too often that the guy burying his knife deeeeeeep into my back is the same guy who didn't appreciate my argument that we should be using Zustand instead of Redux. And when someone outside the dev team asked him to comment on me, he was all-too-quick to paint me as a malcontent.

Let's be honest here: You can't build a ton of software applications without, occasionally, having a debate with someone about the relative merits of one technical approach over another. But if you want the broader business to focus on your worth - and not on the putative headaches that you bring to the organization - then you need to be very careful about where-and-when to pick your battles. Because once the rest of the organization hears that you're a troublemaker, they'll turn a deaf ear to any other efforts to herald your work.

Most Managers Have No Clue What Programmers Actually Do

Adam Nathaniel Davis — Tue, 09 May 2023 04:49:22 +0000

I've been thinking a lot lately about 1.) the avalanche of layoffs happening across the tech industry, 2.) the current push to drive remote workers back into offices, and 3.) the latest hysteria around AI. While these issues have many different factors, I believe there's one common thread among them: Too many "dev managers" have little-to-no-clue what software engineers actually do.

Before I dive into the details, I'm gonna make one thing clear. For the sake of this article, when I say "dev manager", I'm gonna use the term in a very broad sense. Specifically, I'm using "dev manager" to refer to any corporate employee who's responsible for managing the output of a software developer - or an entire team of developers.

There are many different models for managing software development. Sometimes, your "dev manager" may be a technical coder like yourself. But it could also be an executive (e.g., CTO), project manager, product manager, business analyst - or... nearly any other title. But the longer I survive in this career field, the more I'm convinced that very few of them - regardless of title - ever understand the true nature of our work.

Counter-Intuitive

On the surface, this may sound like an odd premise. The question, "What does a software engineer do?" may seem like it has a simple (and obvious) answer: We write software! (Duhh...) But if you've been slinging code for more than a few years, you've probably noticed that a significant portion of every day is not spent in your IDE.

Meetings

First, there are usually many meetings that plague software engineers. Meetings within your team (e.g., standups, demos, code reviews). Meetings with management. Meetings with clients/stakeholders. Even meetings that have nothing to do with your core job function. (Like, "all-hands" meetings.)

I once had a job as an "IT Manager" for a large bank. I had a small team that handled the systems that managed the bank's public internet presence. My role was "hands on", and I was expected to contribute directly to development projects, while still handling the duties of a frontline manager.

One day I had meetings scheduled from 9AM-10AM, 11AM-Noon, 1PM-2PM, and 3PM-4PM. The next day, my director asked for an account of the team's progress from the previous day. After I brought him up to speed on what had been completed (and not completed), he asked me, "But what did you program yesterday??" I bluntly told him that I didn't get any programming done in the previous day, because I had four meetings scheduled. He then asked me, "But those meetings only took four hours. Why didn't you get any coding done in the other four hours?"

My director had no understanding of the fact that, with four meetings throughout the day, occurring every-other-hour, I had virtually no time to sit down and actually write code. Each meeting on my schedule required at least some degree of "prep work". And each meeting spawned a series of "take-aways" and follow-on communications that I needed to handle directly afterward. This meant that, at most, I had maybe 30 minutes to do any real coding between meetings - and for any kinda serious mental work, I just wasn't able to parachute into the middle of a task for 30 minutes and get anything meaningful accomplished.

Teamwork

Beyond the endless series of meetings present in most software jobs, there's usually some degree of "teamwork" that goes with the job. Maybe you need to help someone else troubleshoot an issue. Or maybe you need to help the new guy get up-to-speed. Or maybe you need to spend some time tweaking the deployment pipeline. Or maybe you need to review the pull requests of others. Or maybe you need to spend some time sifting through logs. Or... well, the list goes on and on.

Most of these "teamwork" tasks rarely result in a nice clean deliverable. They don't often satisfy a sprint task. They don't yield a new feature to make the client happy. They're usually best defined as grunt work. But that doesn't mean these tasks are unnecessary. In fact, if no one does them at all, the efficient operation of your team may grind to a halt.

Reading/Research/Grokking

Even when you're lucky enough to have your nose stuck in code, that doesn't necessarily mean that you're writing new code. There are many estimates floating around out there about the amount of time that a dev spends reading code versus writing code. And those estimates always conclude that reading code is a far bigger part of the job than actually writing code. Nevertheless, when you're reading code, you're rarely delivering anything tangible that a manager would quantify as progress.

Blind Management

The problem with all these "soft" tasks is that management is often blind to them. If you sit down and explain these tasks to them, they'll offer lip service as to their importance. They'll claim that they understand that there are many tasks in a developer's job that don't lead directly to deliverables - and then... they'll turn around in the same breath and ask, "But... you're gonna have those deliverables completed today, right???"

To be fair, this isn't necessarily an act of wanton, willful ignorance on their part. Of course they have deliverables that they need to ensure are completed on time. And of course they're gonna be heavily focused on those deliverables and their associated timelines. But sometimes it can be infuriating to witness the disconnect when you tell them that you had to unexpectedly burn a day standing up a new server - but they assume that the due dates will remain unaffected.

You see, here's a central problem of software development:

Those who are not directly involved in the writing of software find it extremely difficult to conceptualize the non-coding aspects of the job - or to account for them when managing expectations.

In theory, they know that there are many non-coding tasks involved in almost any software engineering milestone. However, in practice, they struggle to grasp what those tasks are, or how long they'll take.

Even when you go out of your way to brief them on all the non-coding tasks - even as the work is underway - they're still thinking in the very basic language of deliverables. Anything you must do that cannot be directly tied to a deliverable runs the risk of frustrating those who are managing software development efforts.

Beware the "Technical Manager"

It would seem that an easy solution to this problem is to ensure that those who are managing software engineers have an inherent understanding of the software engineering process itself. In other words, we can avoid these misunderstandings as long as the "dev managers" are people who used to be coders themselves... right???

Ummm...

While I've certainly had some bad experiences with non-technical managers, I have to say that I've also had some horrific encounters with managers who used to be coders themselves. This may sound bizarre. After all, if someone used to be writing code not-that-long-ago, then they should have an inherent understanding of all the "soft tasks" that go into a developer's typical day... right???

Ummm...

The problem is that, in many organizations, the "dev manager" is thrown into so many meetings, and spends so much time communicating with people outside the dev team, that they can scarcely keep eyes on the actual work taking place. They can get overwhelmed trying to keep tabs on the daily efforts of a half-dozen (or more) programmers. They rarely get time to peruse code on their own - or interface one-on-one with the developers. This means that, far too often, the dev manager ends up looking at the same basic "metrics" (deliverables & timelines) that would be used by any other manager with no direct programming knowledge.

Sometimes, the dev manager's technical knowledge can actually be a liability. Because they might remember what it took to do a particular task in the codebase when they were working on the code (often, years in the past). And it can be difficult for them to grok how the current state of the codebase has evolved (or... devolved).

[FUN SIDE NOTE: If you're ever in standup and you're tempted to say something like, "This task is taking a bit longer than expected because this particular section of code is a royal mess," you may wanna do a quick git blame on the code first and see who originally wrote it. It's entirely possible that it was written, years ago, by your dev manager. And some dev managers don't have the emotional maturity to handle comments like this very well.]

The Illusion of Accountability

It took me a long time to grasp these potential disconnects between me and my dev manager. Because modern processes of software engineering often feel as though they're inherently (even... copiously) documented. When I'm working on a task, the audit/accountability trail typically looks like this:

A task is assigned to me from some ticket management system (e.g., Jira). The task has all sorts of meta data about the task itself. Ideally, it has estimates and solid notes for exactly what's expected.
The coding aspects of the task are all encompassed in one-or-more commits. I place notes on each one of those commits (e.g., commit messages).
Throughout the coding process, I give daily verbal updates (usually, during standup) explaining my progress, and expected completion times.
The completed code also contains unit tests that go a long way toward describing exactly what the code is expected to do.
When I'm satisfied that the commits fulfill the requirements of the task, I submit a pull request. I usually add more notes on the pull request to aid other developers who are reviewing the code. If other devs have questions about anything I've done, they add their own notes to the pull request, sometimes leading to discussion that's recorded directly on the PR itself.
Once the code has been merged, I then add more notes in the task management system, in addition to updating the status of the ticket itself.

So by the time that I'm truly done with a task, I've added my own documentation to 1.) each individual commit, 2.) the PR that encompasses the changes, and 3.) the ticket that tracks the status of the changes. This is in addition to numerous daily verbal updates.

That feels like a lot of documentation for every single task, right? And with that level of documentation, there really shouldn't be any mystery on the part of my dev manager (or anyone else on the team) as to what I'm doing or why it took as long as it did... right???

Ummm...

Unfortunately, I've found that, far-too-often, my dev manager isn't taking the time to monitor any of these communication channels. They typically don't have the bandwidth to review commits or PRs. They often haven't read any documentation that I've added in the task management system. Hell... sometimes they weren't even listening when I gave my verbal updates during daily standups.

In other words, despite all of this status-tracking, I've run into situations, on multiple occasions, where my own dev manager wasn't aware of any of it. All they "hear" is 1.) Is the task done? and, 2.) If it's not done, when will it be done? Beyond those basic data points, the dev manager often has little-or-no-clue about what I (or anyone else on the team) is actually doing on a day-to-day basis.

Last year when I was working for Amazon, I had a dev manager who used to code. After I'd worked there for several months, he somehow got the impression that I was "falling behind". This was despite the fact that, by numerous metrics (e.g., commits, PRs, completed tasks, LoC), I was actually doing several times more work than anyone else on the team.

I was documenting the ever-loving hell outta everything I was doing. In commit messages, and PR messages, and in the ticket management system. But none of that mattered. Because my dev manager couldn't be bothered to actually read any of it. Even worse, I came to realize over time that, when I gave verbal updates on my work during standups, he wasn't even listening to those updates.

[NOTE: I'm fully aware that many metrics of programming "velocity" - like # of commits, # of PRs, etc. - are very poor measurements of productivity. I only bring them up here because, when your metrics are several times greater than anyone else on the team, it's borderline ludicrous to imply that you're somehow "falling behind".]

The Danger For Remote Workers

Remember, at the top of this article, how I mentioned this in relation to remote work? Well, here's where this gets really sticky for those who aren't in a traditional office space.

When you're sitting in someone's office, your dev manager may have little understanding of exactly what you're doing at any point in time. But there's an incredibly basic (and... ignorant) "metric" that many in-person managers use to "gauge" your efforts: They simple see you working.

As ridiculous as that sounds, the sad truth is that, for many managers, their primary "metric" for gauging your productivity is simply that they can walk by your desk and see that you're... umm, working? They may not be tied into the actual work you're doing. But at an extremely basic level, they can look up from their own desk and see that you're... typing? Coding?? Doing something???

You may be staring mindlessly at the code for hours. In fact, if they're not looking over your shoulder, they may not even know if you're even looking at the code at all. But they still get a warm-fuzzy just by knowing that you're sitting at your desk and ostensibly... working.

Sadly, remote workers do not enjoy this (extremely basic) "benefit of the doubt". If you're working remotely, and you're doing something that's not directly tied to a "hard" deliverable, it can be extremely difficult to keep your manager "in the know" about the fact that you're working hard and performing critical tasks. This can be true even when you're going out of your way to add all those little bits of documentation (on commits, and PRs, and tickets...) that are customary in almost all software teams.

So when the corporate big-wigs start fretting about last quarter's less-than-stellar results, and they begin reaching for solutions (any solutions), it's easy to target the remote workers. Because your dev manager may have little idea of what you're actually doing. (Or, in the most extreme cases, if you're actually doing anything at all.)

Joe, who sits in the corporate office all day and can be seen clacking away on his keyboard, is generally "safe" during these evaluations. It matters little that Joe may be a crappy developer. It matters little that he spawns tsunamis of bugs and reworks. All that does matter is that your dev manager, oblivious to the real work that goes into software engineering, can see that Joe is constantly working. Even though he's... not sure exactly what Joe's working on.

Layoff Liability

This same bias against remote workers plays out when it comes time to lower the axe. Management is almost always prone to jettison the remote workers first. (Or... they do a cowardly "soft layoff" by issuing a return-to-office mandate - knowing damn well that many of the remote workers will leave of their own accord.)

This happens because soooo many organizations have no clue how to monitor/measure what software engineers are actually doing. Granted, if you singlehandedly rewrote your team's core application, and you did it swiftly and free of bugs, then maybe your chain-of-command understands your worth to the organization. But if your recent tasks were more along the lines of those "soft" tasks - things like setting up servers or diving into error logs - then you may find that they're oblivious to your true value.

In those scenarios, they almost always give the benefit of the doubt to the guy who's actually sitting in their office. It doesn't matter if that guy sucks. They can see that he's working - and that's usually good enough for them.

It should also be noted that there's been many stories lately about remote workers who basically had nothing to do. (I'm casting a nasty glance at you, Meta.) And in those scenarios, that may sound like a damning statement on remote workers. But if a company hired a bunch of remote engineers, and then couldn't be bothered to keep them busy with critical tasks, whose fault is that exactly?

And why were these Big Tech companies needlessly hoarding programming talent that they couldn't even put to work? Because many of the managers in those companies never properly understood what software engineers do in the first place.

The AI Boogeyman

Finally, I'll mention that this inability (or unwillingness) to actually understand what software engineers do represents a short-term threat to developers. (And this is especially true of remote developers.)

No, I'm not claiming that AI is going to make your job obsolete. But I am claiming that, if your management doesn't fully appreciate what you do, it's far easier for them to imagine that you can be replaced (in part, or entirely) by AI tools.

Let me first put this in a historical perspective. I'm old enough to remember when outsourcing/offshoring was perceived as the biggest "threat" to software engineers. (At least, for those developers who were not living in a prime offshoring locale.) We now know how that played out.

Offshoring is definitely still "a thing". And it won't be going away any time soon. But many large development projects that were offshored decades ago ended up getting pulled back to their home bases. Why?? Because the executives who thought they could game the system by offshoring everything found that the results were often... appallingly underwhelming.

And why were those results so disappointing??? Because those executives didn't properly understand what software engineers actually DO in the first place. They saw development as some kind of assembly-line process that could be farmed out to the cheapest bidder. But those projects ended up taking far longer than expected. And even when they were delivered, the results were often suboptimal.

This occurred because quality in-house software engineers perform a whole range of critical tasks that go beyond simply receiving specs and cranking out the desired algorithms. They interview stakeholders. They architect robust solutions. They anticipate short-and-long-term hurdles. They don't just type out code in their IDEs. They solve problems.

Of course, there's absolutely a time-and-place for offshoring. And offshoring has settled into a valuable role for many corporations. But there are few organizations that can successfully manage an ongoing software development operation that is entirely offshored.

Unfortunately, I believe many of these same misguided strategies will play out with regard to AI. Yes, AI is a fabulous (and rapidly evolving) tool to enhance the productivity of savvy developers. Yes, AI's role in software engineering will almost-undoubtedly increase over time.

But before AI settles into an accepted role in corporate life, there will certainly be those who foolishly think that they can replace their engineering resources with ChatGPT. (Or any of the other evolving tools.) And this will probably play out this way because, to this day, there are still so many people who manage development projects, but fail to understand what their developers are actually doing.

In The Next Installment...

This article may be a bit, umm... depressing. But I don't mean it as such. In the next article, I'll propose some strategies that you can employ, as an individual developer, to try to mitigate these hurdles.

Stay tuned...

Updating React State Inside Loops

Adam Nathaniel Davis — Mon, 24 Apr 2023 21:57:28 +0000

I recently ran into a very nasty little conundrum with React. I found a use-case where I felt it was necessary to update React state variables inside a loop. I initially had no idea how vexing it would be.

State Management Under-The-Hood

Before I dive into this problem, there are a few basic facts that you need to understand about how React manages state variables. This should be second nature to all of you salty old React vets out there. But it's important to establish these ground rules before we dive in.

React state is asynchronous

When you update a React variable, the subsequent mutation occurs asynchronously. You can prove it out with an example like this:



export const MyComponent = () => {
  const [counter, setCounter] = useState(0);

  const increment = () => {
    setCounter(counter + 1);
    console.log('counter', counter);
  }

  return <>
    <div>
      Counter = {counter}
    </div>
    <button onClick={increment}>
      Increment
    </button>
  </>
}

From a UX perspective, the example above works just fine. Every time you click Increment, the counter value updates. However, the console.log() output will always be one update behind. This happens because the update occurs asynchronously. And when the code hits the console.log(), the value has not yet been updated.

React batches state updates

React does a lot of work behind the scenes to optimize performance. Normally, this optimization doesn't really phase us. Because the typical flow is:

A user performs some action (like clicking a button).
The state variable is updated.
React's reconciliation process is triggered.
This process realizes that there's now a diff between the virtual DOM and the actual DOM.
React updates the actual DOM to reflect the changes in the virtual DOM.

In the vast majority of circumstances this all happens so fast as to appear, to the naked eye, as instantaneous. But the good folks who built React also put in some safeguards to protect against those instances where a developer tries to fire off a rapid series of state updates.

Of course, this optimization is, by and large, a very good thing. But it can be baffling when you feel that those successive updates are truly necessary. Specifically, React goes out of its way to ensure that all state updates that are triggered within a loop will not actually be rendered until the loop has finished running.

A Case Study For State Updates Inside A Loop

My website - https://paintmap.studio - does image/color manipulation. Although the functionality works precisely as designed, this does present a few challenges:

Images have the potential to be large. I could introduce some artificial limits on the size of the image file (either in raw kilobytes or in height/width dimensions), but doing so would undermine much of the utility of the application.
The images are not being uploaded and processed on a server. It's a single page application with no backend component. It runs entirely in the browser. So I can't, for example, upload an image, commence some intensive processing, and then promise to email the user a link to the finished product when the process is complete.
The amount of time it takes to process an image is largely dependent upon the processing options that are chosen by the user. For example, processing an image with the RGB color space is much faster than using Delta-E 2000. Dithering an image takes more time than if dithering is avoided. So in theory, I could introduce some artificial limits on the number of options available to the user. But again, this would undermine much of the utility of the application itself.

The simple fact is that sometimes I want to transform an image, of a certain size, and with a certain number of processor-intensive options, that's gonna take a little time to complete. When that happens, I don't want the user wondering if the application has crashed. I want them to understand that everything is chugging along as-planned and their newly-processed image will be completed soon.

The Progress Bar

One of the most time-tested ways to let the user know that processing is continuing as-planned is to give them some kind of progress bar. Ideally, that progress bar updates in real-time as the code works through its machinations.

Of course, this is nothing new at all. Applications have been providing this type of user feedback for decades. But when I tried to implement this in React with Material UI's <CircularProgress> component, I ran into some really nasty headaches.

Because I don't want to confuse the matter by trying to drop you right into the middle of Paintmap Studio's code, I've instead created a simplified demo in CodeSandbox to illustrate the problem. You can view that demo here:

https://codesandbox.io/s/update-react-state-in-a-loop-04b9ek

The Problem - Illustrated

In the Code Sandbox demo, I've created an artificially-slow process to illustrate the issue. When you load this demo, it gives you a single button on the screen titled START SLOW PROCESS. The idea is that, once you click that button, a somewhat lengthy process will be triggered.

But we don't want the user wondering whether the site's crashed. So once the button is clicked, we need to have an interstitial overlay shown on screen. The overlay let's the user know that the process is underway, and ideally, gives them a dynamic progress indicator that lets them know how far the process is from being completed.

We'll start the illustration with App.js:



// App.js
export const AppState = createContext({});

export const App = () => {
  const [progress, setProgress] = useState(0);
  const [showProcessing, setShowProcessing] = useState(false);

  return (
    <>
      <AppState.Provider
        value={{
          progress,
          setProgress,
          setShowProcessing,
          showProcessing
        }}
      >
        <UI />
      </AppState.Provider>
    </>
  );
};

App.js is mostly just a wrapper for the UX. However, I'm using the Context API to establish some state variables that will be useful in the downstream code. progress represents the completion percentage of our SLOW PROCESS. showProcessing determines whether the progress interstitial should be shown.

Now let's take a look at UI.js:



// UI.js
export const UI = () => {
  const { progress, showProcessing } = useContext(AppState);
  const { runSlowProcess } = useSlowProcess();

  const handleSlowProcessButton = () => runSlowProcess();

  return (
    <>
      <Backdrop
        sx={{
          color: "#fff",
          zIndex: (theme) => theme.zIndex.drawer + 1
        }}
        open={showProcessing}
      >
        <div className={"textAlignCenter"}>
          <Box
            sx={{
              display: "inline-flex",
              position: "relative"
            }}
          >
            <CircularProgress
              color={"success"}
              value={progress}
              variant={"determinate"}
            />
            <Box
              sx={{
                alignItems: "center",
                bottom: 0,
                display: "flex",
                justifyContent: "center",
                left: 0,
                position: "absolute",
                right: 0,
                top: 0
              }}
            >
              <Typography 
                color={"white"} 
                component={"div"} 
                variant={"caption"}
              >
                {`${progress}%`}
              </Typography>
            </Box>
          </Box>
          <br />
          Slow Process Running...
        </div>
      </Backdrop>
      <Button
        onClick={handleSlowProcessButton}
        size={"small"}
        variant={"contained"}
      >
        Start Slow Process
      </Button>
    </>
  );
};

First, the named components in the JSX, like <Backdrop>, <Box>, <CircularProgress>, <Typography>, and <Button> come from Material UI.

Second, the component leverages the AppState context that was established in App.js. Specifically, we'll be using showProcessing to toggle the visibility of the interstitial layer. And we'll be using progress to show the user how far the SLOW PROCESS is from completion.

Finally, this component also imports a custom Hook. That Hook is called useSlowProcess(). Let's take a look at that:



// useSlowProcess.js
export const useSlowProcess = () => {
  const { setProgress, setShowProcessing } = useContext(AppState);

  const runSlowProcess = async () => {
    const startTime = Math.round(Date.now() / 1000);
    setProgress(0);
    setShowProcessing(true);
    for (let i = 1; i < 101; i++) {
      for (let j = 1; j < 1001; j++) {
        for (let k = 1; k < 1001; k++) {
          for (let l = 1; l < 1001; l++) {
            // do the stuffs
          }
        }
      }
      console.log(i);
      setProgress(i);
    }
    setShowProcessing(false);
    console.log(
      "Elapsed time:",
      Math.round(Date.now() / 1000) - startTime,
      "seconds"
    );
  };

  return {
    runSlowProcess
  };
};

useSlowProcess() returns a single function: runSlowProcess(). runSlowProcess() does the following:

It establishes a startTime so we can calculate just how long the SLOW PROCESS actually takes. (After playing with this repeatedly on Code Sandbox, I can tell you that it takes ~27 seconds to complete.)
It ensures that our progress variable starts at 0.
It then sets showProcessing to true so the user will see the in-progress interstitial.
It then launches into the SLOW PROCESS.
The outer loop runs for 100 iterations. This means that every completion of the outer loop essentially means that we've completed 1% of the overall process.
After each percentage is completed, we console.log() the current progress and we update the progress variable. Remember, that variable will be used to show the user how close we are to completion.
When the process is complete, we set showProcessing back to false. This should remove the in-progress interstitial.
Finally, we console.log() the total number of seconds that it took to complete the SLOW PROCESS.

So what happens when we run this code??? Well... it's very disappointing.

When the user clicks the START SLOW PROCESS button, there is no interstitial shown on screen. This also means that the user sees no <CircularProgress> bar, with no constantly-updated completion percentage.

But why does this happen?

Batching Headaches

This is where we run head-first into the problems with React's batch updating of state variables. React sees that we're setting showProcessing to true near the beginning of runSlowProcess() but we're also setting it to false near the end of the process. So the batched result is that it simply sets showProcessing to false. Of course, it was already false when we began the process. So setting the previous value of false to... false results in the user never even seeing the in-progress interstitial.

Even if we solved that problem, the user would never see any of the percent updates to the progress variable displayed inside the <CircularProgress> component. Why? Because React sees that the state variable progress is being updated repeatedly through the outer for loop. Thus, it batches all of those updates into a single value. Of course, this completely undermines the whole purpose of having a progress indicator in the first place.

Frustrating (Non)Help

Remember, the <CircularProgress> component comes from Material UI. And Material UI has a ton of helpful documentation that's supposed to show you how to use their components. So my first step was to go back to that documentation for help. But... it was of no help whatsoever.

Here's the code sample that Material UI gives you to illustrate how you can update the progress value in the <CircularProgress> component:



export default function CircularDeterminate() {
  const [progress, setProgress] = React.useState(0);

  useEffect(() => {
    const timer = setInterval(() => {
      setProgress((prevProgress) => (prevProgress >= 100 ? 0 : prevProgress + 10));
    }, 800);

    return () => {
      clearInterval(timer);
    };
  }, []);

  return (
    <CircularProgress variant="determinate" value={progress} />
  );
}

To be clear, Material UI's code sample "works". I mean... it does dynamically update the progress value inside the <CircularProgress> component. But this is one of the few times that I found their documentation to be borderline useless.

You see, they're using useEffect(), in conjunction with setInterval(), to blindly update the progress value based on nothing more than a predetermined delay of 800 milliseconds. While that works fine for displaying a rote example of how the component renders, it does nothing to tell us how we can tie the progress value to an actual, meaningful calculation based upon the true progress of the process.

Faced with this very useless example, I then did what any lifelong developer would do: I started googling. But almost all of the posts I found on places like Stack Overflow were similarly useless.

The issue you encounter when you google this problem is that nearly every developer has the exact same "answer":

Don't update React state variables in a loop.

While I understand that there are many scenarios where you do want to avoid repeatedly updating React state inside a loop, the simple fact is that this use case is the quintessential use case where you absolutely should be updating React state inside a loop. Because the progress value should, ideally, be calculated based upon the actual progress of the algorithm - NOT based upon some mindless setInterval() delay.

I actually encounter this sort of non-help all the time. You're trying to solve some kind of sticky programming problem. But rather than providing any meaningful help, the mouth-breathers simply reply that you shouldn't be doing this at all.

It's like seeing someone's post about how they can't figure out how to cook a proper souffle without it collapsing and becoming a mess - and some smartass troll in the cooking forum responds by saying:

You shouldn't be cooking souffles anyway. Just make an omelette.

Wow. That's sooooo helpful. Thankfully, I did eventually solve the problem...

Promises To The Rescue

The key to solving this one is that you have to introduce a delay. If you look at what's happening in Material UI's example, they're invoking a delay with setInterval(). But the real reason why their example "works" is because the setInterval() is embedded within useEffect(). This creates a kind of feedback loop where the state variable is updated inside useEffect(), then the reconciliation process updates the DOM, which triggers another call to useEffect(), which then updates the variable again, and so on and so on...

Of course, in my example, I'm trying to track the progress of a function inside a Hook. So it's not terribly useful to rely upon useEffect().

But there's another way to invoke a delay without using useTimeout() or useInterval(). You can use a promise. Promises (and their associated async/await convention) basically knock React out of its batch update mentality.

The updated useSlowProcess() code looks like this:



// useSlowProcess.js
export const useSlowProcess = () => {
  const { setProgress, setShowProcessing } = useContext(AppState);

  const runSlowProcess = async () => {
    const startTime = Math.round(Date.now() / 1000);
    setProgress(0);
    setShowProcessing(true);

    const delay = () => new Promise((resolve) => setTimeout(resolve, 0));

    for (let i = 1; i < 101; i++) {
      for (let j = 1; j < 1001; j++) {
        for (let k = 1; k < 1001; k++) {
          for (let l = 1; l < 1001; l++) {
            // do the stuffs
          }
        }
      }
      console.log(i);
      setProgress(i);
      await delay();
    }
    setShowProcessing(false);
    console.log(
      "Elapsed time:",
      Math.round(Date.now() / 1000) - startTime,
      "seconds"
    );
  };

  return {
    runSlowProcess
  };
};

Now when you click the START SLOW PROCESS button, the progress interstitial shows up on the screen, including the <CircularProgress> component with it's constantly updated progress indicator.

Notice a few things about this approach:

I invoke the delay directly after I've updated the progress value inside the for loop. This has the side effect of knocking React out of the batch update process.
The length of the delay is immaterial. As you can see, I'm invoking a delay of ZERO milliseconds. That may seem illogical, but it's all that's needed to trigger DOM updates in React.

Conclusion

I just wanna be clear that, in the vast majority of instances, it's truly a solid idea to avoid doing repeated React state updates inside a loop. But I wanted to highlight this use case because, when you're trying to give the user real-time info on the status of an ongoing process, it's one potential scenario where it makes total sense to do it.

Test-Driven Daydreams

Adam Nathaniel Davis — Wed, 19 Apr 2023 20:42:50 +0000

My thoughts on Test-Driven Development (TDD) have certainly... fluctuated over time. At this point, it's far from being a new concept. Wikipedia traces its origins to the early 2000s. I believe that I first heard of it about a dozen years ago. During that time, my personal exposure to it has varied wildly from one company to the next.

This is not my pro-TDD fanboy article. Nor is it my click-baity anti-TDD rant. Rather, I'm writing about it now because I think I've settled on an approach to TDD that works for me. Of course, your mileage may vary...

TDD Fanboys

My first "problem" with TDD, similar to problems that I experience with almost any other approach to dev, is that it spawns its own legion of fanboys. Granted, this is true of sooooo many other aspects of software development. But if you're trying to have a calm, rational discussion with someone about TDD, it's nearly impossible to do so with those who've already drank the TDD Kool-Aid.

So while I know that these points will do absolutely nothing to quiet the TDD mouth-breathers, I'm still gonna point out a few basic facts:

TDD is not a "cure-all".
You can be a great developer without ever worrying about TDD. You can be a crappy developer who adheres tightly to TDD. TDD can be a great tool. Just like a hammer can be a great tool. But that doesn't mean that it's the "right" tool for every job.
TDD is too often confused with general concepts of unit testing.
Writing unit tests does not (necessarily) mean that you're following TDD. Having X% of test coverage does not qualify (or disqualify) you as doing TDD. And doing TDD doesn't solve the ongoing questions of exactly what should-or-should-not be tested within a given codebase.

The above facts are not meant as any kinda "take-down" of TDD. But I've grown a little tired of hearing the TDD fanboys talk about it as though it solves many issues around testing - that it doesn't really solve at all.

The Challenges of TDD Groupthink

Most of my qualms haven't been with the concepts of TDD. They've been with the difficulty in getting everyone on a team to adhere to those concepts - or to even agree on what those concepts are. I've been in some shops where TDD was talked about like an unreachable dream. I've been in others where it was presented as some kind of standard, that we all should be following, and then... no one followed it. I've been in places where it was openly agreed that we would be implementing TDD - and then those guidelines were blatantly ignored as soon as we faced the first pending deadline.

I've also seen scenarios where an underlying desire for TDD "purity" culminated in abandonment of the approach altogether. For example, some believe that the "right" way to do TDD is to have someone else write the original tests, before you begin writing the code that would adhere to those tests. And that approach isn't "wrong". But it requires a lot of coordination and team cohesion. And when that coordination fails to materialize... everyone just drops the whole TDD idea and goes back to doing things as they did before.

Let me absolutely clear on this: I've been in several different shops where TDD was discussed/proposed/championed, but I've never been in a dev shop where it was actually implemented as a regular practice. And I'll also be honest here and admit that, when the rest of the team easily abandoned their TDD dreams, I tended to fall inline with the group.

I also wanna be crystal clear in saying that I'm sure there are dev shops out there that rigidly adhere to TDD. I'm not claiming that they don't exist. I'm just stating that, in my anecdotal experience, TDD is frequently talked about, but has rarely/never been truly implemented.

Going It Alone

One of my recent "aha" moments was around the idea that I don't need to have Full Team Buy-In in order to do TDD. In other words, if Joe and Mary on my team don't bother with TDD, that doesn't mean that I can't still write my code with TDD. In the past, I tended to see this as a team-centric decision. And to be frank, it is better if the whole team is aligned on something like this. But that doesn't mean that everyone has to be in lockstep.

That may sound like I'm advocating for you to "cowboy" your way through the dev process. But I think it's perfectly reasonable to say, "This is the way that I know to write high-quality code. So this is the way that I'm going to attack this problem." In practice, there are many aspects of dev where I enforce my own personal coding standards. For example:

If I'm building a new database-driven app/feature, I start first with the database. I design the database schema (or, at least, I ensure that I fully understand the existing schema) before I ever begin writing the first line of code. I don't ask others if they want me to do it this way. I don't worry whether the others will design their features with the same approach. For me, I know the best way to get the feature built. So I just go about doing it that way.
Similarly, if I'm integrating with web services (or, if I'm building those web services), I always ensure that I have an up-to-date Swagger file (or other endpoint schema model) before I begin writing the code that will consume those services. If others don't build their code in the same way, that's fine. But I'm not going to abandon the best way that I know to deliver quality code simply because others eschew those methods.

So my point here is that, while it would be great if your whole team was on the same TDD page, you don't need to confine TDD to being a team-level decision. If you find that you are writing better quality code by using TDD methods, then do it.

Contract-Driven Development

Another recent "aha" moment, for me, has been that, IMHO, TDD isn't really test-driven development, it's contract-driven development. What do I mean by that??

Well, in the examples above, I explained how I don't start building a database-driven application until I've either designed the database schema, or I at least understand the existing schema. Because the data layer, in many respects, defines what your application can-or-cannot do. So if you're trying to build features without understanding the underlying data model, you're probably setting yourself up for some nasty rewrites down the line. If I'm integrating with endpoints, the same concept applies.

But what about when you're writing code that doesn't directly hit a database or an endpoint? Is there any particular data contract that you need to be aware of? Yes.

Almost all code contains a proliferation of smaller code bits. Those "bits" are typically called methods, or functions, or components. Methods / functions / components all share some common features. Specifically, each one expects zero-to-many inputs, and they all return zero-to-many outputs. Those inputs and outputs are... your data contract.

When you first started coding, you probably began by cranking out functions (or methods, or components) where the inputs-and-outputs where defined "on the fly". You added new inputs (arguments) as needed. And you added new outputs (return values) as needed. And when you were done, hopefully the function did what you wanted it to do.

TDD flips that equation around. It forces you to define (and thus, think deeply) about exactly what those inputs/outputs should be before you ever begin writing the function. In other words, TDD forces you to define the data contract for a function before you ever write the function.

Continuous Feedback

TDD has another benefit that I believe is rarely discussed. This benefit is that of continuous feedback. If you've worked in any professional dev environment, you're probably accustomed to feedback. You receive it every time you submit a pull request, or any time your team does broader code reviews. If you're accustomed to pair programming, you may also receive live feedback in real-time.

But coding is often a solitary experience. Unless you're doing a live coding session, your first real feedback on any piece of code often comes at the point when you feel your code is completed and you're submitting it to be reviewed/merged. But if you're following TDD, you start to receive that feedback from the moment that you begin coding.

By defining the tests first (tests which should, initially, fail - until you complete the code), you're defining, upfront, a data contract. And then, as you write that code, the tests continually tell you whether or not it passes. This is doubly useful once you move on to refactoring your code.

While there's nothing inherently "wrong" about coding outside of TDD, there are some worrisome behaviors that often exist when people are coding without it. For example, most non-TDD devs don't even bother to run the tests until they've "completed" their code. Only once they notice that something's failing (and thus, they can't commit it) will they start to pay close attention to the tests. But TDD devs are much more likely to have the tests running during the entire time that they're coding. They do this because they're constantly getting "feedback" on the code that they're writing - and they can correct errors much earlier in the process.

Non-TDD devs are also much more likely to craft tests that encompass cognitive biases. (Specifically, confirmation bias.) They write code. Then they slap some tests on it. And do the tests pass? Of course they do! Because, whether they realize it or not, they've written tests that are designed to pass what they've written - rather than writing tests that are designed to confirm the desired functionality.

In this model, the tests are not providing continuous feedback. They're only providing "feedback" after-the-fact. Even worse, this "feedback" too-often only serves to confirm what the dev has already coded.

Time Crunches

The biggest problem that standalone TDD advocates run into is: the time crunch. There's been a lot of research that indicates that, in the long run, proper adherence to TDD should save you and your team time. But in the short run, TDD practices can feel like a burden.

Any time you need to spend significant effort pre-planning your work, that's an additional time burden. If you're writing your tests first, and you're putting in significant effort to ensure that those tests are meaningful and helpful, then that absolutely qualifies as "pre-planning". So it is possible that, on at least some of your tasks, a TDD approach will make you look slower in the eyes of your fellow devs. This is especially true if those devs don't follow TDD practices.

Consider the following potential scenario:

Your team hasn't adopted TDD as a standard. Of course, you can still write your code with TDD. But sometimes the difference in approaches will be apparent as you work through a sprint.

Imagine that Joe is on your team. He can't be bothered with TDD. You've both been given tasks of similar scope, each estimated to take a day of effort.

Joe finishes his task by noon. Joe's actually a really good developer, and his code looks fine. (Remember: Being a non-TDD developer doesn't mean that you're a bad developer, despite what any TDD fanboys may claim.) At the end of the day, you haven't quite finished your task, and you let your team lead know that you'll need a little more time before you submit the code.

Is there a risk here that you'll come to be seen as something of a "lesser" dev? Well, to be perfectly frank with you, the answer is "Yes". If the broader team doesn't embrace TDD, and all they see is that Joe finished a task, estimated at one day, in half a day, and you completed a similarly-estimated task in more than a day, this could lead some to hold you in less regard. But honestly, if that's the way your team judges work, then you may need to think carefully about whether this is the right fit for you long term.

Of course, over time it should become apparent to your colleagues that your methods yield solid code that's prone to fewer reworks. But I also wanna be frank with you: Some shops will focus, myopically and brutally, on nothing but raw time.

But I'd encourage you to think about it this way:

If someone wants me to start developing an endpoint-driven application, but they can't/won't give me the schemas I can expect from those endpoints, and they won't let me develop the endpoints myself, then I'm simply not going to start cranking out code just to satisfy someone who wants to know that I'm coding. (Even if that coding is blind.) I simply won't do it. And if that causes a problem with my team, I'll find somewhere else to work.

Similarly, when you're adhering to TDD, you're taking the time to define your own data contract, upfront, before you ever begin the "real" work of coding. You shouldn't be afraid to follow that approach. And if that causes ongoing problems on your dev team, then you really should consider finding a team that will support quality coding.

TDD As A Personal Directive

In conclusion my central point is that, previously, I always saw TDD as a team-based decision. We either adopted it for the entire group - or we didn't, and I ignored it altogether. But it doesn't have to be like that.

There are many aspects of dev where I've learned, over years of experience, what works best for me to deliver quality code. When I encounter those scenarios again, I don't ask someone's permission to write the code in the best way that I know how. I simply do it.

TDD can be that type of personal directive. Yes, it would be ideal if everyone on your team feels the same. But if you find that you can write much better code by using TDD, then... do it.

Thank You For Your (Worthless) Comment!

Adam Nathaniel Davis — Thu, 30 Mar 2023 06:13:35 +0000

I think one of the things that defines a "programming mindset" is the desire to improve processes (for example: automating them). When a programmer sees manual work being rotely repeated, he has an innate desire to streamline it. This often takes the form of writing more (or just... better) code. But it can manifest in other ways.

For example, when I noticed that I would often get the same inane questions from recruiters - often, in relation to "opportunities" that I had no desire to pursue - I reworked my LinkedIn profile to speak directly to those questions. Hopefully, so that I wouldn't need to keep answering them over and over again. I then built my CV/portfolio site with many of the same objectives in mind.

Granted, this doesn't stop the stream of inane questions. But I have noticed that it does in fact limit them. Some recruiters still pay no attention to what's on my LinkedIn profile, or what's on my CV site. But many others have read what I've written before we even have our initial conversation. And it's saved me both time and aggravation.

So, in a similar fashion, I'm writing this article as a way to "automate" the process whereby some "Dev Bro" leaves a snotty and unhelpful comment on one of my articles. Going forward, I'm not gonna engage the jerks anymore. My only response will be to drop a link to this article... and then leave it alone.

The Dreaded "Comments Section"

There's an old truism about the web. It was probably coined as far back as the early 90s. But it's still completely apropos today. It simply states:

Never go into the comments section!

It seems that the comments section is where the swarthiest sector of the web spends most of their time. For example, on the website for my local paper, I long ago realized just how loathsome the comments section can be. Every alt-right redneck in my southern city feels shamelessly empowered to share their deepest darkest thoughts on our local paper's articles. I've encountered some of the most racist/sexist/homophobic comments that I've ever heard after I scrolled just a bit too far down the page on our local news articles.

So, on most sites, it's a good rule of thumb to simply close your browser tab or click off the site once you've reached the end of the article and you're starting to see the user-generated feedback. But why am I talking about this here, on Dev.to? Am I claiming that Dev.to's comments are anywhere near that bad? Thankfully, not at all.

The Dev.to Community

When I decided to start cranking out articles on Dev.to, I did so, in part, because of the sense of community that I witnessed while reading the articles of others. The authors represent a wide range of skill sets, backgrounds, and experience levels. Of course, I've stumbled across my fair share of articles on this site that I would classify as, ummm... not good. But I usually have the sense that the vast majority of people on this site are truly trying to help one another. (Even if, occasionally, their articles are a bit misguided.)

I've always been particularly impressed with the quality of the comments on Dev.to articles. When some newbie posts an article with glaring flaws, I rarely see the commenters attacking him. Yes, they may challenge him. They often correct him. But on a large majority of comments, it does seem (to me, at least) as though the community is honestly trying to help each other.

For this reason, when I began writing my own articles, I made a conscious decision to make every effort to engage my commenters. Sometimes this takes the form of a simple "thank you" for their reply. Occasionally, it becomes a follow-on discussion - something of an "appendix" to the original article. No, I don't reply to every comment. But whenever it feels appropriate (or necessary), I try to acknowledge those who've taken the time to leave comments.

I can't even count the number of times that someone has challenged something I've written here and their input has led me to reassess and/or reformulate my own views. Sometimes, commenters simply point out typos or logical flaws in my article. (When that happens, I typically go back and edit the article to correct the error - after leaving a note thanking the commenter for the insight.) Other times, commenters have shown me really cool new ways to accomplish something - methods that I'd completely overlooked in the original article.

Malcontents and Dev Bros

This doesn't mean that every comment is helpful. Nor does it mean that all comments are left in the spirit of "community". Dev.to couldn't possibly enforce any kind of sweeping "don't be a jerk" policy. And if you write even a handful of articles on this site, eventually you'll run into a few of those jerks.

Of course, one "answer" to this problem would be to simply ignore the comments altogether. But for the reasons stated above, I believe that would be a sad mistake.

Another approach is to simply grow a thicker skin. Blogging is one form of putting yourself "out there". And whenever you expose your thoughts/feelings/ideas to the teaming cesspool that is The Interwebs, it's inevitable that, occasionally, some snotty little Dev Bro will get his jollies by taking a swipe at you.

For the most part, that just comes with the territory. If you can't handle the occasional jerk putting his oh-so-witty commentary on your articles, then... don't write articles for public consumption. And to be clear, I practice this approach of "skin thickening" on a near-daily basis. At this point in my blogging life, and at this point in my overall career, I no longer have "skin". I have a tough, leathery hide.

I will also freely acknowledge that my particular style can sometimes invite the Dev Bros to sharpen their knives. I'm opinionated. I make bold assertions. I enjoy calling out the many different flavors of effery that I've encountered over the last quarter century. The articles I write, while not obscene, are not designed to be presented, verbatim, in a corporate board room. And when I write in such a fashion, a certain subset of malcontents feels empowered to showcase their Keyboard Commando skills. And when they do, I make every attempt to simply ignore those jerks.

Nevertheless, every so often I feel compelled to engage one of them. And that's why I'm writing this article. Consider this my "final word" on any Neanderthal who thinks he's gonna raise himself up by taking me down a notch.

Ohhh... The Delicious Irony!

One of the funniest aspects of these Dev Bros is their utter inability to grasp the irony that's often present in their own comments. I've covered many different topics on this site. But if you read even a handful of my articles, you may notice one theme that pops up over and over again.

Often, I'm not railing so much against any particular piece of tech, or any particular aspect of coding life. Instead, I'm railing against the jerks who can't discuss such things in a rational, professional manner.

Like... maybe you love TypeScript. And you're convinced that our next project should be written in TypeScript - and not JavaScript. OK. That's fine. I may not entirely agree with you. But I'm more-than-capable of having a rational discussion with you about it. In the course of that discussion, you can present your case. I can present mine. We can talk about the pros-and-cons of either approach. We can loop in other team members to gather their feedback on it. And at the end of the day, we can come to some sort of consensus on a logical approach.

And when I say "logical approach", that's not a snide code word for my preferred solution. Just a few months ago, at Amazon, I had this exact same debate with another senior dev on our team. He wanted to use TS. I wanted to use JS. We hashed it out. We talked to the rest of the team. And you know what we decided on? We decided to use TS. And guess what??? I was fine with it!

But when some Dev Bro leaves a nasty comment on your article, he's "outing" himself as one of those jerks who's incapable of having this kind of rational conversation. Not that he cares, of course. He only cares about feeling like he's just put you in your place.

Smarmy Tech Douchebags

At this point, you may be thinking:

OK, fine. There are some idiots who put snotty comments on blogs. But why are you writing an article on a tech/programming website, about commenters???

To be fair, you don't have to be in software development to experience jerks in your life. Douchebags exist in every industry and in every corner of our daily lives. But I'm a firm believer that software development fosters a certain outsized population of douchebags.

No, I'm not claiming that all programmers are jerks. The vast majority of my past-and-present colleagues are very nice people. Smart. Funny. Genuinely interested in doing a good job and getting along with their coworkers. But I do honestly believe that, if we woke up tomorrow and every "jerk" was painted neon green, there'd be a higher percentage of neon green people in software engineering than you'd find in many other career fields.

Software development has a way of rewarding douchebags. You see, programmers are problem solvers. And once you've solved enough problems on enough critical projects, it's easy to fall into the mindset that you've got all the answers. It fosters mindsets like these:

"I used to work on an Angular project that was an absolute nightmare. And now you want to use Angular?? Mannn... you must be an idiot."
"I've been doing this stuff for decades. And now the New Guy thinks he can just step in with a better suggestion on how to solve this problem? Give me a friggin break..."
"You've done decades of work with SOAP and REST, but you've never used GraphQL? Then there's obviously no way you could work on this team."
"Oh, you didn't fit well with your previous team/employer? Hehehe... Sounds like you must be the problem!"
"I know why you're not a fan of pair programming. Cuz you don't want another dev to see that you suck."
"I wrote that solution in an hour. It took you two hours?? Sounds like you're just not cut out for this team."

Of course, I could go on (and on, and on...), but you probably get the point.

Developer Subspecies

When someone leaves a nasty comment on your blog, they don't realize it, but they're usually signaling that they belong to one (or more) of these nasty subspecies:

The Fanboy - They love Package X. You've never used Package X. Or maybe, you prefer Package Y. So of course, you're stoooopid. This can also apply to broader dev practices. Like, they love TDD. You haven't used TDD. Or you have critiques of TDD. So again... you're stoooopid.
The Corporate Apologist - You didn't have a good experience working for Company X. You write about your negative experience, but no matter how you explain the scenario, everything that went wrong was obviously your fault. And if you weren't such a crappy developer, you would've done just fine in your previous role. You can describe a situation where you delivered a bug-free product that went live five minutes after the expected deadline, and that your employer responded by caning you until you fell into a bloody coma, and The Corporate Apologist will tell you that a "real" developer would've had the solution deployed on-time and that you're just not fit to work on software.
The Code Nazi - There's one way to code - and that's exactly how The Code Nazi does it. If your code doesn't mirror his, you don't know what you're doing and you're not fit to work on his team.
The Time Cop - In The Time Cop's world, there are two classes of problems. There are "easy" problems - meaning, problems that he's already solved before. And now he can crank out the solution with incredible speed. And then there are "hard" problems - which are just... problems that he hasn't run into before. If it's an "easy" problem, then you're expected to code the solution in the time that it would now take him to do the same thing. If you take longer to solve the problem (even if it originally took him DAYS to solve it), you're not good enough to code on his team. It doesn't matter if it took him six hours to code his first binary tree search. Now that he can do it in 30 minutes, he expects that any "quality" coder should have already encountered the problem, and should be able to do it in 30 minutes as well.
The Benchmark Troll - He once spent an entire weekend running a massive series of performance tests on for() loops versus .forEach(). And now that he knows that for() is 0.2379% faster, you're an absolute idiot if you ever use .forEach().
The Speed Reader - He's a busy man. He's incredibly important! So important, in fact, that he can't be bothered to take the time to read your article. Which is fine, but curiously enough, he seems to have plenty of time to comment on your article and, in a display of sheer arrogance, correct your article. It doesn't matter that he merely skimmed the first 7% of the article. He now feels compelled to write up a "correction". In fact, sometimes The Speed Reader will boldly acknowledge, at the beginning of his comment, "I wasn't able to read most of your article, but...".
The Snarkster - You've written a 10,000-word magnum opus on a new coding technique involving React Hooks. Not only have you explained the concept in excruciating detail, but you've also laid out numerous coding samples, and you've even linked to several working CodePens that demonstrate your approach. Because he's so epically enlightened, The Snarkster leaves a single mind-expanding comment like, "Wow. This is ugly." <SlowClap/>
The Opinionator - You've written a pure opinion piece. You've gone to great lengths to make it clear that this is just your opinion. You've even admitted, numerous times in your article, that you may not have all the info and there's room for competing opinions. Despite all of this, The Opinionator still feels compelled to drop his comment stating that your opinion is... stoooopid.
The Dogmatist - You've written an extensive article on a new way to do two-way data binding in JavaScript. You may have even acknowledged that two-way data binding isn't everyone's "cup of tea". But for those who want to pursue it, here's one approach you can take. The Dogmatist absolutely must comment to let you know that two-way data binding is BAD and you should be kicked off the interwebs for even having the gall to propose such an approach. He won't give you one iota of constructive feedback on the actual details of what you've outlined. He's just gonna browbeat you for being stoooopid enough to even suggest the idea.
The Entertainer - The Entertainer paid a whopping $0.00 for the privilege of reading your article. And if he's not thoroughly entertained, he's gonna let you know. He'll be quick to label your article as "clickbait". He'll whine about how boring your article is (as though he was strapped to a chair and forced to read it). The one thing he absolutely will not do is provide any kinda substantive feedback on the content of your article.
The Last Senior - If The Last Senior isn't tickled pink with your article, he'll cough up one (and only one) retort: He'll call you a "junior dev". He has a massive stamp on his desk that says, "JUNIOR". When he decides that your article doesn't meet his Holy Standards, he literally mashes the stamp against his own monitor. Then he sits in the dank basement of his mom's house, laughing uncontrollably for the next 45 minutes, because he's in awe at how he massively PWND you by calling you a "junior dev". The whole escapade concludes when he posts the screenshots of his sweet dig on 4Chan. When he's not branding inadequate bloggers as "juniors", he spends the rest of his time repeatedly checking his DMs, waiting for that magical moment when Dan Abramov finally agrees to hang out with him.

This is far from an exhaustive list. But again, you probably get the point.

Just... Don't Be A Jerk

You may have heard before that, before you say anything, you should always ask yourself:

Is it true?
Is it kind?
Is it necessary?

The defining feature of a Dev Bro is that they never go beyond point #1. (And sometimes, they don't even make it that far.)

There are a lotta ways to benefit from the Dev.to community. Some people just lurk. And you know what? That's fine! Some people write their own articles - although no one's forcing you to go that far. And of course, you can always comment, if you're so inclined.

And I'm not trying to tell you that all of your comments must be sugar-coated. Occasionally, someone writes something that just really needs to be... challenged. There's nothing wrong with that.

But if your "challenging" comment can't be bothered to at least consider those three questions, then you're not contributing anything at all. You're just screaming to the Dev.to community that you're an asshat.

What It Was Like To Code For Amazon (Conclusion)

Adam Nathaniel Davis — Mon, 27 Mar 2023 06:01:46 +0000

(You can read Part 1 of this article here: https://dev.to/bytebodger/what-it-was-like-to-code-for-amazon-part-1-5034. And Part 2 here: https://dev.to/bytebodger/what-it-was-like-to-code-for-amazon-part-2-5aon)

If you've read any of the first two articles from this series, you already know that my Amazon experience was... suboptimal. But the first thing I have to acknowledge is that I don't actually know what it's like to code for Amazon in general. In fact, even if you've coded for Amazon in the past, or even if you're coding for them now, you don't know what it's like to code for them in general. The company's far too big and there are far too many devs strewn across myriad teams and locations for any single person to say, with authority, exactly what the overall dev experience is like.

In a company that large, all you can really do is assess your own experience. Some people may have had experiences similar to mine - or worse, even. But I'm also certain that some Amazon coders are perfectly happy there. It all depends, to some extent, on exactly which team/group you worked within, who exactly you worked for/with, and of course, what you brought to the experience.

But while I can't paint a broad, definitive picture of exactly what it's like for anyone, in any Amazon team/group, I did see enough to draw some curious conclusions.

Lip Service To "Principles"

Amazon constantly touts their "Leadership Principles". They ask you about them when you're interviewing. They talk about them in company meetings. On the surface, at least, they pour a lot of effort into these principles. (If you're curious, you can see them all here: https://www.amazon.jobs/content/en/our-workplace/leadership-principles)

Unfortunately, a lot of this emphasis is empty talk. (I know, I know. A megacorporation that doesn't always live up to its own stated ideals. SHOCKING!!!) I could go through them one-by-one and nitpick them based upon my short tenure there. And my perspective is, undoubtedly, biased by my own negative experiences and my own (admittedly brief) tenure. But in my experience, the most glaring example of a completely-failed "principle" is this:

Have Backbone; Disagree and Commit
Leaders are obligated to respectfully challenge decisions when they disagree, even when doing so is uncomfortable or exhausting. Leaders have conviction and are tenacious. They do not compromise for the sake of social cohesion. Once a decision is determined, they commit wholly.

I saw so many examples that made this principle an outright joke that I can't even list them all here. And I'm not just talking about my experience. I'm talking about things I witnessed in other areas of the organization, and things I was told directly by other employees.

I witnessed so many instances where people were simply afraid to speak up. I sat in meetings where no one but the "talking head" dared utter any kind of objection. And when they did bother to raise concerns, I also saw where those concerns were bulldozed because there was no alternative that pleased management.

A Telling Observation

When I wrote this article about working at Amazon (https://dev.to/bytebodger/what-its-like-to-code-for-amazon-4nke) a senior dev from an entirely different part of the company reached out to me on Slack. He praised the article, thanked me for writing it, and said he was glad to see that I was getting along nicely.

I thanked him for his feedback. But I also told him that, in the time since I wrote the article, I'd run into some very difficult situations. (I didn't deluge him with the full, insanely-long story of everything that had happened. I just gave him the high-level bullet points.) His response was very telling.

He was Australian. He told me that, in his previous job, there were many times when the dev team would be discussing some particular bit of an application that had already been built. And frequently they would find themselves saying to each other, "Yeah... this is all a bit crap, isn't it?"

But he also told me that, when he came onboard at Amazon, he had very similar problems. Because, for a good bit after he was hired, no one wanted to hear any kinda dissenting opinions - even if they were only "dissenting" as a means to talk out the problem and to (hopefully) come to a better solution.

His specific advice was to lay low for a good while. Don't say much. Just kinda "go along" with whatever was being dictated to you. And then, only after you've been onboard for a good bit, maybe possibly speak up about a few targeted things.

To be clear, I get this. I'd be the first one to tell you that no one wants the Brand New Guy to show up, on Day 1, and immediately tell everyone that they've been doing crappy work. And that the legacy app is shite. And that all of their current practices should be thrown out the window.

But there's a difference between being an arrogant know-it-all versus just being... a humble - but confident - member of the team. Sometimes some of the best suggestions come from the new guys. Because everyone else has grown accustomed to everything as "the way it's always been done". As long as the New Guy isn't a cocky jerk, there's a lot of value in seeing how someone views the situation with a fresh set of eyes.

That's what Have Backbone; Disagree and Commit is supposed to be about. If you see something that seems "off"... say something. Talk about it with your colleagues. Or your manager. Or your stakeholders.

Sometimes, when you raise those concerns, you'll be "voted down". And that's fine. Other times, you may find that people actually agree with you - but there are other practical reasons why it will continue to be done that way. And again - that's fine. But it's far healthier to at least have those conversations, rather than being afraid that you'll be labeled as a malcontent merely because you raised reasonable concerns.

A Big Brother Mentality

Here's something that I encountered multiple times at Amazon. And I found it to be a bit... disturbing.

I'd be chatting with someone on Slack about something that seemed "off". Maybe it was about a project. Or about a particular person. Or even about the company in general. And in these scenarios, with multiple different people, the Slack conversation would end when the other person typed this:

Maybe we should delete this Slack conversation?

Now to be clear, we weren't talking about bombing the CEO's house. We weren't calling anyone an asshole. In fact, we weren't discussing anything in those Slack threads that I woulda been afraid to say to anyone else, directly to their face. We were just discussing problems that we'd run into, and potentially how to fix them.

And yet, on numerous occasions, my Slack counterpart would close the conversation by suggesting that we delete the thread. Think about that... Honestly, every time I encountered it, it felt rather chilling.

Blatant Backstabbing

After coding for a quarter century, I've lost track of the number of coworkers who simply didn't like me. Work at enough companies, with enough colleagues, and it's inevitable that some people simply won't "take" to you. But that's not what I'm talking about here.

Despite all the interpersonal conflicts I've navigated throughout my career, there is only one company where I've experienced open backstabbing. And, yes, that company was Amazon.

When I say "backstabbing", I'm not referring to someone saying that I'm a jerk (take a number - it's a long line). Nor am I referring to someone badmouthing my code, or my deliverables, or anything about my work effort. I'm specifically talking about someone saying, to my face, that I'm doing great work. Then turning around, whenever a project suffers from any kinda setback, and telling everyone else that I've screwed everything up.

Throughout my career I've had people tell me, to my face, that they thought I really screwed something up. To be honest, once you get past the raw emotions of those moments, sometimes those interactions can end on an extremely positive note. But I've never been anywhere else where someone told me one (extremely supportive) thing to my face, and then told someone else (in senior management) the exact opposite when I wasn't there.

Frontend Myopia

The vast majority of Amazon's software engineers specialize in backend development. (Specifically, Java.) And there's nothing wrong with that. But the company's overall view on frontend development seems to be mired in 2015.

As a frequent Amazon customer, I'd noticed long before I ever worked there, that their UX was pretty, well... lacking. Now I know why.

To be fair, they successfully drive billions in revenue through their website. So I'm not gonna claim that their frontend interfaces are somehow "broken". And whenever you're operating a site that runs on that kinda epic scale, there are bound to be many considerations that simply don't apply to 99.99% of the other websites that are out there.

I'll also acknowledge that there are some teams in Amazon doing frontend work that utilizes modern standards. But it's kinda disturbing to see how many teams are oblivious to modern frontend capabilities. Heck, I even witnessed teams that were hostile toward any kinda modern frontend approaches.

In Amazon's internal knowledgebase, some lifelong Java coder wrote a long screed talking about how frontend apps (and modern frameworks - like React) were simply unmanageable and unscalable. It's quite a long read. Shortly after I came onboard, I was asking one of our Java devs why we were doing things a certain way. His response was... to send me that internal article.

Nevermind the fact that the article in question was written in 2017. And nevermind the fact that, on the article itself, there's long been a disclaimer, right at the top of the article, stating that most of its contentions are now in doubt. None of that mattered. All that mattered was that JS frameworks were "bad" (mmmkay...) and old-skool client-server architecture was "good".

A Silver Lining

My last observation comes with a bit of a silver lining (for me, at least). We all know that Amazon is just one of many Big Tech companies that's jettisoned scores of people in the last six months. While I understand that layoffs are, in a macro sense, a sad reality of corporate life, Amazon did everything they could to ensure that their internal and external communications around the matter were absolutely clumsy and, quite frankly, unprofessional. I'm not gonna go through all of that in detail here. I'm sure you've read the articles in the tech/business news.

Last month, a new bit of ugliness came from Andy Jassy. Effective May 1st, they're requiring everyone to be in the office at least three days per week. I'm sure that, in the final analysis, there will be some people who manage to get excused from this edict. But every indication so far is that there will be few exceptions.

In a sick sort of way, this actually made me feel kinda... relieved. You see, I live in Florida. I'm a remote worker. When I was hired, my offer specifically stated that I would be a remote worker. There were others on my team working under the same pretenses. And even if all the crap of the last year hadn't happened to me, and even if I was never laid off in January, I'd now be stressed and infuriated by the whole situation.

So I guess that, in the final analysis, the last year of "hell" wasn't gonna turn out any better for me, even if I never had any problems on my team and even if I was never booted under any of their layoffs. As odd as it sounds, that actually makes me feel somewhat "better" about the whole experience.

I'm not gonna make any attempt to sugarcoat this: What Amazon's doing now is an outright betrayal to the scores of people they hired over the last couple of years with the express understanding that they would be remote. It's also a betrayal to so many of their Seattle workers who made significant life changes (like... moving away from Seattle to other parts of the country) because they were given repeated assurances that they would not be forced to come back to the office.

Moving On...

I've put 112 articles on this site (so far). I wrote all of the others to, hopefully, spread knowledge, learn from the Dev.to community, and foster discussion. This little series of my-life-at-Amazon articles was the first time that I ever wrote anything here that was not for those purposes. I wrote these last three articles for me. As I stated in Part 1, this has basically been my self-administered therapy - a way for me to yell into the void about crap that I experienced over the last year.

That being said, this (not so) little tale is not a tragedy. Far from it. I'm currently evaluating one very-solid offer from a potential employer. I expect to receive a few other solid offers in the next coupla days.

The simple fact is that, regardless of where I'm working next month, and regardless of what anyone on here thinks about my Amazon tale - I'll be fine. Beyond fine, in fact.

As you've no-doubt surmised from these three articles, there are absolutely some aspects of my Amazon experience that still feel crappy as hell. And there was a period, mostly from November 2022 through January 2023, that all of this took a serious toll on my mental and physical health.

But you know what? That passes. Life goes on. And I'll be pissing people off at some new company before you know it.

Take care!

What It Was Like To Code For Amazon (Part 2)

Adam Nathaniel Davis — Sun, 26 Mar 2023 18:46:02 +0000

(You can read Part 1 of this article here: https://dev.to/bytebodger/what-it-was-like-to-code-for-amazon-part-1-5034)

Everyone was called to Seattle (FWIW, I live in Florida) for a big onsite meeting from October 17th to the 21st. The purpose was for a team-building event. But while we were all there it was a natural time to assess the current state of our almost-finished Big Project.

Given the myriad of headaches that I explained in Part 1, the original launch date of October 4th had been pushed to November 1st. My manager, Hardik, had communicated this new date to us repeatedly. But when we had our first onsite meeting on October 17th, he immediately stated that the project would be deployed that week.

When I brought up the fact that this hadn't even been thoroughly tested in the LLEs, he said, "That's OK. We can test it in production." Yes, that's right. Our manager was openly advocating for the feature - which had taken two months to develop - to be tested in production. This is the same manager who'd freak out and want everything rolled back if even the smallest bug was found in LLEs. But due to the deadlines he was facing, he was perfectly happy to deploy this package with the assumption that it would be tested in production. I was... not happy.

To be clear, when I say that I was "not happy", I don't mean that I was yelling or cursing at anyone. I wasn't trying to "fight" anything that we were trying to complete. But neither was I gonna sit in our team meetings and agree with his test-in-production edict. Nor was I gonna sit silently when he openly asked each one of us whether we thought it was ready to be deployed. I told him, in direct but professional terms, that this was not a good idea.

I wasn't the only one who objected. Other devs with far more experience on the team indicated that this approach was... problematic, to say the least. But it was also painfully clear that they were choosing their words very carefully. They knew what happens when you speak up.

This problem was exacerbated by Hardik's management tendencies. Whenever we were in meetings and he wasn't getting the answers he wanted, he'd keeping asking the same questions over and over again until everyone either agreed (through exhaustion) or simply shut up. And as soon as everyone was either browbeaten into agreement or had just decided to bite their lip, he took that as tacit approval from the team.

A Ray Of Sunshine... Blocked

During that week in Seattle, they also announced that our team would be split in two. There was a new manager, Chandana, and I'd be reporting to her in a few weeks. It's probably obvious that I saw this as a great relief.

I went back to Florida, we launched The Project From Hell, and everything seemed to be getting back to normal. But in the second week of November, which also happened to be Hardik's last week as my manager, he called a one-on-one meeting with me. In that meeting, he explained that I was being put under a 90-day Performance Improvement Plan (PIP). I was... floored.

First of all, the idea that you'd put someone under a PIP one week before they're moved to another team is absolute crap. There are certain tangible infractions that call for a PIP, regardless of the timing. Like, for example, a sexual harassment accusation. Sometimes, you can be written up for something technical, like introducing a change that breaks production. But this scenario was just downright... petty.

I wasn't the only one who thought this. In the pending re-org, we'd been moved under a new director. I had a number of great discussions with our previous director, related to this PIP situation. He agreed with me that it was poor form and highly unusual.

It was made worse by the fact that Hardik couldn't even cite any tangible examples of where I had supposedly performed poorly. He also gave me no tangible guidelines for how my improved performance could be measured. When I pressed him on this, he initially refused to give me any greater detail. I eventually had to involve HR, who informed him that he'd have to provide exactly what I was asking for. But when he finally did, his write-up was riddled with talking points that were verifiably false. I'm talking about tangible facts like dates and recorded conversations in which his PIP bullet points were in direct conflict with the data.

We had a senior architect in our group, Vince, who was above Hardik. Vince's blessing was apparently required on this PIP. So I interfaced with him directly. When we spoke, he indicated that Hardik wasn't the only one who thought there was a problem with my performance.

One of the other people who corroborated Hardik's account was Shawn, the tech lead for the project on which I was farmed out many months ago. I won't repeat that ridiculous scenario in this article - it's all in Part 1. But it was pretty deflating to know that his input was taken on this - when he repeatedly apologized to me about the state of his project and told me, verbatim, that they weren't even ready to have a frontend dev on the project yet.

Another person was Andy. Yes, the same Andy who repeatedly complained to me about Hardik's many shortcomings. The same Andy who told me, before he transferred out of the team, that he'd love to work with me again. But supposedly, in the single month that transpired between that conversation and this PIP, he'd gone on record as stating that I was somehow a problem.

Vince himself told me that, when I was in Seattle, he could tell there was a lot of tension between me and Hardik. And this was part of the reason why he went along with the idea of the PIP. Of course there was tension! Hardik was unilaterally moving up deadlines and openly advocating that we test everything in production. He was blatantly bulldozing any objections - and not just from me, but from his other senior team members.

It was painfully clear to me what had happened. Someone had to be the "fall guy" for the fact that the Project From Hell wasn't launched on its original target date. Guess who that fall guy was??

I have never felt more blatantly backstabbed in 25 years as a software engineer.

Moving Forward

For the next month, I resolved to do everything I could to close out that PIP and be The Best Possible Amazon Employee. I met with my new manager, Chandana, on a near-daily basis. And from every bit of feedback she ever gave me, she seemed to love me. She routinely praised the work I was doing. She told me that she wanted to get the PIP closed out early - as soon as possible. She never said or did anything that indicated, in any way, that she had even the slightest problem with my performance.

She even asked me to directly mentor a junior dev on our team. There were many, umm, "holes" in his knowledge and he was starting to withdraw. We started a routine of pair programming. I also met with him daily to review his work, give him pointers, counsel him on how to improve, and to generally pull him back into the fold.

I was put on a new project where I had to interface with one of our key stakeholders, a senior marketing director, Ted, in Germany. He repeatedly told me how happy he was with my work and how I was providing far more value than his contractors. In fact, I spent a good amount of time bringing his contracting team up-to-speed and correcting mistakes they'd made.

I also spent copious amounts of time documenting the state of the existing system, and writing detailed proposals to migrate it to a new platform. During that process, I engaged many other senior individuals both inside and outside of our team to review proposals and find consensus. I also helped several other marketing managers navigate hard-to-solve issues in our own app.

I scheduled one-on-one's with all the other members of my team. In those meetings, I openly told them that I was under a PIP and that I wanted any feedback (critical or otherwise) that would help me to improve myself and my contributions going forward. Most of those meetings ended with the individuals telling me that they didn't agree with the PIP at all.

A few people gave me a handful of minor points to improve upon. But it was pretty clear that no one on my team was bothered with me in the slightest. I talked with Andy's replacement - a guy named Cole. When I told him that I was feeling pretty worried about the status of my job, he told me directly that he'd be pretty upset if I was released.

Dark Clouds Gathering

Even though I was trying to "keep my chin up", it was still sometimes difficult to keep my head in a positive place. The news broke in late November that layoffs were coming. Our new director called a huge "all hands" meeting in which he spewed every lame, evasive bit of "corporate speak" that he could muster. I didn't speak up at all. But others did. And he did nothing at all to answer anyone's questions.

Chandana informed me that she was going to India for an extended vacation over the holidays. She told me that, before she left, she wanted to have my PIP closed out. Not only was she singing my praises, but she also got Ted to write up all the good work I was doing. Then she got Vince, the senior architect in our group (and the same one who'd originally put his "blessing" on the PIP) to confirm all the great work I'd done and that he'd heard nothing but positive things about my performance.

Nevertheless, the time came for her to go to India for three weeks and... my PIP was still in place. I knew that she'd actively pushed to get it closed out. I knew that she'd gathered supporting input from the most influential people in our group. And I knew that she failed. While she always strove to paint things in the best possible light, I knew that this was not a good sign...

The Great Hookah Incident of Christmas '22

The week before Christmas, after Chandana had already left for India, I was called into a last-minute troubleshooting meeting. There were probably 10 of us on the call.

Seeing as how it was last-minute (I was literally pinged on Slack with a request like, "Hey, can you please jump on this call? We're trying to figure something out."), I was sitting there at my desk (I work remotely) puffing on a hookah. This is nothing new for me. I often smoke a few hookahs a day while I'm working. It relaxes me. I've always enjoyed hookah.

I'd frequently been in standups, on camera, smoking a hookah. No one cared. In fact, some people had even laughed about it. I'd been on calls with my director while smoking a hookah. One of the other dev managers actually said to me once, "Ohh, man. Is that a hookah?" And when I confirmed that it was, he said that he's from Romania and he couldn't wait to smoke one when he went home. I was often smoking a hookah during my one-on-one video conferences with Ted, a main stakeholder who had advocated for the (failed) early closure of my PIP. He joked with me that I looked like a dragon.

But during this last-minute call that I was dragged onto, apparently someone else on that call was beside themselves. I learned, after the fact, that they spent a good chunk of that video conference taking screenshots of me. And once the call was finished... they reported me to HR.

Of course, I didn't know that any of this was happening. Instead, I got a generic meeting request from someone in HR whom I'd never heard of. The meeting had no subject. And I wondered for a bit whether it would be to discuss some aspect of my PIP.

When I got on the call with them, they told me that someone reported that I was smoking a vape during a video conference. I was, honestly, pretty dumbfounded. And confused.

I made no attempt to deny it. (Why should I???) I told her that it wasn't actually a vape. It was a hookah. But I also acknowledged that this distinction was probably beside-the-point. Then I said, "I'm sorry. I've read all of Amazon's corporate policies (and there are a ton of them) and I never saw where there's any policy against smoking a vape or a hookah during an internal video call." She replied that there is no policy against it. And that the only "infraction" would be around generic ideas of A) workplace conduct (Yeah... no shit. I'm not gonna drag a hookah into the corporate office and start smoking it. I'm not stupid.), and B) general ideas of "professionalism".

Although I was flabbergasted (and more than a bit annoyed) that I was being "reported" for something that even HR had to admit is not against company policy, I told her, in no uncertain terms, that I apologized and that it would never ever happen again. She seemed perfectly fine with this.

I told her that I'm currently under a PIP and asked if this was gonna impact that assessment. She said, "No. We just have to record that we've talked to you about it." And... that was it. The call lasted all of 15 minutes. She told me there would be no further repercussions from this "incident".

But I knew better...

Waiting For The Axe To Fall

Although HR claimed that the Hookah Incident would have no further impact, I pretty much knew that was complete BS. Everyone I knew in our team/group was openly telling me that they my work was great and they were advocating for the PIP to be closed out. But that... didn't happen. My manager was literally on the other side of the world. A massive round of layoffs was looming. Then you add this silly hookah incident to the mix, and, well... I had major fears about how this would play out.

I lost insane amounts of sleep over the holidays. I developed a nasty cough which eventually led me to be a mucous-y and bloody mess. I was afraid I was going to lose my job and there wasn't a damn thing I could do about it.

Those fears were manifested after everyone came back from the holidays. I got a Slack message from Vince asking for some background info on this whole Hookah Incident. So I jumped on a call with him. And the news was... not good.

He was bothered. Not with me. But by the idea that the Hookah Incident was apparently being bandied about as some kinda justification for why I should be tagged for released. He directly confirmed that he'd been hearing nothing but good things about me. But our new director was apparently hung up on not only the fact that I was still under a PIP (which everyone wanted closed out - but he refused to do so), but now, also, I had "an HR complaint". An HR complaint about something that HR openly admitted is not against any corporate policy.

Vince was as supportive as he could be in our call. And of course, he couldn't give me any direct statement like, "You're gonna be released." But... I knew. I totally knew.

When Chandana got back from vacation, she was distressed. She also could not say anything like, "You're gonna be released." But she knew. I knew. We both knew. And she wasn't happy about it. At all.

My last week at Amazon, I wrapped up every open task on my plate. Chandana had me do some "transition activities" with our PM and another of the senior devs on our team. When I met with them, they both asked me, "Why are you doing this?" I replied, "Because I'm gonna be released next week." They didn't wanna believe me. But they knew that they had to absorb whatever handoff info that I could impart to them.

On the morning of January 18th, I went out for a long breakfast. I had cocktails. Why not??? I got back to my desk at about 9:30AM. (Most of my team is West Coast, so it's not like anyone was expecting me to be online before then anyway.)

At 10:00AM, I received the email. (All of the victims at Amazon were laid off via... email. There was absolutely no human interaction.) And just like that... it was done.

In the final installment of this diatribe, I'm gonna outline some of the dystopian aspects of Amazon's corporate culture that I witnessed during my 10 months in the fold. Stay tuned for Part 3...

What It Was Like To Code For Amazon (Part 1)

Adam Nathaniel Davis — Sat, 25 Mar 2023 20:55:27 +0000

Last year I wrote a couple articles about my "Amazon journey". You can read them here https://dev.to/bytebodger/how-i-got-hired-at-amazon-3ajl and here https://dev.to/bytebodger/what-its-like-to-code-for-amazon-4nke. My Amazon "career" lasted all of 10 months. On January 18th, Amazon released 18,000 workers. And I was one of them.

I've hemmed-and-hawed over writing this article for a few months. The first few times I tried to write this, it was wayyyy too bitter, and it would've come across merely as "sour grapes". So I scrapped those original drafts. But now, after having a few months' separation from the Amazon machine... I think it's time.

I'm gonna be frank here. This article is basically my own self-administered therapy. If it doesn't strike you as being "professional" or if you feel like hopping into the comments and deriding me for my opinions, well... I really couldn't care less. You can write your own blog post about how I'm an idiot, or about how everyone jettisoned from Amazon deserved what they got, or about how this is all just "the way of the world". But this is my post. And I'm gonna explain things exactly as I experienced them.

Laying My Cards On The Table

Before I get into details, I wanna be dead-honest about a few key points. First, there's nothing about my experience that can be taken as a blanket statement on Amazon as a whole. The company is huge. Their workforce - even after the layoffs - is huge. There are still more than a million Amazon employees. And even if we filter out all the non-coders, it's still a massive workforce. So if you worked at Amazon in the past, or if you work there now, your experience may be completely different from my own.

Second, I can honestly tell you that I was "all-in". I sincerely hoped that Amazon would be my last employer. I really wanted to make it work. So it's not like I came onboard at Amazon trying to "make waves".

Third, it would be really easy in this situation to point to the company-wide layoffs and insist that my removal had nothing to do with me. Afterall, they cut 18,000 people (and they just announced another 9,000 impending layoffs). So I could easily fall back on the comforting bromide that I was a victim of broader market forces. But that would be... wrong.

No one else on my team was released. I was singled out. And it caused me an extreme level of mental anguish from November of 2022 through January of 2023.

So what exactly went wrong? Well, let's dive into that...

Living On An Island

In a quarter-century of software engineering, I've never worked at any company where I felt quite like I did at Amazon. Like I was working on an island. I was hired into a team of backend devs who were accustomed to working only in Java. And to be clear, that's fine. I'm a Java dev myself. But I was specifically hired to work on the frontend app.

No one on my team could even tell me how to run our app locally. No one. You may be thinking, "Well... what's so hard about npm start?" But you could not run our frontend app with npm start or yarn or any other tools that are customary for frontend devs.

When I came onboard, there were a series of instructions in the repo to tell you how to get the app running. They did not work. At all. It took me a few weeks to even figure out how to get the app running in a test environment. And I had to figure it out by myself, because when I reached out (repeatedly) to other devs on the team to figure out how to make it all run... they were clueless.

Even when I did get it running, the "default" configuration was to run everything on an EC2 instance (internally referred to as your Cloud Desktop). And that may have been fine. Afterall, I've worked on EC2 instances before. But the only way to make it run on EC2 was to do a complete compile-and-push of the entire app - meaning, frontend and backend code - that took 13 MINUTES every time I wanted to test my changes.

Everyone else on the team seemed to think that this was just "business as usual". They couldn't seem to understand why I was exasperated to learn that every single code change would take 13 MINUTES to verify.

Granted, I did eventually figure out how to sync my local environment in real-time to the EC2 instance. But it took me a long time to work that out. Once I had the sync running, I could see my changes on the EC2 instance in about 10 seconds. But I had to work that all out on my own, because none of the existing documentation gave any clue as to how I could make that work.

Once I figured this out, I documented all of the steps so that future devs would never need to go through the headache I'd experienced. But I could already tell that my manager, Hardik, was growing exasperated by the delay before I could write new code efficiently.

Even with no meaningful guidance, my path to efficient development would've been much smoother if I wasn't working on a Windows machine. When I was hired, several weeks before my start date, I received an email asking me if I wanted a Mac or a Windows machine. Although I've worked on Macs, I've always done much more work on Windows (yes, I know, this is unusual), so I simply replied that I'd like a Windows machine. That was a big mistake.

All of the internal Amazon documentation starts from the assumption that you're on a Mac. Even after I "translated" many of the commands from bash to PowerShell, I still encountered many roadblocks that were maddening to solve. There were many command line utilities they expected you to use that simply would not run on a Windows maching. Although I eventually did solve everything, after I'd been there for a couple months, I finally said, "Can you guys just send me a Mac?"

To be fair, they did in fact send me a Mac. But by that point, I was already seen by Hardik as someone who was lagging behind.

Farmed Out

Once I finally reached a state where I could efficiently code in the environment, I was immediately farmed out to another team on a short-term, high-priority project. Of course, that project came with a whole other docket of onerous setup requirements.

I was the only frontend dev working on this new initiative. When they introduced me to the project, they pointed me to the repo - but it wouldn't even compile. In fact, I'd get on a conference call with the team lead, Shawn, and it would take him hours to get the app running locally.

When we went through these sessions, Shawn repeatedly apologized to me about the state of the project. He also told me, on numerous occasions, that they probably weren't even ready to have a frontend dev working on the project yet. But I was still expected to crank out frontend code.

They were building a brand new app. But the pipeline was configured to only accept ES5-compliant JavaScript. When I brought this up to them as a major red flag, they literally couldn't understand why I had any problem writing brand new code, in 2022, with vars - and all of the other ancient standards of ES5.

And those compilation problems didn't go away after the first time that I finally got the app running. I'd start working the very next day, after changing nothing in the code, and I'd find that, once again, the app wouldn't compile. It didn't compile because the backend devs were constantly changing key parameters of the app. But those parameters were not all checked into a cogent changeset. So even if the app worked perfectly fine yesterday, I'd get latest when I started working the next morning and... nothing worked.

When this happened, I'd get back on a conference call with Shawn, and even for him, it would still take him hours to get the latest build to a point where it would simply compile. He'd still apologize to me about it the whole time. And he kept telling me that they really weren't even ready to have a frontend dev working on the code yet. But I was still working on the project. And nearly every day I ran into the same kinds of issues.

Even when I could get the project running, it was still maddening to figure out exactly what I was supposed to code. They kept telling me that I had to code for certain variables that would be coming from the backend. But those backend services weren't anywhere near being completed. And they couldn't even give me a mockup of what the data was supposed to look like. I was literally coding blind.

I'd conference with my regular manager, Hardik, every coupla days. And every time I told him that this project was a nightmare and that I really shouldn't be on the project at all until they'd figured out their backend issues. And Hardik agreed with me.

I also repeatedly told the team lead, Shawn, that my time would be best spent if I came back to the project a few months later. And he agreed with me. But it took more than a month before I was officially able to beg myself off the project.

Despite all these issues, that were acknowledged by my regular manager, Hardik, and by the team lead of the secondary project, Shawn, I learned a few months later that I was reported to senior management as being "difficult to work with". It was an absolute betrayal. But I tried not to let it bother me, because by the time that I received this information I was already moved back to my original team.

Back On The Reservation

At this point, I'd successfully navigated the insanely-obtuse process of working on my main team's frontend application. And I'd weathered the nightmare of the temporary project on which I was farmed out. But it was clear that my manager, Hardik, thought that I was somehow lagging behind.

He and I had a meeting where he suggested that I should just concentrate on cranking out code for our main app (it's called "Sonar"). He specifically recommended that I focus on trying to get 10 pull requests submitted over the next month.

I totally agreed with him and I dove into our "regular" work with aplomb. In fact, I had more than 10 pull requests submitted in the next week. But from that point forward, he continually talked about me as though I wasn't doing much work.

This situation continued on for several months. It actually got to the point where I showed him, with git commits, and pull request history, and completed tickets, that I'd completed more than four times as much work as anyone else on the team. But it just didn't seem to register with him. He'd always talk about me - to my face, and in group meetings - as though I was somehow failing to deliver.

I wasn't the only one who noticed Hardik's disconnect with reality. We had a senior architect, Andy, embedded within our team. He would routinely talk to me on Slack about how frustrated he was with Hardik. He told me that he'd reported these frustrations to our director. And he encouraged me to submit a report of my own experiences. However, I held back from doing so because, at that point, I'd still only been there for about five months and I really didn't think it would be a "good look" for the New Guy to be griping to the director about his manager.

Captain Rollback

I soon learned that Hardik was also Captain Rollback. In our codebase, we had a handful of ancient unit tests that were borderline useless. (Also, fun fact: No one knew how to run them and they weren't hooked up to the deployment pipeline in any way.) Even if you could figure out how to run them (I did), they covered such a small part of the app as to be useless.

There were also significant parts of our app that no one on our team even knew how to use. So between the worthless test "coverage" and the complete lack of institutional knowledge, the only real way to test your changes was to push them to your EC2 environment and check them manually. But without sufficient end-to-end knowledge of the app (which no one had), manual testing was hit-or-miss.

Perhaps because of these factors, Hardik was Captain Rollback. Whenever any bug - no matter how trivial - was discovered in a LLE, his first-and-immediate instinct was always to rollback the code. Of course, when you've just deployed to production and you found a bug, I can totally understand this impulse. Or if you have a production deployment pending in the very near future, I also understand this impulse.

But if there was any issue with anything I'd written - no matter how trivial the issue - he never asked what it would take to simply fix the issue. He immediately wanted to rollback.

On several occasions, after a bug was found in production, he wanted to rollback my latest changes in the LLEs, even though my changes had not yet been deployed to production. On other occasions, he wanted to rollback my code, even though the change I'd made had no conceivable connection whatsoever to the observed bug.

And I wasn't the only one telling him this. Other devs, with much more experience on the team, would tell him the same thing. But it didn't matter. Any observed bug led to an immediate knee-jerk directive from Hardik to rollback my latest changes.

The Project From Hell

Although I had some ongoing "issues" with Hardik, I was still intent on delivering solid work. And that "solid work" took the form of a big new project that had to be implemented in Sonar.

To be clear, this "big new project" didn't really seem like any kinda major project upfront. We went through sprint planning and I pointed my tasks as presumably taking several weeks. I was giving my estimates based on everything I knew about the app (and the newly-required features) at the time. But there was much that I couldn't have possibly understood about the requirements in the early stages...

We worked off a continuous deployment model. And even though my piece of the project seemed small, it was clear that the entire effort would take a few months. So when I started planning how to do my pieces of the project, it was clear that I couldn't just commit them upfront - because if I did, they'd get deployed to production and they would break because the backend pieces hadn't been completed.

I talked with our architect, Andy, about how to handle this. After talking through a few options, we both agreed that this should be deployed under a feature flag, so that my new pieces wouldn't break anything before the full project was released.

Then I asked him, "Can you show me in the codebase where we're already using feature flags, so I can follow the same methodology?" He replied that there was no existing feature-flag functionality in the codebase. And that was fine. I set about building a new feature-flag system. But of course, that set back my original estimates.

Granted, I copiously communicated this to the team every step of the way. I created new tickets to track the feature flag development. I repeatedly advised the team about the revised timelines during nearly every standup. I also built the feature-flag functionality to be "universal", so that it was highly configurable and could be used for any-and-all conditional features that may be needed in Sonar in the future. Nevertheless, Hardik was not pleased.

Shifting Data Models

Once the feature-flag functionality was in-place, I set about coding the original requirements for the project. The frontend functionality seemed, on the surface, to be pretty simple. Basically, we needed to account for a few new values coming from the API. Originally, I was led to believe that someone else would be altering the API. But I eventually learned that I would need to do it myself. Which was... fine. But that was never in my original estimates.

So I created new tickets to track the updating of our APIs. And I communicated this all to the team, repeatedly, during standups. Then I coded the Java updates to deliver the values that were needed.

Only after I'd done this, Andy informed me that my data model wouldn't "work". It's hard to explain here, but suffice it to say that, in their odd data model, I instead needed to infer the values based on a very convoluted set of other variables that would be returned from the API. Of course, I had no way of knowing that when I made my original estimates.

After I'd already coded a new Java API to handle what I presumed would be the new variables, Andy informed me that he would be spinning up his own set of APIs that I'd consume. Which meant that my previous Java API work was wasted. It also meant that the frontend code I'd written, which assumed it would be receiving the values I'd coded into the API, had to be completely rewritten. He was also unable to give me any kinda putative mock data that I could use to write new frontend code. In other words, I was stuck waiting on him to show me what the new data would look like.

I communicated all of this to the team, repeatedly, during standups, and I did what little frontend coding I could in lieu of any knowledge of the data model.

During this same time, Andy continued to tell me how frustrated he was with Hardik's crappy management. In fact, one day he scheduled a one-on-one meeting with me where he told me that he was transferring to another team. During this meeting, he also told me that, "If you'd ever like to move to another team, just let me know. I'd be happy to work with you again."

Deadlines Uber Alles

We were supposed to deliver this new functionality in the middle of October. We'd previously planned to have the functionality in our LLEs right around October 1st so we could begin testing. I finally received a mockup of the data model against which I needed to code my features on Friday, November 30th.

By Monday, October 3rd, Hardik was in a tizzy. He was trying to ping me on an hourly basis for updates about when my piece would be completed. I was cranking out code in a rapid manner. And I had done a good bit of "pre-work". But there was only so much I could do to finish the features that relied on a data model I'd only been given one business day prior.

By Tuesday night, Andy was pinging me on Slack and telling me that Hardik was gonna throw a whole bunch of other devs into the mix. Presumably, to implement the features that I hadn't been able to complete. (Again, these were the features that I could only really finish coding since the previous Friday.)

For the next week, I wasted a massive amount of effort. We had four different devs coding multiple features that resided in the same handful of code files. On numerous occasions, I went to submit a PR, only to realize that someone else had already submitted their own version of the feature. All of us were constantly dealing with merge conflicts.

Despite all of this anarchy, we got the features implemented and promoted to the LLEs. That's when I went to Seattle for a team onsite meeting in the third week of October.

Stay tuned for Part 2...

Embedding Data Into React/JSX Elements

Adam Nathaniel Davis — Wed, 22 Mar 2023 01:03:10 +0000

What I'm about to show you is really pretty basic. So Code Gurus out there can feel free to breeze on by this article. But I've rarely seen this technique used, even in "established" codebases crafted by senior devs. So I decided to write this up.

This technique is designed to extract bits of data that have been embedded into a JSX (or... plain ol' HTML) element. Why would you need to do this? Well... I'm glad you asked.

The Scenario

Let's look at a really basic function:



const getTableCells = (cells = [rgbModel], rowIndex = -1) => {
   return cells.map((cell, cellIndex) => {
      const paintIndex = colors.findIndex(color => color.name === cell.name);
      return (
         <td key={`cell-${rowIndex}-${cellIndex}`}>
            {paintIndex}
         </td>
      );
   })
}

This function simply builds a particular row of table cells. It's used in my https://paintmap.studio app to build a "color map". It generates a giant grid (table) that shows me, for every block in the grid, which one of my paints most-closely matches that particular block.

Once this feature was built, I decided that I wanted to add an onClick event to each cell. The idea is that, when you click on any given cell, it then highlights every cell in the grid that contains the same color as the one you've just clicked upon.

Whenever you click on a cell, the onClick event handler needs to understand which color you've chosen. In other words, you need to pass the color into the onClick event handler. Over and over again, I see code that looks like this to accomplish that kinda functionality:



const getTableCells = (cells = [rgbModel], rowIndex = -1) => {
   return cells.map((cell, cellIndex) => {
      const paintIndex = colors.findIndex(color => color.name === cell.name);
      return (
         <td
            key={`cell-${rowIndex}-${cellIndex}`}
            onClick={paintIndex => handleCellClick(paintIndex)}
         >
            {paintIndex}
         </td>
      );
   })
}

The code above isn't "wrong". It will pass the paintIndex to the event handler. But it isn't really... optimal. The inefficiency that arises is that, for every single table cell, we're creating a brand new function definition. That's what paintIndex => handleCellClick(paintIndex) does. It spins up an entirely new function. If you have a large table, that's a lotta function definitions. And those functions need to be redefined not just on the component's initial render, but whenever this component is re-invoked.

Ideally, you'd have a static function definition for the event handler. That would look something like this:



const getTableCells = (cells = [rgbModel], rowIndex = -1) => {
   return cells.map((cell, cellIndex) => {
      const paintIndex = colors.findIndex(color => color.name === cell.name);
      return (
         <td
            key={`cell-${rowIndex}-${cellIndex}`}
            onClick={handleCellClick}
         >
            {paintIndex}
         </td>
      );
   })
}

In the above code, the handleCellClick has already been defined outside this function. So React doesn't need to rebuild a brand new function definition every single time that we render a table cell. Unfortunately, this doesn't entirely work either. Because now, every time the user clicks on a table cell, the event handler will have no idea which particular cell was clicked. So it won't know which paintIndex to highlight.

Again, the way I normally see this implemented, even in well-built codebases, is to use the paintIndex => handleCellClick(paintIndex) approach. But as I've already pointed out, this is inefficient.

So let's look at a couple ways to remedy this.

Wrapper Components

One approach is to create a wrapper component for my table cells. That would look like this:



const getTableCells = (cells = [rgbModel], rowIndex = -1) => {
   return cells.map((cell, cellIndex) => {
      const paintIndex = colors.findIndex(color => color.name === cell.name);
      return (
         <MyTableCell
            key={`cell-${rowIndex}-${cellIndex}`}
            paintIndex={paintIndex}
         >
            {paintIndex}
         </MyTableCell>
      );
   })
}

In this scenario, we're no longer using the base HTML attribute of <td>. Instead, there's a custom component, that will accept paintIndex as a prop, and then presumably use that prop to build the event handler. MyTableCell would look something like this:



const MyTableCell = paintIndex => {
   const handleCellClick = () => {
      // event handler logic using paintIndex
   }

   return (
      <td onClick={handleCellClick}>
         {paintIndex}
      </td>
   )
}

Using this approach, we don't have to pass the paintIndex value into the handleCellClick event handler, because we can simply reference it from the prop. There's much to like in this solution because it's consistent with an idiomatic approach to React. Ideally, you'd even memoize the MyTableCell component so it doesn't get remounted (and re rendered) every time we build a table cell that uses the same paint color.

However, this approach can also feel a bit onerous because we're cranking out another component purely for the sake of making that one onClick event more efficient. Also, if the handleCellClick event handler needs to do other logic that impacts that state in the calling component, the resulting code can get a bit "heavy".

Sometimes you want the logic for that event handler to be handled right inside the calling component. Luckily, there are other ways to do this.

HTML Attributes

HTML affords us a lot of freedom to "stuff" data where it's needed. For example, you could use the longdesc attribute to embed the paintIndex right into the HTML element itself. Unfortunately, longdesc is only "allowed" in <frame>, <iframe>, and <img> elements.

Granted, browsers are tremendously forgiving about the usage of HTML attributes. So if you were to start putting longdesc attributes on all sorts of "illegal" HTML elements, it really won't break anything. The browser will basically just ignore the non-idiomatic attributes. In fact, you can even add your own custom attributes to HTML elements.

Nevertheless, it's usually good practice to avoid stuffing a buncha non-allowed or completely-custom attributes into your HTML elements. But we have more options. More "standard" options.

(Near) Universal HTML Attributes

If you wanna find an attribute that you can put on pretty much any element, the first things is to look at the attributes that are allowed in (almost) any elements. They are as follows:

id
class
style
title
dir
lang / xml:lang

The nice thing about these attributes is that you can pretty much use them anywhere within the body of your HTML, on pretty much any HTML element, and you don't have to worry about whether they're "allowed". You can, for example, put a title attribute on a <div>, or a dir attribute on a <td>. It's all "acceptable" - by HTML standards, that is.

So if you wanted to use one of these attributes to "pass" data into an event handler, what would be the best choice?

title

First of all, as tempting as it may be to use something like title, I would not recommend this. title is used by screen readers and you're gonna jack up the accessibility of your site if you stuff a bunch of programmatic data into that attribute - data that should not be read by a screen reader.

dir, lang, xml:lang

Similarly, you should avoid appropriating the dir, lang, or xml:lang attributes. Messing with these attributes could jack up the utility of the site for international users (i.e., those who are using your site with a different language). So please, leave those alone as well.

style

Also, you could try to cram "custom" data into a style attribute. But IMHO, that's gonna come out looking convoluted. In theory, you could define a custom style property like this:



<td style={{paintIndex}}>

Then you could try to read this made-up style property on the element when it's captured in the event handler. But... I don't recommend such an approach. Not at all. First, if you have any legitimate style properties set on the element, you're gonna end up with a mishmash of real and made-up properties. Second, there's no reason to embed data in such a verbose format. You can do it much "cleaner" with the other options at our disposal.

id

The id attribute can be a great place to "embed" data. Here's what that would look like:



const getTableCells = (cells = [rgbModel], rowIndex = -1) => {
   return cells.map((cell, cellIndex) => {
      const paintIndex = colors.findIndex(color => color.name === cell.name);
      return (
         <td
            id={paintIndex}
            key={`cell-${rowIndex}-${cellIndex}`}
            onClick={handleCellClick}
         >
            {paintIndex}
         </td>
      );
   })
}

Here, we're using the paintIndex as the id. Why would we do this? Because then we can create an event handler that looks like this:



const handleCellClick = (event = {}) => {
   uiState.toggleHighlightedColor(event.target.id);
}

This works because the synthetic event that's passed to the event handler will have the id of the clicked element embedded within it. This allows us to use a generic event handler on each table cell, while still allowing the event handler to understand exactly which paintIndex was clicked upon.

This can still have some drawbacks. First of all, ids are supposed to be unique. In the example above, a given paintIndex may be present in a single table cell - or in hundreds of them. And if we simply use the paintIndex value as the id, we'll end up with many table cells that have identical id values. (To be clear, having duplicate ids won't break your HTML display. But in some scenarios it can break your JavaScript logic.)

Thankfully, we can fix that, too. Notice that our table cells have key values. And keys must be unique. In this scenario, I addressed that problem by using the row/cell counts to build the key. Because no two cells will have the same combination of row/cell numbers. We can add the same format to our id. That looks like this:



const getTableCells = (cells = [rgbModel], rowIndex = -1) => {
   return cells.map((cell, cellIndex) => {
      const paintIndex = colors.findIndex(color => color.name === cell.name);
      return (
         <td
            id={`cell-${rowIndex}-${cellIndex}-${paintIndex}`}
            key={`cell-${rowIndex}-${cellIndex}`}
            onClick={handleCellClick}
         >
            {paintIndex}
         </td>
      );
   })
}

Now, there will never be a duplicate id on any of our cells. But we still have the paintIndex value embedded into that id. So how do we extract the value in our event handler? That looks like this:



const handleCellClick = (event = {}) => {
   const paintIndex = event.target.id.split('-').pop();
   uiState.toggleHighlightedColor(paintIndex);
}

Since we wrote this code, and since we determined the naming convention for the id, we also know that the paintIndex value will be the last value in a string of values that are delimited by -. If we split('-') that string and then pop() the last value off the end of it, we know that we're getting the paintIndex value.

class

class is also a great place to "embed" data - even if it doesn't map to any CSS class that's available to the script. If you're familiar with jQuery UI, you've probably seen many instances where class is used as a type of "switch" that doesn't actually drive CSS styles. Instead, it tells the JavaScript code what to do.

Of course, in JSX we don't use class. We use className. So that solution would look like this:



const getTableCells = (cells = [rgbModel], rowIndex = -1) => {
   return cells.map((cell, cellIndex) => {
      const paintIndex = colors.findIndex(color => color.name === cell.name);
      return (
         <td
            className={`${paintIndex}`}
            key={`cell-${rowIndex}-${cellIndex}`}
            onClick={handleCellClick}
         >
            {paintIndex}
         </td>
      );
   })
}

And the event handler looks like this:



const handleCellClick = (event = {}) => {
   uiState.toggleHighlightedColor(event.target.className);
}

Just as we previously grabbed paintIndex from the event object's id field, we're now grabbing it from className. How would this work if you also had "real" CSS classes in the className property? That would look like this:



const getTableCells = (cells = [rgbModel], rowIndex = -1) => {
   return cells.map((cell, cellIndex) => {
      const paintIndex = colors.findIndex(color => color.name === cell.name);
      return (
         <td
            className={`cell ${paintIndex}`}
            key={`cell-${rowIndex}-${cellIndex}`}
            onClick={handleCellClick}
         >
            {paintIndex}
         </td>
      );
   })
}

And the event handler would look like this:'



const handleCellClick = (event = {}) => {
   const paintIndex = event.target.className.split(' ').pop();
   uiState.toggleHighlightedColor(paintIndex);
}

The "cell" class on the <td> is a "real" class - meaning that it maps to predefined CSS properties. But we also embedded the paintIndex value into the className property and we extracted it by splitting the string on empty spaces.

To be fair, this approach may feel a bit... "brittle". Because it depends upon the paintIndex value being the last value in the space-delimited className string. If another developer came in and added another CSS class to the end of the className field, like this:



const getTableCells = (cells = [rgbModel], rowIndex = -1) => {
   return cells.map((cell, cellIndex) => {
      const paintIndex = colors.findIndex(color => color.name === cell.name);
      return (
         <td
            className={`cell ${paintIndex} anotherCSSClass`}
            key={`cell-${rowIndex}-${cellIndex}`}
            onClick={handleCellClick}
         >
            {paintIndex}
         </td>
      );
   })
}

The logic would break. Because the event handler would grab anotherCSSClass off the end of the string - and try to treat it like it's the paintIndex. If you'd like to make it a bit more robust, you can change the logic to something like this:



const getTableCells = (cells = [rgbModel], rowIndex = -1) => {
   return cells.map((cell, cellIndex) => {
      const paintIndex = colors.findIndex(color => color.name === cell.name);
      return (
         <td
            className={`cell paintIndex-${paintIndex} anotherCSSClass`}
            key={`cell-${rowIndex}-${cellIndex}`}
            onClick={handleCellClick}
         >
            {paintIndex}
         </td>
      );
   })
}

And then update the event handler like this:



const handleCellClick = (event = {}) => {
   const paintIndex = event.target.className
      .split(' ')
      .find(className => className.includes('paintIndex-'))
      .split('-')
      .pop();
   uiState.toggleHighlightedColor(paintIndex);
}

By doing it this way, the value that's extracted for paintIndex isn't dependent upon being the last item in the space-delimited string. It can exist anywhere inside the className property, as long as it's prepended with "paintIndex-".

Why Should You Care?

To be frank, in small apps, having something like this isn't exactly a federal crime:



const getTableCells = (cells = [rgbModel], rowIndex = -1) => {
   return cells.map((cell, cellIndex) => {
      const paintIndex = colors.findIndex(color => color.name === cell.name);
      return (
         <td
            key={`cell-${rowIndex}-${cellIndex}`}
            onClick={paintIndex => handleCellClick(paintIndex)}
         >
            {paintIndex}
         </td>
      );
   })
}

The performance "hit" you incur by defining a new function definition inside the onClick property is... minimal. In some cases, trying to "fix" it could be understandably defined as a "micro-optimization". But I do believe it's a solid practice to get in the habit of avoiding these whenever possible.

When the event handler doesn't need to have information passed into it from the clicked element, it's a no-brainer to keep arrow functions out of your event properties. But when it does require element-specific info, too often I see people blindly fall back on the easy method of dropping arrow functions into their properties. But there are many ways to avoid this - and they require little additional effort.

How to Get Your First Job as a Self-Taught Programmer

Adam Nathaniel Davis — Fri, 17 Mar 2023 07:00:54 +0000

A few years ago, I wrote an article right here on Dev.to called One Crazy Trick to Become a Programmer. (You can read it here: https://dev.to/bytebodger/one-crazy-trick-to-become-a-programmer-j8k) Since that time, I've received numerous emails and comments from aspiring coders who are still asking me how to break into the world of professional coding. So I've finally decided to take this a step further and provide some more-detailed suggestions on how to get started as a professional developer.

To be absolutely clear, I still stand behind everything I wrote in that original article. The "soul" of that article is just as applicable today as it was in 2020. But I'll also admit that the original article was a bit... glib. It was also very general - pounding away on the simple (but useful!) mantra of, "WRITE MORE CODE".

Recently, it's become apparent that some people just aren't sure how to translate the general bromides in that article into specific, actionable steps toward fulltime employment. So I'm gonna take it a step further by trying to provide more-targeted advice.

I'm also going to target this article specifically toward the self-taught crowd. I'm doing this for one simple reason:

I myself am entirely self-taught. I've never attended a code camp. I've never taken a single course (college or otherwise) on coding. Everything in my modest brain is there because, at some point, I had to sit down, by myself, and figure out how all this stuff works. So I guess you could say that I have a bit of a soft spot for other self-taught devs.

Of course, I realize that there are people with comp-sci degrees who are also struggling to get their first real programming jobs. And if you're in that crowd, there will still be some actionable nuggets of wisdom for you in this article. But my target audience is all the people who received no formal training in application development.

I'm also gonna write this mostly from the perspective of frontend development. But I think the lessons would apply equally if you're a self-taught backend dev. Just swap out some of the technologies that I mention for those that are more applicable to your scenario.

So... let's dive in.

Skills vs. Experience

The whole point of my "WRITE MORE CODE" mantra (from the original article) was that no one can magically give you experience. Experience only comes over time. But you can give yourself skills. And the only way you get more skilled as a programmer is to... write more code.

But I'm not gonna take all of this article to just keep hammering away on that mantra. I'm gonna suggest some things you can do to bolster your skills while you're searching for that first company that will grant you some experience.

The first thing is to tailor your employer-facing persona to focus on your skills, and not on your experience. This means that your resume should be skill-centric. Your website should be skill-centric (more on this later...). Any personal projects you take on should be focused on broadening your skills. Basically, you should be constantly thinking about what you can do to add more tools to your toolbelt.

For example, I see many newbies who've been diving into React. And that's great! There's broad demand for React devs and it's wise to have a solid grasp of the library. But many of these devs can do little else besides React.

Have you worked at all with jQuery? (Yes, that technology is getting a little long-in-the-tooth, but it's still massively used and it can teach you a lot about certain core JavaScript concepts - such as anonymous functions.)

How comfortable are you with JavaScript and TypeScript? They're used almost interchangeably today in the workplace and it can be a liability if you're a TypeScript wizard but you get uncomfortable if someone asks you to code something up in plain JavaScript (or vice versa).

Have you experimented, at all, with other frameworks like Angular? Or Vue? Or Svelte?

How about Node? It is, afterall, JavaScript. But it's amazing how many freshly-minted, so-called JavaScript devs can seize up at the site of a Node application.

I fully realize that, as a newbie in the field, it can feel incredibly daunting to have to tackle all these different "angles" of frontend/JavaScript development. And I'm not asking you to become a JS/TS/React/Angular/jQuery/Node/Vue/Svelte superhero all on your own. But the more of these skills that you can confidently boast about on your resume (and hopefully, during interviews), the better off you'll be.

The point here is that you can't make up a robust job history out of whole cloth. So you'll need to do everything you can to ensure that you can at least boast a well-rounded skillset. You're gonna need to find ways to build up a resume without relying on the one thing that shines in most resumes - a robust job history. That's why you need to focus so hard on bolstering your list of skills.

Do NOT Skimp On HTML/CSS

I could've shoved this under the prior section, but I'm listing it here separately because the modern code camp culture has, IMHO, spawned a small army of new devs who feel pretty good about their JavaScript skills - but have only basic knowledge of HTML/CSS. It's easy for HTML/CSS to feel almost like an afterthought. But it should be your first thought.

Without HTML/CSS, you have no web app. And if your answer to every presentation challenge is to throw everything into a <div> and slap a few style attributes on it, potential employers are gonna spot this right away.

How confident are you with Flexbox? How about Bootstrap? Do you know what "responsive design" means? Can you build a responsive site? There was a time when some of these challenges could be shunted to the design team. But nowadays, employers expect their frontend devs to be completely comfortable with all aspects of HTML/CSS.

Have a GitHub Presence

If you don't already have a GitHub account, you need to do so. Now.

No... seriously. If you don't have a GitHub account, stop reading this article and go create one. RIGHT. NOW.

You may be thinking, "I don't have anything to put in a GitHub account." I don't care. The first step is to have a GitHub account.

Why is this important? Because you don't have any job history to speak of. So the only thing you can do is to start documenting your code history.

Maybe you don't have any repos right now. But from this day forward, every time you complete a coding challenge or spin up some bare-bones web demo, I want you to create a new repo under your GitHub account and store it there. The code in those repos may not be the prettiest or the most advanced. Heck, it may look downright amateurish to a seasoned dev. But you know what looks even worse? Having no public code presence to point potential employers to.

To be frank, I delayed opening a GitHub account for many years. (Although it wasn't a huge problem for me because I was already an established dev before GitHub even existed.) I used to have dozens of little test/demo apps on my local machine that I played around with, but I never put them on GitHub. But those little apps at least provide some evidence of your skillset and the type of work you can do.

A GitHub account also has another (seemingly obvious) benefit. It forces you to get more comfortable with git (if you're not already). In modern dev, git is not a "nice to have". It's a core skillset. As a dev manager, a JavaScript savant who struggles with basic git commands is borderline-useless to me.

(Side note: Last year, at Amazon, there was a guy on our team who somehow managed to get hired without having basic git skills. He lasted all of two months. Quite frankly, I'm surprised he lasted that long.)

Open an AWS Account

Now that you have a GitHub presence, take the next step and open an AWS account. If you're worried about the cost, don't be. It's free to open an account. Most of their services are free to use for the first year. Even after that first year, any costs to you should be extremely minimal unless you start hosting torrents or doing some other kinda high-traffic activity.

I currently have four sites in AWS. And my monthly bill is usually about $8.

Maybe you're thinking that you have no need for AWS because you're not hosting/building public websites/apps. But I'm telling you, it makes life sooooo much easier when you decide to launch even your first little utility.

Using AWS Amplify, I can create a new GitHub repo, throw up some bare-bones code, then hook that repo up to Amplify and have it published, on the web, in minutes. If you want your own domain name for the app, you can purchase that right in AWS with Route 53 and have it live in less than an hour. Amplify even provisions an SSL certificate for free for all of your Amplify sites.

Once you have a GitHub repo hooked up to an AWS Amplify account, every single time you push new code to the repo, it will automatically build-and-deploy your latest code to the public website. It's sooooo easy. And cheap.

Not only does this give you a quick-and-easy (and cheap) path to launch anything, but it will also get you acclimated with the AWS ecosystem, which is a huge selling point with many potential employers. Even if the company you're aiming to work for doesn't use AWS, it looks good on your resume to be able to say that you're familiar with it.

To be clear, AWS is a massive beast in itself. And I'm not telling you to become an AWS Ninja. I'm just suggesting this as one potential way to A) bolster your resume, and B) have a swift path to launch anything that you'd like to publicly display. Of course, you don't have to use AWS. There are other cloud-computing solutions that will give you similar capabilities and experience. The exact platform you choose is up to you.

Build Stuff

Now that you have a GitHub account to house your code, and you have an AWS account to deploy your code, you need to have some... code. Yes, this is basically an extension of my "WRITE MORE CODE" mantra. But again, if you don't have a formal work history, you're gonna need some way to at least demonstrate your skill history.

If you're not sure what to build, start with your personal portfolio site. Maybe you haven't done that because you don't have any kinda meaningful portfolio to speak of. But even if your site contains nothing but your resume and a few other trivia facts about yourself, it's a good "first step" to getting a public coding presence.

One important note here: Do NOT half-ass your personal site. Spend some time on it. Try to make it look nice, even if it's weak on content. Pay attention to details like performance and accessibility. (HINT: You can use Lighthouse to generate performance/accessibility reports for your site.) Just last week, a hiring manager at a place where I'm interviewing (and I expect to receive an offer in the next coupla days) told me, during our interview, that he pulled up my site and he was amazed at how well it scored. He said that he frequently does this for candidates and usually the scores are abysmal.

But don't stop building stuff once you have a personal site up-and-running. Build more stuff. I don't even care what you build. The purpose here is not to illustrate that you are The World's Greatest Coder. The purpose is simply to demonstrate to potential employers that you are, in fact, a coder.

I don't even care if you're launching static sites. Put up a site for your church, or your D&D group, or... whatever. It may not be incredibly fun or engaging. But you gotta start somewhere. And you'll learn things - even if the stuff you're building isn't all that challenging.

Of course, if you can build something that better demonstrates your full coding skillset, then all the better. You can launch some simple utilities. You can launch something that leverages/extends a public API. You can even launch a site that contains tutorials on how to code. I don't care what you build. Just build something. And make sure that it's available for you to brag about when talking to potential employers.

Use Everything You're Building to Bolster Your Resume

Let's imagine that you've been trying to get a "real" programming job for the last two years. During that time, you've been working on personal coding projects and developing websites/apps for friends/colleagues. During the same period, you've also been working as a waiter to pay the bills. Many people would represent that on their resume like this:



EXPERIENCE:

2021-Present
Waiter @ Joe's Chicken Hut
Responsibilities: Spitting in food; Angering customers; Taking smoke 
breaks;

In other words, they wouldn't put anything on their resume that pertains to coding because they don't have a "real" coding job. But here's how this should be represented on your resume:



EXPERIENCE:

2021-Present
Self-Employed @ My Awesome Digital Solutions, LLC
Responsibilities: Launched a new website for a local faith-based 
organization; Forked ChatGPT to create an interactive tool for 
interview preparation; Developed a utility for managing Spotify 
playlists; Partnered with local dev users group to craft coding 
tutorials;
Technologies Used: TypeScript, JavaScript, HTML/CSS, Bootstrap, 
jQuery, GitHub, AWS, REST, GraphQL, React, Redux

2021-Present
Waiter @ Joe's Chicken Hut
Responsibilities: Spitting in food; Angering customers; Taking smoke 
breaks;

If you're thinking, "But I didn't get paid for those projects," you're missing the entire point. It doesn't matter if your total income from My Awesome Digital Solutions, LLC over the last two years was $27.83. As long as you actually did the projects listed under that resume entry, you're not lying - not at all. Also, there's absolutely nothing wrong with having concurrent work histories on your resume. People do it all the time.

And how does anyone know that you actually did those projects, with the technologies that you've cited? Well, because they're in GitHub, and probably viewable at some public URL.

Contribute To Open Source Projects

I'm gonna open this section by freely admitting that this suggestion is hard. Most open source projects are maintained by a core group of dedicated senior devs who know the package inside-and-out. Not only can some of those communities be incredibly insular, but it can be extremely difficult for someone who's not already deeply ingrained in the package to even know where to begin. While it's great, in theory, to say that we should all be doing our part to contribute to open source, in practice, it can be daunting to get even a single line of code approved and merged into an open source project if you're not already deeply ensconced in it.

So why am I telling you to do this? Especially if you're not deeply experienced yourself? Two reasons:

First, diving into established open source projects is one of the only ways that you can see what "production code" looks like before you've ever had a chance to work in an official programming role. What do I mean by "production code"?

Well, there's a nasty little secret that most people don't tell you when you're first learning to code: The "production code" that you typically see in most live codebases usually looks nothing like any of the code that you've yet been exposed to. That may sound like a scary fact. But it's true.

When you're going through tutorials, everything is "dumbed down" to the simplest possible level. This is done on purpose because, if I'm trying to demonstrate a single, targeted principle, I don't want the tutorial to be "muddied up" by the myriad bells-and-whistles that you'd often find in a large-scale app. I only want to illustrate the targeted principle that I'm trying to demo.

That makes perfect sense when you're trying to teach a single, simple concept. But it can cause someone's head to spin the first time they're ever exposed to "real" code out-in-the-wild.

I've seen this firsthand. I've witnessed newbies who managed to get hired, and they showed up on the first day thinking that they know what "real" code looks like. Then they get exposed to the Big Hairy Real Life App that we work on. And... they're lost. In fact, I've seen some of these guys quit a job within days because they felt completely out of their depth.

Sometimes live apps look insanely complex because they're legacy apps that've been cobbled together over many years, and by many different devs, to the point where they've become a certified mess. But even in new apps, or even in apps that are fastidiously maintained, the code can still be insanely difficult for a newbie to grok. This is because that new code isn't some simplified tutorial. It's a real-live app that has a lot of different "hooks" and dependencies embedded within it.

If you wanna avoid that massive shellshock the first time someone drops you in the middle of a live codebase (or a coding interview), there are few options. Because companies aren't just gonna hand over their codebase for you to learn from.

But there is one fabulous way to see what "real" code looks like without having to be hired at some company. That way is to jump into an open source project. Open source projects often have just as much complexity as you would expect to find in corporate apps. And you don't need to be hired anywhere to start acclimating yourself to it. It's all right there, publicly available, in GitHub.

The second reason that I want you to start wading into the open source waters is that it can be a great boost to your resume. For example, let's imagine that you manage to get a pull request, with a single line of code, merged into the React project. Now, to be perfectly frank, even accomplishing that would be quite a challenge. But if you did??? Well, you could say, with perfect honesty, that you are now a contributor to the React project. That'd be quite a nice chit on your resume, dontcha think??

Sure, your "contribution" would consist of a single line of code. But who cares? You could still say with total integrity that you are, in fact, a contributor to the React project.

Consider Code-Adjacent Roles

This suggestion may sting a bit. If you've had your sights set on a programming role, you probably don't wanna think about getting hired in QA, or as a business analyst, or as a data analyst, or in desktop support, or as a PM. But sometimes this can be a way for you to get your foot in the door.

I've been on many dev teams where I never saw a single newbie hired from outside the company. This doesn't happen because someone's trying to punish you. This happens because newbies can be a liability on the team - draining time from other devs and potentially introducing bad code.

But I have seen, on multiple occasions, where someone within the company who's not technically in a coding role, gets approved to join a dev team once they've shown that A) they're really a great employee in another role, and B) they actually have coding skills.

Think about it. If Joe's coming to us "off the street" and his resume clearly shows that he's never worked as a programmer before, it's actually pretty reasonable to believe that he may not be cut out for this environment and we may need to escort him out in a frighteningly-short period of time.

But if Joe already works for our company (in some other role) and we interact with him on a regular basis, we have the freedom to talk with him whenever we want. We can see if he's doing any coding-like work in his current role. Even if he's not doing any coding at all, we'll probably be much more comfortable with the risk because we already know this guy and we can see how he works.

I'm not just telling you this in theory. My first corporate role was as a "Web Content Editor". Sure, I was technically working on the website. But I wasn't (initially) allowed to make any code changes. I was just an editor. I updated static text.

But at the point that I was hired into this role, I'd already been coding - on my own - for a number of years. And when problems cropped up on the site that would normally take weeks/months to get IT to fix, I told them, "Well, you know... I could actually fix this for you if you want?" It took a little while, but eventually they realized that I actually knew what I was doing. By the time I left that company, my official title was "Application Developer".

Blog

I realize that this suggestion will not suit everybody. Writing is a proclivity that some just don't care for. But blogging can be incredibly useful.

First, it expands your public presence. The never-been-hired candidate that no one's ever heard of is often less valuable than the one who has a rich history of blogging about tech issues.

Second, the mere act of blogging often leads to deeper understanding on the issues that you're writing about. The blog-reading community is your "rubber ducky". I can tell you that, on numerous occasions, I've sat down to write a Dev.to blog on some software concept that I thought I fully understood - but by the time that I tried to crank out the explanation in a formal article, I realized that there were flaws in my logic.

Even if the act of explaining an issue doesn't highlight the flaws in your logic, you can bet that the commenters probably will. And you know what? That's a good thing. I've learned some great tips by reading the comments that were made on my own blogs! That expanded knowledge will only help you in your quest for a dev job.

You may be thinking that it's silly to blog about programming precisely because you're so new. But blogs don't even need to consist of you telling the world how it's done. Blogs can even be fashioned as open questions for problems that you're struggling with.

Pitch Your Services

When you're applying to open positions, you're already at a massive disadvantage. Job postings are typically created by companies who have significant salaries to offer, so they can afford to be picky. And the mere fact that the job is advertised means that there will inevitably be a large number of applicants. And nearly all of those applicants will be more qualified (at least, on paper) than you.

But not all jobs start with advertised openings. If you're paying close attention, sometimes you can pitch someone on the idea of hiring you. In such a scenario, you're not competing with All The Other Applicants - because there are no other applicants.

Imagine that you know a small business owner and you can see him struggling with manual processes. Then imagine you propose that you could build some tools for him that will automate those processes - assuming that he hires you.

Is that likely to work? No. But it can't hurt to ask. You never know...

And to be clear, even if that small business owner actually does agree to hire you, the pay may be abysmal. But it's probably still more than you're making in your current job. And after a year-or-so of proving yourself in that type of role, your resume will look stronger and you can leverage it into a better role with a company that pays more.

Don't Give Up

In conclusion, I just wanna say that, I get it. I really do. Finding your first programming gig can be really tough. Especially when you've got that "self-taught" millstone hanging around your neck. And I know that I haven't written anything here that's a silver-bullet answer. Even if you do everything I'm suggesting, it's still gonna be... hard.

All I can say is: Keep working on your skills, your public "footprint", and your projects. There are opportunities out there, even if they're pretty hard to see at times.

Best of luck!

Browser Zoom, CSS, Event Handlers, and Accessibility

Adam Nathaniel Davis — Thu, 16 Mar 2023 09:10:02 +0000

A few weeks ago I was working on some features for my color mapping site (https://paintmap.studio) and I ran into some very odd edge-case bugs. I found that when I used Chrome's zoom feature (which also exists in any other modern browser), my seemingly-perfect code was breaking. Specifically, CSS properties and React/JavaScript event handlers were simply disappearing when I viewed the app at different zoom levels.

Here's the exact scenario (along with the associated fix):

First, the user selects an image, along with a number of different parameters that determine exactly how that image will be transformed. The result is that you get a pixelated image that matches the colors in that image to a known set of colors from a palette of paints. The result looks like this:

In theory, the app will process images of any size. They could be small images that are easily viewed onscreen. But in practice, nearly all the images that I put through the app are fairly large. Most commonly, they're 1440x1440 pixels.

This means that it can be difficult to view the generated image in its entirety. So when I'm using the app, I usually have my browser's zoom function set to 75%. On my 4k monitors, this allows me to view the entire 1440x1440 image onscreen without having to scroll horizontally or vertically.

Another feature of the app is that it will then convert the transformed image into a huge "color map". This is a massive HTML table where every cell in the table corresponds to one of the pixelated blocks from the transformed image. But on the map feature, each of those cells contains a number, and each number corresponds to a given color of paint.

(In case your wondering, the whole purpose of this feature is that I can then copy-n-paste the entire HTML table into a spreadsheet. Once it's in a spreadsheet, I can then use it as a "paint by numbers"-style template.)

Unfortunately, converting the image into the massive HTML table makes the onscreen output even larger. This is necessary because if I try to adhere to the size of the original image, you'll never be able to see all of the numbers in every individual cell.

So even with my browser set at a 75% zoom, the resulting display looks like this:

That may seem somewhat unwieldy because I still have to scroll horizontally and vertically to see the whole image. But this isn't much of a concern because it's all just gonna get copied-n-pasted into a spreadsheet anyway. Besides, when you're viewing an image in this format that has 144x144 table cells, there's only so much you can do to make it "presentable" on a single screen.

Adding clickable elements

Here's the feature that I needed to add. When I was looking at the big "color map", I found myself wondering: "How many other places on the map use the same color as the one that's in this particular cell?"

For example, when looking at the following section of the map:

I can see that there are certain blocks that use color #920. But I wanted to be able to quickly see, at-a-glance, where color #920 occurs in the entire color map. So I added some new logic to the code that renders the table cells. That looked like this:



const getTableCells = (cells = [rgbModel], rowIndex = -1) => {
   allow.anArrayOfInstances(cells, rgbModel).anInteger(rowIndex, is.not.negative);
   const { highlightedColor } = uiState;
   return cells.map((cell, cellIndex) => {
      const paintIndex = colors.findIndex(color => color.name === cell.name);
      const darkness = (cell.red + cell.green + cell.blue) / 3;
      let color;
      let backgroundColor;
      if (highlightedColor === cell.name) {
         backgroundColor = '#39ff14';
         color = 'red';
      } else {
         backgroundColor = `rgb(${cell.red}, ${cell.green}, ${cell.blue})`;
         color = darkness < 128 ? 'white' : 'black';
      }
      return (
         <td
            className={'cell'}
            id={cell.name}
            key={`cell-${rowIndex}-${cellIndex}`}
            onClick={handleCellClick}
            style={{
               backgroundColor,
               borderWidth: highlightedColor === cell.name ? 5 : 0,
               color,
            }}
         >
            {paintIndex}
         </td>
      );
   })
}

Here's what's happening in that function:

We grab the highlightedColor from uiState.
Then for each cell, if that cell represents the highlightedColor, we set the style to have a neon green background, with a red number, and a border width of 5. If it's not the highlightedColor, then we match the background color of the cell to the "normal" color, with a black number, and a border width of 0.
We set an onClick handler for each cell that will update the highlightedColor.
We also set the className for each cell to cell.

The cell CSS class looked like this:



.cell {
    border-color: red;
    border-style: solid;
    cursor: pointer;
    font-weight: bold;
    height: 50px;
    min-height: 50px;
    min-width: 50px;
    text-align: center;
    transform-origin: 0 0;
    vertical-align: middle;
    width: 50px;
}

Notice that I've set the cursor attribute to pointer to give an extra visual cue that each individual table cell is indeed clickable.

And the handleCellClick() event handler looked like this:



const handleCellClick = (event = {}) => {
   allow.anObject(event, is.not.empty);
   uiState.toggleHighlightedColor(event.target.id);
}

The end result is that, if I clicked on any cell that contained #920, the previous subsection would look like this:

And if I zoomed way out, I'd get something that looked like this:

This allowed me to quickly see all the other places in the image that used the same color.

The zoom problem

At first, I was quite pleased with my new color-highlighting feature. But then I noticed something really wonky.

When I viewed the color map with no browser zoom applied, everything worked great. But viewing it with no zoom meant that I could only see a tiny portion on the screen. When I went back to my "normal" setting - browser zoom = 75% - something really strange happened.

Most of the onClick handlers worked just fine. But in some portions of the map, they did nothing at all. Also, for most of the table cells, the cursor: pointer CSS attribute was applied. But on all of the cells where the onClick handler was failing, the cursor also reverted to its default value of pointer.

I couldn't find any rhyme-or-reason as to why the event/CSS values failed on some cells, but worked perfectly fine on others. Furthermore, the exact cells that failed-or-worked varied depending upon the particular zoom setting that I'd chosen in the browser.

At 75% zoom, a given region of cells would lose their event/CSS settings. But at 66% zoom, entirely different regions would lose the settings. However, I also noticed that, at 50% zoom, everything worked just fine. This was a critical clue as to what was happening.

The dangers of subpixel rendering

You may have noticed that, in most modern IDEs, if you try to manually set a CSS property to a subpixel value (e.g., height: 50.33px), you'll get some kinda warning. They do this because browsers can get kinda wonky when you set pixel values that are not integers.

Of course in my example, I wasn't manually setting any style attributes to subpixel values. Everything was set to nice, clean, whole numbers. But here's the "gotcha":

When the user manually alters the display with their browser's zoom feature, it forces everything onscreen to be re-rendered. And those re-renderings will often turn your nice, clean, whole numbers into subpixel calculations.

For example, I was setting every table cell to have height: 50px and width: 50px. Nothing wrong with that. But if the user sets the zoom factor to 66%, now every cell height and width becomes 33.33px.

Now I'm gonna be honest here. I don't fully understand what happens inside the guts of the browser itself that makes a table cell with height: 33.33px and width: 33.33px suddenly lose it's CSS properties or its event handlers. But I was able to prove out through experimentation that those subpixel calculations were indeed the source of my problem.

This explains why, at different zoom levels, some regions of the color map performed just fine, while other regions failed. Because when you're tiling successive table cells on the screen at, say, 66% zoom, the first cell will be "off" from the screen's normal pixel grid (because of that pesky .33px modifier). And the second cell will also be "off" from the pixel grid (because now that one is essentially shunted by .66px). But the third cell will be able to "snap into" the screen's normal pixel grid. Because by the time that the third cell is rendered, it's "offset" is 1/3 + 1/3 + 1/3 = 1 - meaning that it can snap into the monitor's "normal" display.

This also explains why my code worked perfectly at 100% zoom, and 50% zoom, but failed at zoom levels like 66% or 75%. Because, at 50% zoom, all of my height: 50px; width: 50px; cells became... height: 25px; width: 25px; cells - meaning that at 50% zoom, everything was still rendered with nice, clean, whole-number pixel dimensions.

The fix

Luckily, once I realized what was going on and I did a bit of CSS googling, I was able to solve the whole problem with a single line of CSS. I altered my cell CSS class by adding this:



transform: scaleX(1) scaleY(1);

This basically tells each cell to scale up to consume 100% of its boundaries. This in turn seems to clear the problem that the CSS-and-event-handlers had with subpixel-styled elements.

But... who cares??

It's reasonable to look at this odd bug and wonder if you should even care about it at all. At first, I just filed it away as a weird edge case that I never ran into before - and I'd probably never need to worry about it again.

But... I'm actually pretty sure that I have run into this issue before. There have been times in the past when I was working on a site and I got tired of scrolling around to verify functionality. So I'd shrink the screen down so I could see it all in one shot. But then, after days, or even weeks, of using the site in this manner, I'd find some odd glitch in the app.

After investigating it further, and after realizing that none of my colleagues could reproduce the error, I'd realize that the issue only happened for me because I was the only one using the site on a non-100% zoom level. So what did I do? I just flipped my zoom back to 100% and went about my business.

Afterall, no one else had reported the error or was complaining about it in any way. So I didn't want to burn dev cycles troubleshooting a problem that no one else cared about.

The only reason that I felt a need to fix the bug, in this particular case, was because it was important to me. Specifically, it "mattered" because it's hard to view those large color maps onscreen unless I'm shrinking it down to a workable size.

Additionally, even if someone had complained in the past about features being broken in non-100%-zoomed formats, I'm pretty sure that I would've been fairly dismissive about it. It's not that I don't care about the user experience. But my reasoning would have been as such:

We spend a lot of time painstakingly ensuring that the site works optimally in its default resolution. If you feel compelled to change that resolution (for some odd reason), I can't be bothered to test-and-troubleshoot every far-edge-case that results from people using the site in unintended ways.

Maybe that sounds flippant. But there are many things you can do/use in a browser that subvert the devs' original intent. And we can hardly be expected to devote loads of troubleshooting time to your aberrant way of using the app.

For example: I've received "bug" tickets from users who said that something was broken on the site. When I investigated it further, I couldn't recreate the error. Nor could anyone else on our team. When I contacted the user directly, I realized that the "bug" was caused because they're using some third-party browser plugin. And it's interfering with the site's normal functionality.

In such scenarios, my answer has always been the same: Stop using that third-party browser plugin on our site. Sure, some people have whined about this response. But I've always received support in this stance from my management chain. Because trying to ensure that your app works properly no matter which third-party plugin someone chooses to use is a horrific rabbit hole that yields almost no discernible value.

Finally, issues caused by browser zoom functionality feel like extreme edge cases. I mean, 99.99% of the time when I'm viewing/using any website, I'm viewing/using it at the default 100% zoom level. For the vast majority of users out there, they probably use most/all sites at the same 100% zoom level as well.

An accessibility issue

But the more I thought about this, I began to realize this is an accessibility issue. And it's one that I don't think many dev teams are really thinking much about.

I've worked on apps where accessibility was no one's real concern. We had a limited userbase and management put no priority on accessibility standards. So we happily cranked out code without worrying about things like A11Y compliance.

I've also worked on teams where accessibility was a critical concern. In those shops, we constantly ran auditing tools and preached the importance of accessibility standards in everything we built.

But even in those "woke" environments, I don't ever remember anyone saying that we needed to validate the site's features at different zoom levels. But what subset of your userbase is most likely to be using your site/app at varying zoom levels? That's right. People with impaired vision. And if key features of your site simply break at, say, 125% zoom, you could be alienating those users.

To be clear, I'm not even sure exactly how you test for this. Like, if you're writing Jest unit tests, you won't be able to validate functionality at different zoom levels. You'd need to leverage a headless browser solution. And I'm not sure if quick auditing tools (like Axe) even check for these things? I'll have to research that some more.

At any rate, I'm not trying to upend your current accessibility practices. And to be fair, maybe in your dev shop, this is already something that's on your radar. But I'm just highlighting it as one potential issue that you may need to keep in mind going forward.

Cheers! And happy coding.