DEV Community: András Tóth

Tech Zen Wisdom: Abstraction

András Tóth — Tue, 01 Jul 2025 03:12:54 +0000

One cannot be angry at reality, one can only be angry at one's own abstractions.

The Anatomy of a Software Engineer

András Tóth — Sat, 26 Apr 2025 23:52:22 +0000

Software development is a lot more than knowing a couple of programming languages, popular libraries or to be able to traverse a binary tree in a job interview. It's crucial for product managers, team leads, engineering managers, and basically anyone making decision over engineers, to know how to mix and match expertise inside a company to unlock true productivity.

I dedicate this article to both product managers and software engineers in hope that we get to understand each other better and we can be more productive simply by strategically utilizing knowledge and expertise and avoid blunders like keeping talented people perpetually inexperienced by making them constantly switch languages/tech/teams and products.

As there is reusable and non-reusable code, I will classify engineering knowledge into reusable and non-reusable categories.

By reusable I mean the normal definition everyday definition it: if you learn how to cook in a country most likely you'll figure it out in another country.

The Non-Reusable Knowledge

Let's start with what I consider "non-reusable" as these categories are all about detail and gotchas. The quirks of Linux won't transfer when you work with IIS (Internet Information Services) of the Windows ecosystem for example. Let's get to the details!

Knowing a Programming Language

I consider the details of a programming language "non-reusable" as the syntax of a language cannot really be used again - unless the other language is almost the same. It's much easier to jump from Java to C# than from JavaScript to Rust. In the latter case you need to relearn keywords, rules, gotchas, and indentation, best practices, anti-patterns... Not to mention package managers and the strengths and weaknesses in the ecosystem (e.g. which input validation library to choose).

💡 When moving around engineers for a project, consider that lhe less similar two languages are, the more time they will need to write intelligent code.

For instance ixn JavaScript, the idea that the this keyword of a function is a freely attachable context, and not a pointer to the object containing said function, cannot really be reused in another language; it's a one-time quirk. Once you abandon JavaScript that knowledge will be lost (or you can bore young colleagues in the future about it).

However, the more familiar you become with the deep features of a language, you'll know what to search/ask for when you learn a new language and can get productive a lot quicker as opposed to be a newbie. It took me little time to refactor and low-key optimize the code of data analysts when I had a Python assignment; they knew how to crunch the data, I knew how to avoid typical coding mistakes. See more about this in the next section!

The Ecosystem of a Language

The ecosystem of a language refers to the modules or packages available — like react, express.js, or SQLAlchemy for Python — that are typically accessible through a package management system, such as npm, pip, or NuGet for .NET.

This knowledge accumulates slowly through years of trial and error, getting lucky or getting burnt with someone else's code. In some ecosystems you absolutely should not reinvent the wheel by reimplementing what's out there; in others you might encounter abandoned projects or missing important libraries and you'll have to roll your sleaves up.

Even if you're not changing languages during your career, frameworks change often as well: libraries like Angular or firebase get rewritten with a new design goal, so this type of knowledge also tend to get lost with version changes.

💡 Consider the ecosystem when moving people around in a company! This knowledge cannot be externally obtained through search engine queries or asking one of the LLMs.

Going back to my Python assignment, while I was getting their code cleaner, I needed lots of help for all the things that were unique to Python, like setting up pip, the package manager and development environment. The analysts colleagues who had significant amount of experience with the basics were very helpful dealing with this.

Platform-specific Gotchas

Languages and ecosystems do not exist in a vacuum. There is an operating system or sandbox around them (for example, MacOS, Firefox, or a particular Android version). The medium our code runs in dictates how we write things. Here are a few examples of these type of gotchas:

Some older browsers won't be able to process certain newer UTF encodings and completely drop rendering the page.
Working on a react-native project chasing mysterious Android crashes, I needed to get familiar using logcat from Android Studio.
I had horrible, non-reproducible failures for timeout related tests. Turned out that the virtual machine had its internal clock out of sync with real world time. It took me 2 days of bug hunting figuring this out.
Running two tasks in series with && is the standard on a Mac, but it won't work on Windows; hence the existence of https://github.com/mysticatea/npm-run-all.

These can only be learned by paying the "iron price": struggling through mysteries, scrolling through GitHub issues, and asking for help. You can be stuck debugging these for days from time to time!

Therefore, this experience is a very important part of engineering and crucial for having real productivity! Sadly much of this knowledge starts from zero whenever engineers are reassigned across platforms.

💡 Platform-specific knowledge can make or break releases! Make sure you not only have enough engineers but to have experts on the platform you're building for.

The cross-platform framework react-native is a great example to illustrate this point. You can't just grab 5 JavaScript engineers and put them on a react-native project if none of them have mobile development experience.

Having a team member who scores high on platform-specific experience is able to defuse future landmines that others would not even know to look for. It's much cheaper if way before release that expert engineer exclaims in a meeting that something won't work than pulling back an embarassing failure.

Invaluable Product/Domain Knowledge

When working at one company and one product for years engineers get to know the user base, their needs, the problems they face. They would also know the code inside-out.

There is of course more general and more concrete domain knowledge. For example once you fixed your first internet reconnection bug in single page application you would expect the same to be a problem in mobile apps as well, while you can't really transfer your intricate knowledge about the details of GDPR regulations to your new job in car manufacturing.

Engineers that spend significant amount of time on one product, one aspect, usually become living encyclopedias of both the product and how it works. They become the "go-to" people when someone has a hunch but not unsure and they can know more about certain topics than the product manager of the team.

💡 Therefore, the domain and product knowledge of engineers is crucial for company success! This local expertise can be easily lost with arbitrary layoffs, denied salary raises or moving team members frequently around.

You can be a senior in a programming language but an absolute junior on a new product.

Internal tools, special configurations, rules coming from your special group of users are contributing to a local knowledge that is really hard to get external help for.

👆 Let me emphasize this a bit more: you cannot ask ChatGPT or from online forums about how your product and codebase works!

Personal example

I've had a project where the company selected around 60 C# professionals familiar with support and remote connection to an IoT project and then changed the project to be node.js microservice one because of appeal to investors. This is where we lost all language knowledge, we weren't familiar with the node.js ecosystem, we had no experience with internet enabled devices and their quirks, we had new teams so interpersonal knowledge was also lost.

The product this many people built for a year got scrapped (and then again I heard) and rewritten from scratch when relevant pieces of experience both from product and engineering side got there.

Reusable Knowledge

Now let's focus on the good things: what an engineer can bring from one assignment to another.

Engineering Principles and Instinct

Luckily, most of the principles of popular paradigms are quite reusable: clean coding, the SOLID principles, design patterns and anti-patterns, the test pyramid, the art of discarding unnecessary layers (in other words: avoiding overengineering)... All help you to be critical during your work.

There's also what I call pure instinct, the ability to play around with a bit of code and tell if it needs more work or not. You develop your subconscious skills by working with both elegant and terrible codebases, and after a while you will just see when something is overcomplicated or off.

It is also knowing what to reuse and what not to reuse, what code to repeat and what code to move into its own module. It's your ability to smell the code.

To give another personal example, when I had to fix a data engineer's Python code, even as a Python newbie, I immediately searched for a better way to replace variables in a string than positional %s signs that are prone to silly mistakes (like putting address in place of firstName when the amount of data passed changes):

# original version was something like this
'SELECT %s FROM %s WHERE id = %s' % ('my_table', 13, 'name')

# versus

'SELECT {column_name} FROM {table_name} WHERE id = {id}'
.format(id=13, table_name='my_table', column_name='name')

# Did you notice that in the first version the order 
# of the arguments passed is wrong? Not likely to happen in
# the second version - it would look odd immediately

As it turned out, there was already a syntax for named placeholders, which is superior with its clear indication of what each property means, therefore changing the order of parameters will not have consequences.

This is the most reusable knowledge.

It also helps you with the adoption of a new language: you know what to put into the search bar to find exactly what you need.

💡 Tip of the day: Head First Design Patterns is a book seemingly about Java, but in reality, it gives you the why of every pattern and you can learn a lot about principles that are useful in other languages. It's not just for object-oriented programmers!

Problem Solving Skills and Engineering Instinct

One of the distinguishing feature of a truly senior developer is to look holistically at feature requests. It's no longer "just another button in the menu". The experienced eye would look for potential clashes, think about small monitors, mental load of the user, consider UX practices and anti-patterns.

There are also ways of how to approach nasty problems, like tracking down a crash without any useful clues by progressively commenting out parts of the codebase. Or engineers can develop an eye of spotting scaling issues like "Well, with a 100 users this is not a problem, but we're going to be stuck when we have 10000!". Or tricks, like inverting the problem statement, brainstorming hacks, and so on.

Finally they would know what requirements to implement to the letter and what requirements need more investigation. Or where and how to look up data to support or disprove assumptions.

For example a story can be making a sizable chunk of the knowledge base available for non-registered users. If the task requires significant changes, it might worth looking into the data; if it turns out that 99% of the users are logged in, then maybe you can skip an unnecessary and expensive feature.

This is readily reusable knowledge, and to some extent can be enhanced with special training sessions.

Personal Productivity Management

This ranges from getting the most out of your IDE to organizing your day effectively. It also includes knowing when to push through a problem regardless of time versus when to go home when you're mentally done for the day. Or when to politely decline meetings to stay in flow! This is also knowing your own limits, understanding the resting requirements of your body, to have rituals to reset your brain.

Growing Lasting Knowledge

Alongside classics like algorithms, object-oriented programming, design patterns and so on I have learnt SQL, HTML and CSS at the university. I still use these languages to this day while I have learnt and forgotten popular libraries like Angular for the frontend or Prisma ORM for the backend.

The important takeaway is to spend time on the basics and not to skipping them just because you have that trendy framework that hides that from you. Otherwise you are setting yourself up for a bitter loss of knowledge in a couple of years.

💡 Having only trending tech in a team is a red-flag and vulnerability!

Therefore any reasonable engineer/manager should think about investing into the lasting knowledge.

Communication Skills and Solving the Problem at the Right Level

Let's not forget about soft skills!

A well-versed senior software engineer have experienced different methodologies, problem solving tricks. Hopefully by this time in their career they became excellent team players: hard stance where it matters, agreeable where it doesn't.

Let's say you are having a heated argument over the way IMEI number from the phone is to be collected in the application. One way possibly takes 2 weeks to implement. However, someone raises their hand and says: "Hey, let's ask legal team if we can actually collect that information from a user!". This is yet another engineering instinct that comes from being exposed to multi-faceted problems.

On the communication side, learning to be context aware, know when and how to explain technical concepts to non-technical people and so on. Or learning that the loudest people are not always right and you have to ask each team member one by one to get the full picture.

Then there's considering the entire team from business owners to data analysts. You can vibe-code refactor the entire codebase in a caffeine fuelled late night sprint, however if the new code completely replaces analytical event names and properties then your data analysts and your business team will get absolutely understandably angry.

Summary

I hope that this article was enjoyable and helpful for managing teams or your own future career in engineering! During my career I have encountered many cases where leadership had very naive expectations over productivity, coming from not knowing how engineering and engineers worked.

I also hope that I nudge existing or prospecting team leads, product managers and CTOs to map out differen types of expertise in their teams and to be strategic about nurturing local knowledge. Check this interview I did with a friend about what happens when someone can never reach a deep expertise while she was always doing what was requested.

Refactoring Towards Pure Functions

András Tóth — Fri, 11 Apr 2025 10:46:22 +0000

In one of my articles a commenter wrote that he was "in general, refactoring towards pure functions". Now, usually the word "towards" does not lend itself to bold statements, but I grew fond of the expression because it expresses precisely a couple of things that I rarely read or hear about.

Black and White Thinking

Before I get into specifics, this article has a message: black-and-white thinking about paradigms is costing us code quality. In other words forcing one paradigm onto a varied set of problems will result in over- or underengineering.

As I wrote in my previous article Do you need classes in JS/TS?, when you have state to persist between calls and it's not trivial to manage that, using a class (or an equivalent object + scope combo) is the right way. It's akin to serving your dish with the appropriate cutlery (note that in JavaScript people can eat with their hands regardless of your attempts to neatly tuck things away - see also "monkey patching").

I maintain that even in a mostly functional codebase, if you encounter this particular problem, you're better off using a class than creating convoluted functional workarounds.

That's why I like the term "refactoring towards pure functions"! We try to convert everything into a pure function, but if that results in something awkward or it just complicates the code, we keep what we have - or even rewrite it in OO-style!

Spotting a Useless Class

With the mindset of turning everything into pure functions, I began finding patterns of useless classes - ones that just complicate things without leveraging what a class could offer.

Here is my simple algorithm to spot and remove such classes, hopefully resulting in a cleaner code base!

A `class` Without Methods

If a class has no methods then, it's just you a POD (plain-old-data) structure. You can simply use your everyday JS object: {} (of course you should define its type in TypeScript).

class Person {
  constructor(firstName: string, lastName: string, occupation: string) {
    this.firstName = firstName;
    this.lastName = lastName;
    this.occupation = occupation;
  }

  // we have no methods here
}

const onePerson = new Person('Edward', 'Elric', 'Alchemist');

// Instead, simply:
type SimplerPerson = {
  firstName: string;
  lastName: string;
  occupation: string;
}

const otherPerson: SimplerPerson = {
  firstName: 'Alphonse',
  lastName: 'Elric',
  occupation: 'Alchemist'
};

// Notice that the second solution is more descriptive!
// If you make a mistake and pass "Alchemist" to "firstName",
// seeing the label "firstName" will alert you or the reviewer
// that something is off.

(You might have a special case where you may want to use a class for relying on instanceof, but I can provide an alternative for that in TypeScript - would you rise up for the challenge in the comments? 😉).

A `class` Without (Serious) Members

Any method of the class that doesn't use this (or doesn't us this seriously) can be moved into a standalone function. By "seriously", I mean the members on this are not just there to "avoid taking arguments" (see below to get what I mean!).

class Operations {
  sum(a, b) {
    return a + b;
  }

  // These methods never access `this` — they’re just pure functions!
  multiply(a, b) {
    return a * b;
  }
}

const sum = (a, b) => a + b;
const multiply = (a, b) => a * b;

// While I usually dislike using _named_ unnamed functions,
// they're perfect for 1-liners!

While this one was trivial, often this pattern appears in a more concealed way. See this variety: arguments are shoveled into the constructor and we dig them back out in the methods - without ever changing them:

export class StringValidator {
  constructor(private input: string | null | undefined) {
  }

  sanitizeString(): string {
    if (this.input === undefined || this.input === null) {
      return '';
    }

    return this.input.trim().replace(/\s+/g, ' ');
  }

  isEmpty(): boolean {
    return this.input === undefined || this.input === null || this.input === '';
  }
}

// This class has no real internal state!
// We don't modify its internal state ever!
// The constructor just passes a value, and the methods act on it.
// Moreover, there's low cohesion — the methods don't rely on each other.

// Instead you can replace them with two pure functions:
export function sanitizeString(input: string | undefined | null): string {
  if (input === undefined || input === null) {
    return '';
  }

  return input.trim().replace(/\s+/g, ' ');
}

export function isEmptyString(input: string | undefined | null): boolean {
  return input === undefined || input === null || input === '';
}

Observing the Result

Now, take a look at what's left of the original class! If you see either of the patterns shows up, continue pulling out data or functions.

Eventually, either your class disappeared already or it has a tightly-knit set of variables and methods.

👆 You may also want to consider splitting large classes using class cohesion: if you have disjunct sets of methods and variables they can go into their own classes.

The true benefit a class provides is access to this. If a method doesn’t use it, or just passes arguments around, then a function is likely more appropriate.

Working Backwards from Usage

You can also spot unnecessary classes by looking at how they're used. A big clue can be one-time usage.

Here's what I spotted recently:

async function transformDataAndSendEmail(recipient: string, someData: SomeData) {
  const mailDocument = formatSomeData(someData);

  // Why insantiate an entire that's discarded immediately?
  // Where's the persisting state we need to manage between calls?
  await (new MailService()).sendMail(recipient, mailDocument);
}

As you see MailService is not a real "service" waiting in memory to handle further requests. It holds no state. It's just extra steps and bureaucracy to reach one function, and it'll be garbage collected right after.

Cleaning Up a Long Component (React)

We can extract pure (or purish) functions not only from classes but from any large code block, as long as:

We can isolate arguments with a little effort,
Avoid mutating them,
Same input yields the same output*,
With clear output values.

Note(*): there are obvious exceptions, for example if you have to use Math.random(). My advice is: don't fret about theoretical correctness if the logic can be neatly extracted, just know about it when you need it.

It's ingrained in many React developers that a component must contain everything for rendering — either via props or hooks. This is an anti-pattern resulting in breaking the Single Responsibility Principle, not to mention the mental load of juggling huge components.

import { parseTimeRange } from 'date-lib-of-the-day';

interface ArticleProps {
  articleId: string;
}

function PostTime({ articleId }: ArticleProps) {
  const article = useArticle(articleId);
  const translate = useTranslator();

  // other hook calls, etc.

  let ago = '';

  if (article.timestamp) {
    const now = Date.now();
    const articleCreationTime = new Date(article.timestamp);

    const timePassed = now - articleCreationTime;
    const parsedRange = parseTimeRange(timePassed);

    if (parsedRange.year > 0) {
      // ay-ay, we have to translate!
      // On top of everything, "translate" function comes from a hook!
      // 🥲 - all hope is lost!
      ago = translate(parsedRange.year, 'yearAgo');
    } else if (parsedRange.month > 0) {
      ago = translate(parsedRange.month, 'monthAgo');
    }
    // } else if () { ... and so on
  }

  return <div class="article">
    {/* imagine here some useful extra markup */}
    <div class="article-time">
      {ago}
    </div>
  </div>
}

It does look like it cannot be helped, right? Calculation of "ago" seemed like a great candidate, but it seems to be tightly coupled with translate function coming from a hook.

But is all hope truly lost?

// calculate-ago-from-timestamp.ts
import { parseTimeRange } from 'date-lib-of-the-day';

export type CalculatedAgo {
  value: number;
  translationKey: string;
}

// I guarantee you that, like this, you'll be more likely to find edge cases!
export function calculateAgoFromTimestamp(timestamp: string): CalculatedAgo {
  const now = Date.now();
  const articleCreationTime = new Date(article.timestamp);

  const timePassed = now - articleCreationTime;
  const parsedRange = parseTimeRange(timePassed);

  if (parsedRange.year > 0) {
    return { 
      value: parsedRange.year,
      translationKey: 'yearAgo'
    };
  }

  if (parsedRange.month > 0) {
    return {
      value: parsedRange.month,
      translationKey: 'monthAgo'
    };
  }

  // if () { ... and so on
}

Resulting in a cleaner React component, check this out!

// article.tsx
import { calculateAgoFromTimestamp } from './calculate-ago-from-timestamp';
// ... types and interfaces

function PostTime({ articleId }: ArticleProps) {
  const article = useArticle(articleId);
  const translate = useTranslator();

  // Look how much cleaner this component looks like now!
  let ago = '';
  if (article.timestamp) {
    const processedTimestamp = calculateAgoFromTimestamp(article.timestamp)
    // Oops! We've just solved the coupling with a bit of creativity!
    ago = translate(processedTimestamp.value, processedTimestamp.translationKey);
  }

  return <div class="article">
    {/* ... */}
    <div class="article-time">
      {ago}
    </div>
  </div>
}

Yeii, 🎉 now we can test this functionality without writing UI tests or without setting up a complicated translation mock! I also guarantee you that the moment you put this in a file and start writing tests you'll get creative finding edge-cases.

Summary

As you can see now, while "refactoring towards pure functions" is not going to give you the feeling of technical superiority it is an excellent tool to clean up code and make sure testing stays easy!

Easy testing usually means better code coverage!

I hope I have convinced you to look for these patterns and mercilessly cut complexity!

What's the point of a rockstar developer?

András Tóth — Wed, 26 Mar 2025 19:25:19 +0000

Hi there folks, today this question came to me.

I understand that it is great that you hire a very capable person and that unblocks certain things, fixes long broken projects and so on.

But why did these things got blocked and broken in the first place?

For me, the reliance on "genius" developers, or "newtype" or "10x developer" (even I saw 100x because of AI 🤦) is showing something very disturbing:

The lack of quality company (tech) leadership.

Either they are not capable or they are capable but unable to really influence decisions because of a strong push from business.

You see, if main stability features, like a comprehensive test suite depends on finding the right candidate who does that job outside of weekly responsibilities (and potentially on their own unpaid free time) then we are talking about serious, serious management issues.

I heard this idea about Japanese school system, that it's aim to bring all students up to a good average standard. I saw on the streets in Japan what it meant: they were clean and orderly. The bicycles were left in public without any safety on them, because they could trust the good average standard that they won't be stolen.

So in conclusion, behind the cult of the "rockstar developer" is a company that should invest in hiring at least a capable management who are going to coordinate the important work required for engineering longevity and velocity.

And if you do hire a "rockstar"... They would make your company fly.

(Photo: me as a ""rockstar"" about a decade ago.)

Do you need classes in JS/TS? [2025 version]

András Tóth — Wed, 19 Mar 2025 05:21:22 +0000

Hi there folks!

This is a revised version of 2022 article: Do you need classes in JS/TS?. (Ethical AI usage notice: no content was generated for the article or the cover image, however I did ask for a grammar check).

If you are a fresh JavaScript/TypeScript developer, you'll encounter some very vocal opinions on writing code in a "functional style" (FP, or "functional programming") or an "objectied oriented style" (OOP, or "object oriented programming").

You will hear devs saying things like "serious backend work requires a strong command of object oriented patterns", or _"On the frontend you must avoid side effects and embrace functional programming!".

Not coincidentally you will encounter backend frameworks that are fully object-oriented (like NestJS) and frontend ones that embrace immutability and pure functions, like the framework redux.

Personally, I believe that the right technique should be used for the right problem.

The key sign of misusing a particular style is confusion.

If you start to feel confused about why such a simple thing as adding a new endpoint to a web service or handling a simple HTML form requires so many steps or files, there is a chance that the wrong paradigm was applied.

Or more likely, black and white thinking about a particular paradigm resulted in bloat, unnecessarily complicating code.

Note on terminology, that this article focuses on using "classes" to achieve an "object oriented" paradigm: when to use it in JavaScript/TypeScript working on the frontend and webservices. I exclude niche applications like parsers/linters/transpilers/etc. and games.

I will also exclude from this article principles that people regularly associate with OOP; for instance hiding implementation details, providing a clear and safe interface to interact with a private data store and also microservices. These are extremely valuable principles, however I believe many of these can be achieved without classes in JS/TS. I also feel that tightly coupling these principles to the custom of using classes for everything and then raising the strawman of attacking the latter means throwing out these great principles hurt code-bases.

The point of using a class

Let's roll back time and go back to an old language: C. The algorithm you are working on requires an implementation of a stack and you have to write one from scratch. You drop elements into the stack, and by using the pop() function, you retrieve the last element that was dropped into it.

To implement it you would need the following things:

some kind of storage that holds the items of the stack
some way to deal with memory when you have a lot of items in your stack, even expanding the storage behind the scenes if it fills up
you want to keep a clear front, so the user access only specific methods and properties, giving you room to refactor later

Therefore you will have the following:

a private internal state that holds values between calls (the stack stays in memory and you can access at your leisure)
a couple of internal methods that manages your internal state properly and a way to hide them from users to avoid code coupled to the implementation of the day
on the other hand you do want to show public methods that lets you interact with the unit
and optionally have an interface to further decouple those public accessors from the implementation, declaring mandatory methods and properties of a stack, allowing you to interchange different implementations if needed

Now imagine when this concept was new and trending! It was very elegant, very organized. People back then were dealing mostly with desktop applications or very low level data structures like buffers, pointers, etc. and it made sense to tuck all that complexity away and use higher organization by having more of that class thing.

The rise of Object Oriented Programming

As with any trends, the industry got a bit overboard with it. When C# and Java arrived it was no longer possible to just declare a procedure or function without having a class; in my opinion it was a way to discourage people from Procedural Programming which was the old paradigm and force people to learn this new way of organizing code. (Not always successfully - I had a Java developer colleague who didn't bother with classes: everything was a Map<string, something>, essentially reinventing other dynamic languages 😄.)

I get what they wanted but this paradigm was overly complicating dead simple things, like a humble data transformation code where you process data from type A to type B and where you do not need to keep an internal state made of low level building blocks.

Therefore, while OOP solved great many important problems, it also tighly coupled classes with the idea of "well organized code". This became ingrained in a generation who uses it, well, for everything.

Now let's see a pair of contrasting examples to hit my point home.

Good example: database connection

Managing access to a database usually requires maintaining some kind of connection pool (reusing a number of connections to a database server). It also needs to track if we have already logged in or not, if the remote server is down and so on. We don't want to know about all of that, just a way to configure DB access and to run queries. These functions will constitute our interface: a set of functions and properties that do not change frequently (or at all preferably) while keeping the implementation details of the connection and the connection pool hidden (making them private). We do want to also persist some state as well to track, say, if we already gained access to the DB or not yet, or how much of the connection pool is already used up.

// An overly simplified database module
interface Database {
  configure: (options: ConfigOptions) => void;
  connect: (user: string, password: string) => void;
  query<T>: (query: string) => T;
  // I just make this up for a simple example
  isReadyToServeRequests: boolean;
}

class PostgresDatabase implements Database {
  // ...
}

// Same public methods but maybe very different concrete implementation!
class MySqlDatabase implements Database {
  // ...
}

Bad example: REST handlers

Let's say you have a dynamic FAQ page on your company website helping users. They want to click on articles in their own language with tailored, relevant information. This can be understood as a simple projection of (userId, articleId, language) => article. A simple function with its isolated scope ("the closure") is ideal here since you don’t want to persist state between calls: the article of user A is unrelated to the article of user B.

I have a little story about this. About 6 years ago we were new to next.js when we ran into this problem - in fact 2 teams separately made the same mistake: persisting a state between calls unwittingly. The bug we ran into with my team was serving articles in a random language, depending on who called last - if 2 users were making concurrent calls and had different languages the articles showed up all mixed. We accidentally stored language in a local state - the request handler was finding this state and used that.

The other team had it worse: unlike us they didn't catch it in QA and they managed to deploy a bug to production where users could see other users' private data...

The solution was to load up the user in both cases and scope it to the request handler, which became a simple function. Now each call was isolated from the other.

Summing it up, there was no need to keep a state between calls, whereas the interface was also very simple: 1 endpoint matching 1 function. (In real life you might need to create sub functions as you don't want to have 1000 lines functions.)

Conclusion of the examples

As I hopefully demonstrated, while OOP is an excellent pattern for certain problems, it is not a magic bullet and can add a useless complexity and even be dangerous when used on the wrong thing.

I am positive that seeing more examples can help you grasp this:

If you build a game, all the enemies are little persisted states with things like health, abilities etc. Perfect sense to go with classes! ✅
If you implement data structures, components with internal states, complicated algorithms that run for a long time and need to keep tab on a lot of little variables: classes to use! ✅
Data transformations, projections: you have no internal state, classes are a bad fit! ❌
API request handlers: you might have millions of concurrent requests, each of them should be isolated from each other: having an internal state is actually dangerous here, OOP is ❌! (A database service you may need to call is not an internal state.)

Understanding the clash between OOP and JavaScript's language design

The tension between Java/C# style object-oriented programming and JavaScript lies in the fact that

Javascript (and consequentially TypeScript) is neither strictly functional nor an object oriented language.

(Note: TypeScript is not making JS into an object-oriented language! I heard this baffling myth a couple of times from people.)

It has elements of both but its implementation differs in very important aspects. For example if you used JS for a while you must have encountered curious problems around this. You passed a method of a class to a function as a callback and BOOM! 💥, this.something was no longer there. In a classic OOP language, this can never happen because classes "own" their methods. In JavaScript classes are just syntactic sugar on top of this object-function soup we have. There is no such thing as grabbing an object's method and binding it to another object's internal state in Java or C#.

One particular anti-pattern I see comes directly from C#/Java where it was unavoidable to use class even when just needed to define a function or to store a couple of properties. In JavaScript, I consider this a design mistake as we can create simple functions and simple objects without the bells and whistles.

On the other hand, JavaScript isn't a true functional language either, as it lacks key guarantees like the immutability of function arguments and functions can have side-effects. (Though, I wish we could declare and enforce functions to be pure!).

A classic example is the .sort() method of an array which modifies the original instance unlike .map which isn't (note that in 2025 we have now .toSorted() that does no longer mutate the array! 🎉). This means if you pass the same array to two different functions if the implementation of functionA sorts the array, it will change what is happening in functionB!

(A personal rant: I can't fathom to understand why it is next to impossible to find in the documentation of Jest how to mock named exports of functions. It is clear to me that Jest was designed for OOP in JS and supporting proper JS import/export patterns was an afterthought.)

When to refactor a `class`

Now that we understand the strengths and weaknesses of a class let's have some simple rules about when and how to dismantle them:

the class does not contain methods => this is POD aka plain-old-data, you need a simple object: {} (+ a type in TypeScript)
any method of the class that does not seriously use this, can be moved into their own functions; by "seriously" I mean it doesn't use this to avoid receiving arguments (see below)
now check what's left of the class; if the resulting methods don't need this anymore, move them out

At this point, either your class is gone or it has a tightly knit set of variables and methods.

👆 I have written an article about: Refactoring towards pure functions, where I go into the details.
There's also a chance here to split large classes into smaller ones, by using class cohesion: if you have a disjunct set of methods and variables they can go into their own class.

The true feature a class provides is access to this in its methods. When some or all of them do not access it, as they operate over the arguments passed in then you will need a function instead. I am going to show you an example next where we seem to use this properly but we are better off with using the simplest functions.

export class StringValidator {
  constructor(private input: string | null | undefined) {
  }

  sanitizeString(): string {
    if (this.input === undefined || this.input === null) {
      return '';
    }

    return this.input.trim().replace(/\s+/g, ' ');
  }

  isEmpty(): boolean {
    return this.input === undefined || this.input === null || this.input === '';
  }
}

// As you can see, the class has no real internal state
// We just use the constructor to pass in an argument.
// Moreover, the cohesion of the class is really low; 
// none of the methods depend on each other.

// Instead you can refactor this to two pure functions:
export function sanitizeString(input: string | undefined | null): string {
   if (input === undefined || input === null) {
      return '';
    }

    return input.trim().replace(/\s+/g, ' ');
}

export function isEmptyString(input: string | undefined | null): boolean {
   return input === undefined || input === null || input === '';
}

A useless class: a quick example

async function transformDataAndSendEmail(recipient: string, someData: SomeData) {
  const mailDocument = formatSomeData(someData);

  // why use a class for something that will be thrown away?
  await (new MailService()).sendMail(recipient, mailDocument);
}

// In this case, "MailService" is not a real service.
// It is not "waiting somewhere in the memory" to handle requests.
// Nor does it have some meaningful internal state.
// It is just an extra step to get to `sendMail()` function call.
// And it will be garbage collected when we are out of `transformDataAndSendEmail` block.

Conclusion

Working with JavaScript we should use JavaScript patterns. That would yield us the simplest results.

For getting the "JavaScript way" I really recommend the books of getify You don't know JS; class alternatives.

Questions, agree or disagree? Sharing your edge cases help both of us refining our points of views. 🤝 Let me know in the comments!

Note

As a commenter on my first article pointed out, you don't even need to use the class keyword to encapsulate state and methods that operate over them, just use any old function to create a new object:

function makeSomething() {
  let myPrivateMember = 13;

  function getMyNumber() {
    return myPrivateMember;
  }

  function randomizeMyNumber(range) {
    myPrivateMember = Math.floor(Math.random() * range);
  }

  return {
    getMyNumber,
    randomizeMyNumber
  };
}

Tech stories: the wrong type of help that made me rage quit a meeting

András Tóth — Fri, 27 Dec 2024 04:13:14 +0000

When I shut close my laptop and apologized for leaving, it was a big achievement: I hadn't shouted at anybody 🫣. I was just shaking from frustration and anger.

Hi there, folks. This story is about the right and wrong ways of offering help, respect, experience, processing information, and how attempting to save time can sometimes lead to delays.

This story is also in my top 5 worst engineering experiences. I rarely get this angry.

Great plans for a burning issue

At work customer support issues were piling up. We reached a level that were not sustainable: hiring and training support agents were lagging behind. Responding to emails took 2-3 days on average, users were quite frustrated.

My talented teammates were getting to the bottom of it absolutely professionally: data analysts crunched customer issues, grouping them with their volume; PMs narrowed them down to ones that were feasible to implement, interviews with the frustrated users were done by UX researchers, copywriters nailed the right tone and UX designers tested out the right self-help "tiles", each with its own clear explanation and actions. I think this was one of the most professionally researched plans I have ever worked on.

However, there was no patience for its implementation.

"Hey, you need some help?"

While our team had design, research, and many helpers, we were only three full-time frontend engineers who could only partially work on the project. We had ongoing projects plus customer and infrastructural issues to handle (for example, the data analyst of my team had left, so as a frontend engineer, I was fixing the data pipeline—not optimal).

The customer support bottleneck eventually caught the attention of top management. Out of the blue we were offered the help of another team: 6 young engineers.

Brooke's Law states that adding engineers to a late project will only delay the finish of the late project.

Knowing this, I replied that we might not need all six of them. Personally, I needed a data analyst to hand over the fixing of a never-ending data pipeline task in Python, which I was learning as I was fixing a broken database migration. I also thought maybe two more people would be very useful to pair up with, cutting down the coding-pull request-review-fix chains.

But we got an entire team, and stopped working on the exciting new project to prepare a well documented intro for them. I expected we’d explain the finer details when we start. Well, that didn't happen.

"So, it's a very simple task! I think we're done by tomorrow afternoon."

Then came one of the worst meetings of my life: a young (22ish) and inexperienced team lead dominated the entire meeting. He said he’d just glanced at the design slides right before the meeting, and each self-help tile looked very similar to each other: some text and one or two buttons, easy-peasye. He comically underestimated the task at hand and literally said:

Oh, I think this is a very easy task. We're going to be ready by tomorrow afternoon!

This was not a joke. The dysfunction in my team was laid bare in that second. My team lead, who was conflict-avoidant, didn’t say anything. I was looking around in disbelief, trying to see who's gonna react to such an absolutely crazy statement. None did.

Of course, there's no way a new team can push out something that quickly. By that time I saw 600 million times already how requirements change the moment there is working UI code. You cannot rely on assumptions that "there's gonna be only some text and maybe two buttons", you would need your code to be flexible. (For a bit more info see also Kent C. Dodds’ compound component approach).

I asked if he has read the documentation we had written. "Nope," he said without showing any regret whatsoever.

I was enraged seeing that all the effort we put together was going to waste. From going through with our plan, we were running after people who kinda understood some part of it. Moreover, the impossible deadline of "tomorrow afternoon" filled me with dread.

In that moment, I reached my boiling point, shut my laptop, and stormed out of the meeting.

Inside a raging head

The experience soured my mood for months and still angers me today. I felt betrayed by my team lead for not stepping up for our careful plans, for not calling out reckless promising, for choosing his personal safety over team spirit and lastly, for wasting our work.

Luckily, apart from the other team lead, nobody took seriously that crazy estimation, and nobody held us accountable for failing it.

However, I didn’t handle the coming days well, and I’m not proud of it. I was deeply offended, and I would cynically giggle at any setbacks, because I wanted to feel vindicated.

"You can't promise the next day! It's impossible! I told you so!"

I was right, it wasn’t ready the next day or the day after. We even had to roll back a couple of releases as the code hastily thrown together. It was done exactly two weeks later than tomorrow afternoon - and a work that needed refactoring.

Without them, it would have taken us 1 month I think. With them it was 2 weeks of hell, failed releases + refactoring later. Not to mention the human fallout, that costed us working relationships: while I lost faith in my team lead, my negative attitude during those days did affect my literally closest colleague (sitting next to me).

Without me knowing it, that relationship soured to the point that months later, when it was his time to step up for me, he instead jumped on the opportunity to get rid of me. It was a really dark day for me, I couldn't speak to him since.

Now I always measure what and how I say things.

Why new people are more than just more cores in a processor

We kinda demonstrated Brooke's Law: though we finished earlier having this "help", the combined time spent on this, including lost team members was huge.

So why is this law so true?

Unlike moving houses, where more hands bring more boxes, the big picture for a software engineering project has many intricate details that must be understood first. Some of it even must be processed during sleep (have you ever woke up or came out of the shower just having come up with the right approach?)! Not to mention grasping the coding style of the team, or the gotchas of the codebase. And then the human factor: team dynamics that came to be through spoken and unspoken agreements.

When new people arrive they have to feel these out.

Help done right

Combining everything, these are my suggestions:

Trust the devs who are intimately familiar with the problem!
Let them specify what help they would benefit from!
Don’t add too many people at once!
Use the new people to handle distractions, not to create them.
For live coding sessions pair a new and old member: a second pair of expert eyes, even without domain knowledge can help shortening the feedback cycle, so code review turnarounds would be a lot faster.
For the love of everything that is holy! READ THE DOCUMENTATION before promising anything! Check out the current codebase, speak with people who worked on it.

Exploring and getting familiar with alternatives before committing to a solution is an essential part of the job. Work is not eight hours of pure coding, you should not skip the discussions, otherwise you are going to ship the wrong thing, or at least in the wrong format.

But let’s get back to what happened afterward!

Somewhat of a success story...?

hanks to solid planning and company-wide efforts, the customer support bottleneck disappeared. Response times dropped from 2–3 days to just a few hours.

There was a secondary benefit to that: people did not write a second or a third email begging for a response. So not only the cases got resolved faster, also the volume of the work went down.

It could have been done just so much easier...

7+ Years of Experience Converting JavaScript to TypeScript: My Caring Opinions

András Tóth — Sun, 29 Sep 2024 22:14:57 +0000

I started my JS career in 2015, spent a year working exclusively with it, and then transitioned to TypeScript. I’d love to say 'And never looked back again!', but I can’t; since 2016 there’s a chore I have to do basically at every company I worked for: converting existing codebases from Javascript to TypeScript. These are going to be my subjective, sometimes scolding opinions.

In a hurry? Here’s the tl;dr:

The False Sense of Velocity: skipping to deal with data drifting and edge cases is surely faster than dealing with them, but the price will be paid nonetheless.
Data Drifting: When data schemas evolve without a type system following them, it’s not just migration to TypeScript that gets hard, you will be plagued by support issues. Best way to deal with it is to standardize first your data collections and have strict typing afterwards.
Poisonous Optionals: When your data schema lacks uniformity, you would have to deal with handling of undefined properties every time you deal with these. TS is just a reminder, not the cause for it.
any Means Trouble: Using any hides potential issues and makes it harder to track your actual state of TS migration; define first your API types, and type inference will lay out a migration “plan”.
Forgetting about Promises: Forgetting to react to promises either with await or with .then/.catch happens more often than we think. Failing to do so might cause you long hours of investigating weird bugs like an entry created for a missing photo.
Undefined Variables: A classic refactoring mistake in JavaScript when you rename/move out things from scope, but not all references to them get updated; TypeScript helps catch these before runtime.
Unsafe Array Operations: It’s quite easy to forget about edge cases of arrays; yet another area where TypeScript helps prevent this.
The Saga of Magic Code: Complex JavaScript patterns can be very hard to type; but do you actually need them, are they good, recognizable patterns?

The False Sense of Velocity

Every now and then I encounter a JS purist, who sneers at us with their harsh opinion: they simply work way too fast to get slowed down by the extra steps required for TypeScript. Sounds badass, but this confidence usually falls apart when I change the extension from .js to .ts, because I get blasted by the following typical errors.

Data drifting

I wish to start with this, as I rarely read about it in blogs, but it is, in my opinion, one of the hardest parts of TS conversion: the authors start with data having ShapeA a couple of years before the conversion. Then ShapeA changes to ShapeB, ShapeC, then there are competing versions for ShapeD1 and ShapeD2. In the end you will have all shapes of the data in your (probably NoSQL) database accumulated during many years: [ShapeA, ShapeD1, ShapeD1, ShapeB, ShapeD2, ShapeB, …].

An example: recently I had sampled from a Firestore collection items of users. The birthday property had the following types:

type User = {
  // …
  birthday?: string | Date | { time: string } | null;
}

Of course if I use this type that accurately describes what is in the database the entire codebase goes up in flames: hundreds of TS compilation errors show up, while the morale goes down. Usually it’s warning me about potentially undefined values, or missing conversions (e.g. a string is not a Date).

Not dealing with this toxic variability, a developer might feel very productive, but these are going to cause a lot of trouble to customers, customer support and data analysts (maybe we should have an annual “Hug and comfort a data analyst, who puts up with your data leniency” day so we don't forget about these folks?). We waste their time, but us? We’re fast as lightning without the confines of strict types.

After trying to solve it in through million different ways, I reckon the only way of dealing with this is to...

first, define the ideal type you want to work with
and second: standardize the data you have accordingly (which means backing up and sweaty scripting of long running tasks)

Poisonous optionals

If you have paid attention to how the example type was defined you would see how this a problem directly related to data drifting:

There can be a million different ways an expected property to be not in an object.

In a JS codebase (especially if you choose a simple text editor over an IDE) you are not going to get warned about these, since really, there is now way for your IDE to tell if an object passed in as a parameter has or hasn’t the expected property. However TS will warn you about these missing optionals (i.e. not just you might not have birthday.__time__ you might not even have a birthday property) and then you would be forced to cover all these cases (including null as opposed to undefined - take a second look at the type above 🫣). This is usually means to do the repetitive task of writing birthday?.time ? birthDay.time : typeof birthDay === ‘string’ ? new Date(birthday) : birthDay, etc. (of course not in this brainf*** format).

This often leads to a lot of frustration, and not just to devs new to TS. It does feel like having types slow us down.

But in reality this is the consequence of data drifting: whose fault is that you cannot be ever sure whether an object has a birthday property?

How `any` gets in the way of TS migration

I have a clear preference for where to start in a project to do the TypeScript migration and it is where external data enters; either through fetch or through a form.

Let's say that for a given piece of data I have 3 relevant files:

fetch-data.js where the data gets queried from an endpoint
ParentComponent.js where data is partially transformed and passed as a prop to the next component
ChildComponent.js where the passed data from ParentComponent.js is used

Now if during migration I choose to convert to ParentComponent.js and as I don't know what exact data is fetched in fetch-data.js I use any temporarily to silence the annoying compiler, I might set myself up for failure.

Of course, if we had these 3 files clearly laid out to us we would not start with ParentComponent.js, but in real-world we would have hundreds of JS files and when a bug occurs in ParentComponent.js we feel tempted to convert it to TypeScript.

In this case the following happens:

exact shapes of data in fetch-data.js stays unknown
ParentComponent.tsx uses it with any
ChildComponent.js receives it and it's going to be an unknown as well

Now a bit later someone else adds the types to both fetch-data.js and ChildComponent.js. Looking at the extension it seems ParentComponent.tsx got migrated and trusted, but in reality the relevant data for ChildComponent.tsx would be still unknown but in this case we would not even know about it. The type inference would break in ParentComponent.tsx and we are still poking in the darkness in ChildComponent.tsx.

In my opinion this case is worse than having the component completely untyped as I would know to tread more carefully.

To deal with this, I suggest starting from converting the files where data is originating from, which is going to be where the data is fetched or where it is produced through a form.

TypeScript is great at inferring these schemas (unless you do the magic code; see below), so when you incrementally change your codebase you can then rely on these sources being correct.

Order grows out from the seeds of well-defined data sowed at the entry of your data flow.

A real world example is when I finally knew what a validationError object looked like, I could correct a bug of a label for a validation error never showing up, e.g. the component code expected a singular validationErrors.article property, but the actual property was validationErros.articles. This is a super easy thing to miss.

Note, that it was for a reason I have mentioned data drifting and data standardization: if you do these 2 steps correctly, now you are going to deal with robust types with very little ambiguity.

Forgetting about Promises

Let’s say your block of code might receive an image, convert it to another image format, save it to storage and create an entry for it. However, saving the image never gets awaited, and the code always goes to the next step, which is saving the data that might point to a non-existent storage location. Local testing does not find it, only some users complain that sometimes their uploaded photos disappear.

While I haven’t encountered a developer who is fine with this, with JS codebases it happens way more often than people think.

Undefined variables, unsafe array or object operations, optional everything

Recently I have found an ironic bug: an error never got reported as the error message used a variable that was defined in a different scope. No errors, no problem!

As I said, it wastes so much time, because the error might get to you way later when you accidentally stumble upon it in the error logs of your container. Or it’s customers who report it.

This is, just like “forgetting about promises” is a very frequent issue of JS codebases. It’s not a “developer issue”. It usually happens under certain circumstances, for example during a mentally taxing refactoring step: you move code around a lot, and then a variable like this slips through. (Obviously a good test coverage can spot these; that’s for another time.)

Even if you work with very disciplined developers, some errors are just very hard to spot by looking at them, therefore people frequently forget about them. For example there are unsafe array operations: for example you want to grab the title of the first item in an array (articles[0].title) there can be cases when the query returns 0 items, therefore articles[0] will be undefined.

Again, this is an everyday, average slip, it’s not a “character issue” of an (otherwise great) engineer. But we have a tool to warn us, and that’s TypeScript.

The Saga of Magic Code That Could Not Have Been Typed

Finally there is a situation where the “inconvenience of TypeScript” can actually help you write simpler code through making convoluted code painful to write; I will explain what I mean by this later.

The flexibility of JavaScript allows transformations (e.g. add properties to a function) that are extremely complicated to accurately type. I remember a magic function transformer that took a function, stapled variables from a redux store onto it binding the parameters and redux actions and the function together.

The problem was that this custom piece of code was very hard to understand and took a lot of time to for every team member to get it. Contrary to this, working along coding standards saves a lot of time for engineers of an organization: any member from any team is now going to be able to deal with the code without needing to spend time and familiarize themselves with the inner workings of a contraption.

I want to say redux-saga is a similar case because of the usage of generator functions: there is an error by design there, I must mention. I have found typing these generator functions to be extremely hard. Try typing a saga (and using it in another TypeScript file) that for every yields might return a different value type. First an undefined value (as in no explicit returned value), then a Promise and finally an explicit value (say the third yield returns a sanitized user object).

One can argue that typing this and dealing with its ambiguity is just too much effort, therefore TypeScript puts shackles on the brilliant mind of a competent Javascript programmer, but my counter-argument is why do we need this flexibility?

I mentioned “inconvenience” at the start of this paragraph: since most devs who work with TS are just not that level to be able to type these contraptions, they are not going to write these magic functions; which in my opinion is a very good thing.

Writing an extremely complicated function should be only a last resort anyways, after exhausting all simpler options. If TypeScript makes it harder, that’s even better.

Conclusion

In my professional experience, fuzzy, heterogenous sources of data and broken chains of data flow cause the most issues in a TypeScript conversion, however I argue that it is not TS being at fault here; it is the toxic flexibility of JavaScript that delays dealing with the consequences of coding mistakes to runtime.

I sometimes call it “HDD”: hope driven development.

You hope that the data would look like how you’d expect it to look like. You hope that the unit tests are describing the data accurately and you won’t have false positives. You hope it will blow up before it blows up at the user.

While it is exhausting to deal with these errors, it is way cheaper to address these during compile time than waiting until accidents happen to the customers. And for the entire company!

With a solid TS codebase you will unlock your true velocity because then you can rely on your data and the tooling around it.

The Challenges of Working in Big Tech: Interview with an ex-employee part 3

András Tóth — Tue, 20 Aug 2024 05:56:12 +0000

This is the third and last instalment of the interview with my friend about how big tech companies work and how the bureaucracy in these places can really grind someone down. We share these experiences to call attention to mental health safety issues in the tech industry.

Getting Into Big Tech

After I got fired from my previous workplace for not wanting to work 60+ hours a week, I wanted to show that I still had it in me. That’s why getting this job at one of the Big Tech companies became important. I prepared and practised a lot and finally got the job.

During this time, my self-confidence was still very low. So low that I went to a therapist to work on it. The therapist listened to me for an hour and then said, “I am very empathetic, and your story affected me: it lowered my own self-esteem as well, so I'm unsure how to help you.” and then proceeded to charge me without any takeaways. 😅 It was quite a shock, and I didn’t try going to therapy for many years afterwards.

But eventually, I arrived at my new team and stayed there for 6 years.

Who Owns This Button? The Detective Work. 🔍

At this company not all teams own a codebase. In my team, theoretically, we coded half the time and did consultancy the other half. In my case, I only coded about 10-20% of the time because I enjoyed client work more. (Plus, people tended to chase me for things, while my longer-term coding projects didn’t; they were only important for my own long-term goals…)

Often, clients would ask a question obvious from their side: “If I turn on these 2 options, why don’t we have the desired result?”. Those 2 options might be the work of 2 different teams in 2 different repositories with 2 different coding conventions, who might not be aware of each other’s work and might have created incompatible features… It was quite frustrating and time-consuming detective work to dig to the bottom of these requests.

Another goal of the client-facing work was coming up with ideas for new features or necessary improvements that the product teams missed: so basically keeping an eye out for unmet needs and low-hanging fruit. You then supposedly fleshed out your own projects with a proof-of-concept attitude, then handed over the long-term support to a “real” product team. This sounded excellent in theory, but in reality, it was a constant uphill battle. After figuring out which team owned the feature you wanted to change (if any), you had to convince this much bigger team (consisting of many members from product marketing to data science) to allow us to make these changes while the team had their own - often conflicting - priorities.

There was a lot of opportunity for friction: either the team was extremely busy with other things and did not have time to help us get familiar with their code base and coding conventions, or, on the contrary, they really liked the idea, but they wanted to do it themselves (but later…). Even if they agreed to let us do the project, they often did not have the capacity or motivation to understand our changes properly and take them over from us for long-term support. So, our new features were often deprecated soon after they shipped. Once, a product team scolded me over a broken feature we shipped for them, but it turned out that it worked great until they made a change and forgot to regression-test our feature. Since nobody has spent real time getting familiar with our work, this was bound to happen.

This huge barrier of entry and the constant struggle for approval was chipping away at me slowly, and I felt bumbling about complying with each team’s definition of high-quality code.

The Bureaucracy of a Meritocracy

In this company, we always had to find objective-looking, measurable metrics and KPIs (key performance indicators) to prove our existence, both individually and team-wise.

It was rubbing against my soul stronger and stronger when I instinctively knew what really mattered and what would be of great help to our clients, yet it was impossible to find a good metric to make it measurable.

For example, who wants to invest time in measuring having detailed and up-to-date documentation? Yet, it’s a task I felt was very important to do.

Therefore, before any action, there was this block we had to overcome; let’s say if the task took an hour to deliver, then finding a relevant metric and justification took over 2-3 hours. Or at least this is how it felt. And abandoning an idea because of a lack of a good metric wasted so much mental and emotional energy. Plus, normally, you couldn’t just come up with a new metric unless we were in a planning phase; you had to ensure that it would positively affect your team's already agreed metrics.

Disillusionment also crept up when I started doubting our metrics: were they really meaningful?

The goals and KPIs tended to be very forward-looking, and the features actually used by our real-world users at the present time were often neglected and deprioritised.

Some other metrics were brainchildren of stressed-out leaders made up during the beginning-of-year planning. I hated participating in brainstorming sessions where we wanted to develop ideas on moving these KPIs; it seemed so forced and selfish. Yet this was what senior team members like me were supposed to do; this was the path towards further promotion. I felt that if I stayed true to my values, I would never get promoted to the next level.

The same was required individually: there was this very US American end-of-year “ritual” of stepping up and talking about your achievements. Your promotions or just the fact you can stay at the company depended on your “merits” and how you presented them. This was a social game, and

I am not kidding. People spent weeks before the end of the year to prepare and collect all their yearly achievements to ensure they were received well!

Writing about successful collaborations and selling our work internally took a lot of time that could have been spent instead during actual work. To me, it felt like there was no real value to the end users in this. And in order not to forget what you have worked on - which I frequently did - you had to take meticulous notes each day so later you would be able to demonstrate your value. I now realise that my bad memory and my inconsistent ability to do this bureaucracy were symptoms of my ADHD as well.

This also meant that selfish, narcissistic people had a way better chance of moving upward in the ranks, and there were quite a few people like that in management positions. It also heavily favoured people with great communication skills, even in positions which didn’t need communication skills otherwise; for example, being a native speaker gave a huge unfair advantage.

The “No Blame Culture”

On the positive side, I actually appreciated that the impact of our work was important and not the circumstances that counted, e.g. how many hours you have spent in the office. I also loved the “No Blame Culture”: whenever something broke, everyone worked side by side to fix the problem and ensure it would not happen again. Punishing the “culprit” was not a goal.

It felt liberating that everyone always assumed the best of intentions, especially compared to the previous companies I worked at. At the investment bank where I worked previously, if you didn’t reply to an email the next day, they would CC the boss and their boss to make sure you followed up on the email… While here, people understood you might have been busy and only sent a friendly reminder to you instead. I will really miss this solution-oriented culture.

And Then… The Burnout

Slowly but surely, this constant fear of “what if I can’t sell our achievements”, combined with the high effort required just to start anything, chipped away at my motivation.

Looking back, there were signs of the coming crash: for example, I was losing interest and excitement during the above-mentioned KPI brainstorming sessions. I saw excited people around me, but my face gave away that I just could not give a f*** about it, and I could not come up with anything.

Yet another sign was the guilt of procrastination: I had spent a lot of time at the computer, yet I was not working on the important things, and I knew it.

As it was impossible to know the whole feature offering of the company in depth, in my team, we each became experts in 1-2 aspects and helped each other out when relevant client questions popped up. Unfortunately, my speciality eventually got deprioritised within the company and wasn’t actively worked on or even properly supported any more. I wasn’t selfish or wise enough to abandon this sinking ship on time because I truly believed in it. (Plus, I put so much effort into it; I have shipped various projects around it and onboarded some of the biggest clients.) So I was constantly fighting for the importance of this particular product, not just within my team but with the product team as well, which was supposed to own it. The owning team didn’t even properly understand the intricacies of their own product anymore, so I often ended up training their new team members on how it works. This situation was very unmotivating and wasn’t recognised by most people, including my manager (which is understandable as this shouldn’t have been my job). It was a great example of something that didn’t align with the team’s and company’s KPIs any more but was still important for our clients.

Only positive personal interactions slowed the burnout process: if I could help somebody, if we had a good meeting, etc.

How Burnout Kept Me in Harm’s Way

During this time, I had this menacing feeling that “they are about to discover I work very little!”. However, at the last performance review, I received an above-expectations rating, which was quite baffling. Counterintuitively, it became demotivating as I now could not reach out for help and be open internally about the fact that I was struggling because my review praised me. About a year later, it started to become noticeable, unfortunately, just as the economic crisis and layoffs came.

I knew I had problems, and I knew I really needed a change, yet I did not have the energy to make the change. Changing teams or roles within the company required good performance ratings and internal interviews to the same high standard as for external candidates. Plus, my mood was so low I couldn’t even imagine what change would make me more fulfilled.

It’s hard to think about your future when you are in survival mode!

Making the decision to pull the plug and leave the company was also hard as some people call BigTech companies the “Golden Cage”: you are paid well, you have great benefits, flexible working arrangements and motivated, bright colleagues. I’ve worked so hard to be here, and I couldn’t imagine where I could be happy if I’m suffering even under such - on the surface, at least - good circumstances.

Personally, I think I got quite unlucky with the layoffs coming at the worst moment possible. Under normal circumstances, I would have probably eventually gotten the mental health help I needed and gotten out of the hole. It was pretty normal to have a bad performance rating from time to time and given that I had worked there for more than six years, my managers knew what I was capable of when I was not burnt out, so probably they would have given me some leeway. Even if they had put me on a performance improvement plan, that process would have given me months to get my sh*t together, which I probably would have done under pressure. (ADHD people work much better under pressure, at least for a short period of time…)

But all in all, I think this was a blessing in disguise, so I’m grateful that this happened to me. It gave me the necessary kick in the butt to make the changes I needed. And the severance payout gave me the means to take some time off work and really think about my future. It took about six months for me to figure out that I have a passion for psychology and counselling, which is a much better way of helping people than client-facing tech jobs, so that is probably where my career change is leading me. It’s not a happy end just yet, as I’m still in training and not making a living off it yet, but I see the light at the end of the tunnel.

— END OF THE LAST INSTALMENT —

Summary

Hi, this is András again. One of the key topics of this interview was “self-surveillance” (I just made this term up): as companies go bigger, it is getting increasingly harder to figure out if things are going in the right direction. The inability to confidently monitor and understand where things go is then pushed as a “tax” onto the teams: time for coding is now converted into time for holding the hand of the management. The metrics are at least pointing to a more scientific method compared to how it was done previously.

“Weak Ownership” was yet another topic with which I am also personally familiar, and I think it is still in its infancy. Usually, during team formation, a strong sense of “in-group” and “out-group” is formed (see also [“in-group/out-group bias"])(https://en.wikipedia.org/wiki/In-group_favoritism)), which means that outsiders’ moves are watched with suspicion. Especially when bonuses or headcount depend on reaching goals. I have yet to see a team that is not incredibly busy with a backlog worthy of years of work, and I also never saw a company where it was OK just to sit and wait to see if anything comes up. (Note on idleness: it is absolutely necessary for, say, transportation, as if all maintenance crew are out doing busy work all the time, and then you have nobody to respond to emergencies. Yes, it’s inherently ineffective, yet it is a requirement if you want a quick response.)

Thanks for reading the interview! This was the last part. If you have any questions, for me or my friend, just ask away in the comments below!

Do senior devs use terminal/VIM? Do they type faster?

András Tóth — Mon, 24 Jun 2024 16:58:27 +0000

A reply to this great post about productivity of console proved to be quite popular, so I decided to turn it into an article and add a bit of extra.

(Skippable) Little Story About DOS and `config.sys`

First a little story. I was a kid in the 90s and my dad had a computer at home. I totally got sucked into it; mostly to play video games. Back in the day we had DOS (Disk Operating System) and it was terminal based. You started Windows 3.1 from the terminal and not the other way around. 🙂🙃

To juggle with files and folder, I used Norton Commander. It had two panes for two folders and you used F5 for example to copy (if I still remember correctly) from active pane to the other. I've gotten really-really fast with it, so fast in fact, that one day I have accidentally deleted the important looking config.sys file. Since there was no "Bin" back then, and I didn't know about the undelete command, it was a huge trauma to me: ruining dad's computer (which I didn't as I realized later) by being reckless. Later a friend of mine gave me his notes he learnt about DOS configuration in IT class, and I could recreate the file (and go back to playing games that required EMS memory handling instead of XMS).

So it is safe to say I was growing up not using the mouse and doing everything in the terminal. Yet, I have no particular love for it.

Do You Need Serious Terminal/VIM Skills?

I try to use a great IDE as much as possible and the terminal as little as possible.

Why? Let's say I'm writing and fixing unit tests. The jest integration runs in my Webstorm works as a breeze: I get diff, I can click on the failing test, it jumps to the relevant line in the codebase, I can put in a breakpoint if I want it and so on. Lightning fast, I have everything at my hands, no need to manually scroll, load, struggle with something. 21st century experience.

I do advocate for learning the keyboard shortcuts while using the IDE and also to learn tricks like multiline cursor editing and so on, because they save so much time.

Do you need great typing speed? Is using a mouse an anti-pattern?

Now, about typing speed. When I code, I write a little and then mostly I think for a while, then type out my code, then check the results (either through a unit test or on the frontend). It's more like a quick chess game than a horse race. It's not a typing competition, it's not a copy-paste-modify extravaganza. In case I've written the samish thing multiple times I tend to step back to evaluate what to do with this repetition. Do I need to extract the code or am I expecting them to grow in a different direction very soon, therefore no need to extract the code? It requires stopping and thinking, nonetheless.

Half of my "coding time" is actually also talking with stakeholders, making agreement with my colleagues on what to work on and what not to work on. Sometimes you do a lot of damage to a codebase if you start solving the problem in the wrong place (e.g. is doing the join on the frontend the right place for it or is it better suited in the database?) and sometimes you have to advocate for an easier path to take.

Terminals, CLIs and Mental Mapping

Finally, about CLIs: personally, I hate command line interfaces. They violate the "avoid mental mapping" principle of clean coding: you have to memorize the flags for each CLI tool, remember if -f stood for file or force or folder or something completely different.

There is no "Codex of CLI Conventions", no "Knights of Inter-CLI Consistence". Every CLI is special in its own ways, and to remember the quirks of each is mentally taxing for me.

The only things I do in the terminal are basically "npm start" or "npx something something". Very, very limited instructions.

Why People Might Prefer Terminal over Full-Fledged IDEs?

This is going to be pure speculation on my side:

maybe there is this "Coder/Hacker" image which glorifies stream of logs in consoles
or people are influenced by a famous engineer who uses terminal for everything
can be a bit of impostor syndrome: the Big Fish uses terminal and VIM therefore if I don't they will think I'm just an impostor; you are not!
neurodivergency 1: some people have very low tolerance to any type of slowness, they prefer high responsivity; IDEs, since they provide many functions tend to have problems with that time-to-time
neurodivergency 2: some people have excellent mental mapping abilities (great, reliable memory) like my university math professors; I assume they tend to prefer tools with hardcore mental mapping; since it's a "superability", not the norm, I would not force it on others, personally (I don't have it - I love clean code for this reason)
using console is a great way to freak out grandma or your parents that you are so intelligent you can speak directly with the CPU

Do Senior DEVs Use Terminal/VIM then?

I think most of us do not. Personally, I feel there tend to be a lot of friction with the people who push CLIs and bash scripts on others as they increase the mental load on others who are neurologically not that great at mental mapping. If you can keep common projects working without hacking too much in the terminal, without adding magic lines to .bashprofile, you should do your own thing. Also if you are working alone, you are 100% free to choose the methods that let you stay in the zone.

Therefore my productivity hack is to get a good IDE and learn it well! The shortcuts, the multiline editing capabilities, the integrations (in my favorite IDE, you can run an SQL statement from a TypeScript to manually test your query; how cool is that?).

In a team, you have to code and plan your productivity in accordance of the tools available. If you "muscle" your code through by typing quickly and a lot, there is a chance you will ignore very effective coding assistance tools, while you have the illusion of productivity since you type a lot, and press Enter a lot.

In reality you might be doing double/triple work. Think before you strike!

Why I (mostly) never write `const fn = () => {}`

András Tóth — Fri, 14 Jun 2024 19:16:21 +0000

A short article here on a subjective/objective manner.

Compare this:

const justAConstant = 1244430;
const conditionalValue = justAConstant > 13 ? 'yes' : 'no';
const updateResult = updateInDb(conditionalValue);
const updateInDb = value => fetch.post('/url', JSON.stringify(value));

with this:

const justAConstant = 1244430;
const conditionalValue = justAConstant > 13 ? 'yes' : 'no';
const updateResult = updateInDb(conditionalValue);
function updateInDb(value) {
  return fetch.post('/url', JSON.stringify(value));
}

Let's start with the trivial matter: while function is hoisted and you can declare wherever you want them (I like to define functions that solve partial problems under the function that solves the main problems) the order of constant declarations matter.

In the above example will throw this error: ReferenceError: can't access lexical declaration 'updateInDb' before initialization.

This is, as I said, trivial, very easy to fix. However there's something more appealing to me in the second version:

Separation of values and functions that operate over values. A quick glance at the second example will immediately show me where I can find the business logic, because they look different.

In UX design we plan for the ease of traversing the UI: things that are different must look different.

While your preference to use named functions vs. named unanymous functions saved as constants is subjective it is good to know that categorization of syntactical elements can be objectively confusing or clear.

What's worse? `NullPointerException` or `try (error) {...} catch {// do nothing}`?

András Tóth — Mon, 06 May 2024 19:56:35 +0000

Sir Charles Antony Richard Hoare has an excellent presentation on why null was a bad idea.

There are even programming languages that try to eliminate the very problem of receiving a random null value out of blue: Elm is such language.

In practice

Usually when I encounter a null related error the fix were kinda straightforward:

Check the stack trace
Read the code in the location
Either understand it immediately ("Oh, me stupid donkey, I tried the wrong parent property!") or put a debug point in.
Debug the code.
Fix and cover the error with test cases.

So, on average, I would say these are maybe 20-minute long adventures.

When you swallow the error on the other hand...

Let's see this code:

try {
  const result = await apiCall();
  const unboxedResult = await result.json();

  sendToSomeoneElse(unboxedResult);
} catch {
  // nothing here!
}

Now this is way worse! I have no clue why sendToSomeoneElse was not called. Unless I'm actively developing this particular block of code I would not have any suspicion that there was an error in the first place!

The legendarily bad `angularjs` template

There was 2 key design mistakes in version 1 of angularjs that caused countless hours of fruitless, laborious debugging sessions.

1. Breaking convention of `html`

When you read this: <div data-something="This is a string!">something</div> you know that the data-something attribute is now having a "This is a string!" string.

In first version of angular you could write this:

<div ng-repeat="name in names" ng-include src="'template.html'">

Note the moment where the convention is broken: "'template.html'"

Even though we expect the HTML attribute to be parsed automatically to a string value, the angular engine differs here: if it is not enclosed in ' single-quotes, it tries to interpret it as an expression or - simply - as a variable.

2. All templating errors were swallowed

Now this is where the real problem started. In case you forgot the single-quotes (and many, many people forgot it), you would now have an invalid expression. However the decision to swallow or templating errors (for whatever reason) meant...

you have had these innocent looking templates that just did not work as you expected!

I still remember vividly when my colleague from another team decided to escalate the question of "Why does not this angular snippet work???" to the "frontend guild". I only answered it immediately: you missed the single-quotes. The mind of my colleagues were blown, how the hell did I know it so quickly?

The reason was that in my previous workplace, with my previous team I had burnt my fingers with this very thing. We also had no clue what was going on, so:

I wasted many hours alone.
I wasted then my team members' time to debug the issue.
We then escalated to a larger group of devs to figure the issue and wasted their time...
Until someone, just like me later, knew that this is a typical angular error.

So I conclude swallowing errors is a grievous mistake and according to my anecdotic evidence, wastes more time than the well-established NullPointerException.

My love-hate relationship with JS/TS and CSS

András Tóth — Thu, 11 Apr 2024 11:13:55 +0000

INSERT AI GENERATED HEADER IMAGE

I frequently encounter comments that love Javascript and CSS dearly. That is fine, but they reply in quite harsh manner when I point out several unmitigated mistakes of these languages.

So this is how I see the stack as a professional JS/TS developer who worked with them for around 8/12 years (I used CSS for longer than JS).

In the browser we have a lack of choice: you have Javascript, CSS and WASM. You can't get a more performant language, you can't get a higher level language: whatever you code must boil down to these options.

I contrast it with any other operating system, where you have a huge array of languages.

Many years ago, a lot of companies moved their legacy platform-based solutions to the web. I was working once on a project that recreated (with better UX) a chat application running on Windows only. By moving to the web we instantly gained MacOS and Linux users.

We could do this, because essentially the browser became a mini operating system. If this is the case then we should treat it as such and expect the variety we have when we work with an OS.

My next point is that...

languages (however beloved) in the browser were designed during a much different stage of the internet.

People who hate CSS usually hate it, because it has so many features and optimizations about how to create pleasing documentation (see also: margin collapse feature). On the other hand many of us have to deliver large scale applications that have very interactive UI; a thing for which CSS was not built (even though it is getting better at).

People who hate JavaScript hate it for its quirks and gimmicks (see also: [] + {} === 0 vs {} + [] === [object Object]) which came from a person tasked to write a language in a week and he chose these and also because of backward compatibility of the language. Yet another reason is that fully dynamic languages suck at scaling: you end up with MDD: memory driven development (in other words: you are cool if you remember everything you wrote, 'cause the IDE can't help you), which is only not a problem when you code alone.

Now all these limitations were and are somewhat mitigated by an awesome community, who adds new elements to languages, like flex to CSS.

But these are mitigations instead of purpose-building. Imagine you want to fix throughput of trucks by chaining together many trucks; but it would be better to transport cargo on rails.

JavaScript, TypeScript, CSS are not bad languages, and I can be very productive working with them. But, and that's a big but, it's quirks and problems are causing constant troubles, especially for junior and mid-level engineers. The former are utterly confused at the quirks, the latter rage-quits problems and brute force patterns, like TailwindCSS or OOP or FP onto languages that will never have the guarantees and optimizations for those approaches.

As I said, I don't hate the languages of the Internet, but I wish for a bigger dose of healthy criticism and thinking out of the box. After all, we have now a huge amount of real world use cases which we didn't have when CSS and JS were designed; it is normal to time-to-time to rewrite basics to better align with usages.

It is foolish to think we can predict how tech will be used; it is even more foolish not to react how tech is actually used.

I don't even dare to suggest things like "Can we have a separate engine for the case when I don't have a document, but I do have rich UI inputs?", I just want to state the problems here.

DEV Community: András Tóth

Tech Zen Wisdom: Abstraction

The Anatomy of a Software Engineer

The Non-Reusable Knowledge

Knowing a Programming Language

The Ecosystem of a Language

Platform-specific Gotchas

Invaluable Product/Domain Knowledge

Personal example

Reusable Knowledge

Engineering Principles and Instinct

Problem Solving Skills and Engineering Instinct

Personal Productivity Management

Growing Lasting Knowledge

Communication Skills and Solving the Problem at the Right Level

Summary

Refactoring Towards Pure Functions

Black and White Thinking

Spotting a Useless Class

A class Without Methods

A class Without (Serious) Members

Observing the Result

Working Backwards from Usage

Cleaning Up a Long Component (React)

Summary

What's the point of a rockstar developer?

Do you need classes in JS/TS? [2025 version]

The point of using a class

The rise of Object Oriented Programming

Good example: database connection

Bad example: REST handlers

Conclusion of the examples

Understanding the clash between OOP and JavaScript's language design

When to refactor a class

A useless class: a quick example

Conclusion

Note

Tech stories: the wrong type of help that made me rage quit a meeting

Great plans for a burning issue

"Hey, you need some help?"

"So, it's a very simple task! I think we're done by tomorrow afternoon."

Inside a raging head

Why new people are more than just more cores in a processor

Help done right

Somewhat of a success story...?

7+ Years of Experience Converting JavaScript to TypeScript: My Caring Opinions

In a hurry? Here’s the tl;dr:

The False Sense of Velocity

Data drifting

Poisonous optionals

How any gets in the way of TS migration

Forgetting about Promises

Undefined variables, unsafe array or object operations, optional everything

The Saga of Magic Code That Could Not Have Been Typed

Conclusion

The Challenges of Working in Big Tech: Interview with an ex-employee part 3

Getting Into Big Tech

Who Owns This Button? The Detective Work. 🔍

The Bureaucracy of a Meritocracy

The “No Blame Culture”

And Then… The Burnout

How Burnout Kept Me in Harm’s Way

Summary

Do senior devs use terminal/VIM? Do they type faster?

(Skippable) Little Story About DOS and config.sys

Do You Need Serious Terminal/VIM Skills?

Do you need great typing speed? Is using a mouse an anti-pattern?

Terminals, CLIs and Mental Mapping

Why People Might Prefer Terminal over Full-Fledged IDEs?

Do Senior DEVs Use Terminal/VIM then?

Why I (mostly) never write `const fn = () => {}`

What's worse? `NullPointerException` or `try (error) {...} catch {// do nothing}`?

In practice

When you swallow the error on the other hand...

The legendarily bad angularjs template

1. Breaking convention of html

2. All templating errors were swallowed

My love-hate relationship with JS/TS and CSS

A `class` Without Methods

A `class` Without (Serious) Members

When to refactor a `class`

How `any` gets in the way of TS migration

(Skippable) Little Story About DOS and `config.sys`

The legendarily bad `angularjs` template

1. Breaking convention of `html`