Forem: Javier Toledo

Abstractions, Components, Services, and Libraries in Software Projects

Javier Toledo — Thu, 31 Oct 2024 16:30:26 +0000

In software projects, terms like abstractions, components, services, and libraries are often used in daily communication, and sometimes, it becomes confusing. They all describe reusable code, but each has specific connotations that help engineers communicate more effectively. Here's a brief overview of each.

1. Abstractions

Abstractions simplify complex systems by hiding unnecessary details and providing a simplified interface. For example, a data access layer abstracts database operations, allowing developers to work with higher-level concepts without dealing with SQL queries. This is a very broad term because any component, service, or library is indeed an abstraction, but we tend to use it to emphasize that we're hiding part of a problem's complexity.

Using abstractions is essential in computer science because, otherwise, our only tool would be electrical signals coming and going through a cable. Zeroes and ones abstract us from remembering the correct voltage representing an activated or deactivated state in a transistor. Logic gates are abstractions of a bunch of transistors, processors are abstractions of logic gates, and this goes all the way up to data structures that map to real-world concepts (like an invoice) or windows drawn on a screen (which are indeed just code drawing colored dots here and there).

2. Components

Components are modular, self-contained parts of a system that encapsulate specific functionality. They allow us to group the related code and better manage code responsibility (i.e., all the code related to managing tickets goes into the ticketing component). They are designed to be reusable and loosely coupled, meaning they interact with other components through well-defined interfaces. Component is still a generic term that can refer to almost any reusable piece of code. An example is a "user login form" in a web application or a set of functions that allow your software to make financial calculations.

3. Services

Services are independent components that provide specific functionality, often over a network. They are commonly used in service-oriented or microservices architectures, such as a "payment processing service" that handles payments through APIs. A service's key distinction is that it runs independently from the main program as a separate program so that it can be developed separately. The way to use a service is through the operating system's standard functions (Like inter-process messaging, files, pipes, or network messages).

Suppose you're developing an application that depends on a service. In that case, you'll need to start that service (Often a different app) before starting your application, and if you stop the service, your app will stop functioning. This is extremely useful when running your app on one computer and the service on another, which essentially enables the Internet. All websites are services running on someone's servers that the browser in our machine uses.

4. Libraries

Libraries are collections of reusable code that provide specific functionality to be embedded in your program, such as a "date manipulation library." Unlike services, libraries are distributed as part of the application code in the same program, so they cannot run independently on different machines. In other words, when we use libraries, they become part of our code in the final executable.

Dynamic libraries are a feature of modern operating systems that prevent common libraries from being duplicated in all programs. Because these libraries are often distributed independently, they can be confused with services, but they behave as if they were embedded in your app without any communication mechanism. The operating system dynamically links them when your app starts. When a program doesn't use dynamic libraries, we say it's a statically linked binary and has the advantage of being runnable anywhere without installing any dependencies.

Summary

Abstractions simplify systems by hiding details.
Components are reusable parts of a larger system.
Services provide functionality independently, often distributed.
Libraries are reusable code collections embedded in applications.

Libraries and services can be considered components of a larger system, as they encapsulate specific functionality and enhance the overall system architecture. Furthermore, all these concepts are ultimately abstractions, as they simplify complex functionality and make it easier for developers to work with software systems. These terms are important because they help us discuss how to reuse our code or use third-party code when creating new software.

Will AIs Replace Software Systems As We Know Them?

Javier Toledo — Fri, 02 Jun 2023 21:29:07 +0000

Machine learning models draw much of their inspiration from biological brains. Composed of millions of neurons working in unison, these models are extremely powerful. However, like biological intelligence, they are susceptible to occasional errors or confusion. By structuring data, enriching it with metadata, or setting guardrails on the way it's processed, we can significantly enhance their accuracy. This improvement is feasible because we're enhancing a system with excellent computational abilities and superior memory (traditional computers) with robust machine learning models capable of solving problems that cannot be easily described with mathematical formulas or code.

This scenario arises because AI and traditional computing are based on fundamentally different computing models. AI exhibits the capability for "Fuzzy Logic", which relates to understanding problems with imprecise inputs and outputs, such as recognizing a human face in various positions or transcribing sound from a noisy recording. In contrast, traditional computers operate on "Exact Logic", in which both the inputs and outputs can be described with high precision, and any variation must be explicitly encoded. Examples of such operations include performing mathematical computations or removing all uppercase letters from a paragraph.

Consequently, when AI models and traditional computers collaborate, their combined effectiveness significantly increases. Leveraging their individual strengths, they form a synergy analogous to our relation with the applications we use every day. The apps on our mobile phones and computers give us almost superhuman abilities, like perfect and virtually limitless memory, the potential to visualize and act on unusual health data, or even talk in real-time with someone on the other side of the globe. Unlike us, AI applications don't require user interfaces as they can swiftly process and operate on raw data. However, they can use APIs and databases, in the same way we use apps and notepads.

In my view, AI is not here to replace traditional software. Instead, it brings it to a new level by giving us tools to introduce features that were unthinkable just a year ago. AI will empower us to build more intelligent machines with impeccable memory that can interact with humans in more natural ways while retaining existing computer capabilities.

So software will likely remain the same under the hoods, but the ways we interact with computers will likely change radically.

We can now create machines that can talk.

Don't waste time building another API, let the machines make them for you with the Booster Framework!

Javier Toledo — Tue, 11 May 2021 17:37:35 +0000

Building a great API is not trivial, you have to design the data structure, choose the right connection mechanism, implement handlers for every endpoint, serialize/deserialize the data and validate it before accepting it in your business logic.

In addition to that, it is often necessary to build API clients for front-end applications or for other services in order to make use of the functionality offered by your service.

If you use GraphQL, the second part can definitely be simplified, as you can use any standard GraphQL client to query the system, but manually building and maintaining schemas and resolvers is still such a hassle that some teams might prefer to stay in REST.

Boost your API with CQRS!

The Booster Framework introduces a very different approach to building APIs: not doing it at all!

This is only possible thanks to the opinionated implementation of the CQRS pattern and Booster's inference capabilities. Let's walk through the structure of a typical Booster application before going back to APIs.

In a Booster application, most functionality is defined in commands. A Command is a data structure that has a handler, like this one that processes a backflip:

@Command({ authorize: 'all' })
export class PerformABackflip {
  public constructor(
    readonly personName: string,
    readonly personAge: number
  ) {}

  public static async handle(command: PerformABackflip, register: Register): Promise<void> {
    const luck = Math.rand()
    if (command.personAge > 35 && luck > 0.5) {
      register.events(PersonSurvivedABackflip(command.personName)
    } else {
      callAnAmbulance()
      register.events(AmbulanceCalled(command.personName)
    }
  }
}

When a command handler is processed, it finishes by writing one or more events into the event store. In this case, a PersonSurvivedABackflip event for lucky or young people, or an AmbulanceCalled for the rest of us 😅.

An Event is just a data structure that looks like this:

@Event
export class PersonSurvivedBackflip {
  public constructor(
    readonly personName: string
  ) {}

  /* We define the `entityID` method to help Booster match 
  the event with the corresponding entity */
  public entityID() {
    return this.personName
  }
}

These events are later reduced into entities that represent the current state. The reduction is carried out by reducer functions that look like these:

@Entity
export class Person {
  public constructor(
    readonly name: string,
    readonly backflipTrials: number,
    readonly backflipSuccesses: number,
  ) {}

  @Reduces(PersonSurvivedBackflip)
  public static reduceSurvival(
    event: PersonSurvivedBackflip, 
    currentPerson?: Person
  ): Person {
    return buildNextPersonObject(currentPerson, true)
  }

  @Reduces(AmbulanceCalled)
  public static reduceFailure(
    event: AmbulanceCalled,
    currentPerson?: Person
  ) {
    return buildNextPersonObject(currentPerson, false)
  }

  private static buildNextPersonObject(
    currentPerson?: Person, 
    success: boolean
  ) {
    const trials = (currentPerson?.backflipTrials ?? 0) + 1
    let successes = (currentPerson?.backflipSuccesses ?? 0)
    if (success) { successes++ }
    return new Person(
      event.personName,
      trials,
      successes
    )
  }
}

Securing queries with Read Models

At this point, the CQRS design helped us to separate the data schema that the system accepts (commands) from the state data schema (entities). This in itself already simplifies the API design: The API schema could just match the command and entity schemas, and we could call that a nice API. But before calling it a day, we need to make an extra consideration; Allowing direct API access to entities would mean no restrictions on data access, so private fields like password hashes or bank accounts would become accessible. That's why Booster adds Read Models to the mix.

ReadModels are eventual consistent caches of the internal state. They're not only a way to filter which fields you want to make accessible, but they can also aggregate related data or make small data transformations to optimize reads. Accessing read models is highly performant and they're updated in real-time when data changes, pushing these changes to the client applications.

A typical read model that projects a single entity would look like this:

@ReadModel({ authorize: 'all' })
export class PersonReadModel {
  public constructor(
    readonly name: string,
    readonly backflipTrials: number,
    readonly backflipSuccesses: number,
  ) {}

  @Projects(Person, 'name')
  public static projectPerson(
    entity: Person,
    currentState?: PersonReadModel
  ): ProjectionResult<PersonReadModel> {
    return new PersonReadModel(
      entity.name,
         entity.backflipTrials,
      entity.backflipSuccesses
    )
  }
}

Inferring APIs from code!

At this point, we could build a very nice, useful, and secure API by just copying the schemas from the classes decorated as Command or ReadModel, and that's exactly what Booster does for you!

Booster analyzes the class structure of all classes decorated as @Command or @ReadModel in compile-time, generating metadata that is used in deploy time to generate a GraphQL schema and provision all the cloud resources required to make the application work, including API gateways, lambda functions, containers, permissions, and even the database tables to store the events.

For some people, this might look similar to maintaining the schema in a regular GraphQL schema file, because, at the end of the day, you're still expressing the schemas as Command and ReadModel classes, but Booster brings many extra advantages to the table:

Commands, Read Models, and all their usages are type-checked in compile-time, reducing or eliminating the likelihood of making mistakes.
No errors can be introduced when serializing/deserializing data because this is done transparently by the framework.
When you update a command or a read model, the API is updated automatically, you don't need to change any other files.
Resolvers are hidden under higher-level abstractions like commands or read models, so you don't need to deal with low-level protocol nuances.
All Read Models support WebSockets by default, so there is no need to implement any extras for real-time support in your applications.

To summarize, by writing highly semantic code and letting the machine do the heavy lifting, Booster allows you to build fully functioning real-time APIs in a breeze, making everything else work out of the box, and saving a ton of time that you can use to add new use cases, write better tests, or manage elusive corner cases.

Try it!

Booster is a 100% open-source project developed by The Agile Monkeys. You can get its full potential for free and with no hidden fees. The typical Booster application can be run on the free tier in AWS, but it also has experimental support for Azure and Kubernetes, so you can run it locally using Minikube.

Learn more about Booster on the official website, the documentation, or the Github project.

If you try it out, be sure to let us know what you thought of it on the project’s Discord channel!

Playing with promises and concurrency in TypeScript

Javier Toledo — Tue, 24 Nov 2020 22:17:48 +0000

I still remember how hard it was to understand promises the first time I learned them. Modern languages have built constructs like JavaScript's async/await to make it easier to synchronize processes and keep things simple. With async/await, you can write asynchronous code as if it was synchronous, but as with any abstraction, understanding the underlying mechanisms will help you to understand what's going on when things start behaving in unexpected ways.

We recently found an issue that drove our entire team nuts for a couple of hours. We deployed a lambda function to AWS that performed several tasks concurrently. To do that, we wrote code that looked like this:

async function task1(): Promise<void> {...}
async function task2(): Promise<void> {...}
async function task3(): Promise<void> {...}

async function doAllTheThings(): Promise<void[]> {
  await Promise.all([task1(), task2(), task3()])
}

This worked nicely... until one of the tasks failed. When that happens, Promise.all is automatically rejected, and the doAllTheThings method stops "awaiting", no matter what's the state of the other tasks. In our case, it looks like once the lambda returned the error response, it was killed, canceling the remaining ongoing tasks without notice. There's a shiny new Promise.allSettled method introduced in Node 12.9 that waits for all promises to either be fulfilled or rejected before emitting a response, but it's not available if you're not targeting ES2020 (which is our case). Discussing ideas to solve this without using the new Promise.allSettled method, we realized that the team had different levels of understanding of what was actually going on under the hoods, so... time for a back-to-basics article!

What is actually a promise?

Starting from the beginning, a Promise is not black magic sorcery, it's just an object that is smartly designed to hide the complexities of dealing with asynchronous code. You can even create your own custom promise objects if you want. This is a simple promise implementation to help you understand the basics:

class MyOwnPromise<TValue> {
    /* The promise holds the value, which is initially "unknown", meaning
     * that the promise is "pending". Once this value is set, 
     * we say that the promise is "resolved". The error will also be "cached" */
    private value?: TValue = null
    private error?: Error = null

    // Callbacks set before fulfillment are put in these queues
    private thenQueue: Array<(value: TValue) => void> = []
    private catchQueue: Array<(error: Error) => void> = []

    /* The constructor gets an `execFunction` with the user's code.
     * This function is asynchronous and calls the `resolveCallback` when the process
     * is fulfilled or the `rejectCallback` function when it isn't. */
    public constructor(
        readonly execFunction: (
            resolveCallback: (value: TValue) => void, 
            rejectCallback: (error: Error) => void
        ) => void
    ) {
        /* The user's `execFunction` is called in the constructor, this is important
         * to understand that any promise you create starts running right away, 
         * no matter if you await for it or not */
        execFunction(
            (value) => {
                /* When the user calls to the `resolveCallback`, we save the value
                 * and call the `then` callbacks to notify the user about the
                 * resolved value */
                this.value = value
                for (const thenCallback of this.thenQueue) {
                    thenCallback(value)
                }
            },
            (error) => {
                /* When the user calls to the `rejectCallback` with an error,
                 * we cache the error and call the `catch` callbacks in the queue. */
                this.error = error
                for (const catchCallback of this.catchQueue) {
                    catchCallback(error)
                }
            }
        )
    }

    /* The user calls to `then` to receive a callback when the promise
     * is resolved. */
    public then(callback: (value: TValue) => void) {
        if (this.value) {
            /* When the promise is resolved, the callback is called right away.
             * This is important, and means that the user don't need to know 
             * if a promise is fulfilled or not before registering their callback.*/
            callback(this.value)
        } else {
            // When is pending, we append the callback to the queue
            this.thenQueue.push(callback)
        }
    }

    public catch(callback: (error: Error) => void) {
        if (this.error) {
            /* In the same way, when there's an error, we just send it to 
             * the callback right away. */
            callback(this.error)
        } else {
            /* When there are no errors, we append the callback to the queue */
            this.catchQueue.push(callback)
        }
    }
}

Using this code as a reference, we can see that the most important properties of the promises that are important to remember:

They encapsulate asynchronous code, but they are not processes.
The asynchronous code is started right away no matter if the promise is awaited or not.
Promises smartly cache their values and errors, so the user doesn't need to know the internal state of the promise to deal with it.

What do async/await actually do?

Okay, this might sound like it has nothing to do with async/await, so let's see first how our MyOwnPromise is used. Let's say I want to "promisify" a task that takes some time and can fail with an exception. I can do this:

// I create my promise, my code will be started right away
const myOwnPromise = new MyOwnPromise<string>((resolve, reject) => {
    try {
        resolve(longRunningTask())
    } catch (error) {
        reject(error)
    }
})

// If I want to receive the value once the process is completed:
myOwnPromise.then((value) => console.log('My value is ' + value))

// To log the errors:
myOwnPromise.catch((error) => console.error('Ooops: ' + error.message))

Async functions and the await keyword were introduced in ECMAScript 2017. The async keyword transforms a function into a "promise builder". It forces a function to return a promise that is fulfilled with any value it returns or rejected with any exception raised. This means that we can rewrite our previous code like this:

// I just need to wrap my `longRunningTask` in an async function to build my promise. I can do this only because my task runs synchronously. If it was asynchronous, I'd need to wrap it in a new promise object anyway.
const myOwnPromise = (async () => {
    return longRunningTask()
})()

// Everything else works in the same way because the returned object is a promise
myOwnPromise.then((value) => console.log('My value is ' + value))
myOwnPromise.catch((error) => console.error('Ooops: ' + error.message))

The await keyword waits for a promise to be fulfilled and unwraps its value. If the promise is rejected, it throws the error as an exception. So we can finally rewrite our code like this:

const myOwnPromise = (async () => {
    return longRunningTask()
})()

try {
    // I just need to "await" for it:
    const value = await myOwnPromise
    console.log('My value is ' + value))
} catch (error) {
    console.error('Ooops: ' + error.message)
}

So async/await basically makes async code feel like it's synchronous code, but the most important thing to remember at this point is that all the versions of the code in this section are equivalent, async and await are just convenient syntactic sugar to help us reason about our asynchronous code, but the promise objects are still being created under the hoods in the same way. Promises are run when they're created, and we can play a bit with the awaits to achieve different execution schemes:

1. Running a sequence of tasks:

This is the easy scenario. Awaiting the promises as they are created we can block them from running until the previous one is completed. You often do this when one task require previous tasks results:

const result1 = await task1()
const result2 = await task2(result1)
const result3 = await task3(result2)

2. Running the tasks concurrently placing the awaits strategically

If you create all the tasks without immediately awaiting for them, they'll run concurrently, but managing errors could be tricky. In this case, all tasks will run concurrently, but if, let's say, task2 fails, it will wait for task1 to finish before raising the exception.

const promise1 = task1()
const promise2 = task2()
const promise3 = task3()

const results = [
    await promise1,
    await promise2, // If this one fails, we won't notice until `promise1` is fulfilled
    await promise3
]

3. Running tasks concurrently wrapping them in another promise!

Once you understand how promises, async and await work, you can combine them to achieve advanced behaviors. For instance, we could emulate what Promise.all do wrapping the whole process in a new promise that is only resolved when all the promises have been resolved and rejected immediately on the first rejection:

function customPromiseAll(...promises: Array<Promise<any>>): Promise<void> {
    // We initialize an `fulfilled` boolean array of the size of `promises`
    const pending = promises.map(() => true)
    return new Promise((resolve, reject) => {
        promises.forEach((promise, index) => {
            promise
                .then((value) => {
                    // When a promise is resolved, we store this fact in our array
                    pending[index] = false
                    // If there are no pending promises, we can resolve our main promise
                    if (!pending.find((isPending) => isPending === true)) {
                        resolve()
                    }
                })
                .catch(reject) // Any failure in one of the promises will make the main promise rejected
        })
    })
}

And back to our original problem: Making sure that we properly wait for all our promises to be settled (resolved or rejected). We can implement our own version of Promise.allSettled like this:

type PromiseResult = {
    status: 'pending'
} | {
    status: 'fulfilled',
    value: any
} | {
    status: 'rejected',
    error: Error
}

function customPromiseAllSettled(...promises: Array<Promise<any>>): Promise<PromiseResult[]> {
    // We initialize a `results` array of the size of `promises`
    const results: PromiseResult[] = promises.map(() => {
        return { status: 'pending' }
    })

    return new Promise((resolve, reject) => {
        function resolveIfNothingPending(): void {
            // If there are no pending promises, we can resolve our main promise
            if (!results.find((result) => result.status === 'pending')) {
                resolve(results)
            }
        } 

        promises.forEach((promise, index) => {
            promise
                .then((value) => {
                    // When a promise is resolved, we store the value and status
                    results[index] = { value, status: 'fulfilled' } 
                    resolveIfNothingPending()
                })
                .catch((error) => {
                    // When there's an error, we store it in the `results` array too
                    results[index] = { error, status: 'rejected' }
                    resolveIfNothingPending()
                }) 
        })
    })
}

Conclusions

In this article, we've gone through the internals of promises, this little, but powerful object that significantly simplifies how you deal with asynchronous code. We've seen how there's little magic in this truly magical object, and how you can use promises, async and await to build complex behaviors. In a production project, I wouldn't recommend implementing your own promise classes or combinator functions if you can use functions like Promise.allSettled, but understanding promises well is definitely an ace up your sleeve in your developer tool kit. I hope you liked it!

Cover photo by Gerrie van der Walt on Unsplash

*Disclaimer: I edited the code samples in VSCode to make sure the syntax is correct, but haven't run them in real scenarios. If a code snippet doesn't work, let me know in the comments, I'll be happy to fix it!

Currying in TypeScript (just for fun)

Javier Toledo — Tue, 23 Jun 2020 10:30:35 +0000

Let's have some fun with TypeScript syntax. Thanks to the fat arrow interface, you can easily match (with some caveats) one of the best features of Haskell called currying. Currying is the ability to partially apply a function. Let's build a small function that concats strings first, we'll see a situation on which this technique can be useful.

An obvious reference implementation for our cat function could be:

function cat(a: string, b: string): string {
  return a + ' ' + b
}

But this function can't be applied partially if we call it with just the first parameter, we'll have a funny result (thanks JavaScript):

cat("hello")
=> "hello undefined"

In Haskell all functions are curried by default, so the obvious implementation will behave very differently:

cat :: String -> String -> String
cat a b = a ++ " " ++ b

-- Calling it with one parameter returns a 
-- partially applied function
let catHello = cat "hello" 

-- we can apply the other parameter later
catHello "World" 
=> "Hello World"

The fat arrow syntax and TypeScript type annotations allow us to implement currying in a ~~non really that~~ surprisingly similar way. The trick is very easy, we just need to nest single-parameter functions that return a function for the next parameter, writing the implementation in the last function:

let cat: (a: string) => (b: string) => string =
    (a) => (b) => a + ' ' + b

// To apply the whole function, you'd need to pass 
// the parameters separately:
console.log(cat('Hello')('World'))
=> "Hello World"

let catHello = cat('Hello')

console.log(catHello('World'))
=> "Hello World"

If you're wondering how this can possibly work: A function defined in another function can access the scope of the previous function via closures, so inner functions can see the parameter values of previous ones. You can learn more about this useful technique here.

Notice that if we could remove the parentheses, the implementation would be almost the same as Haskell's!

Why partial application is interesting?

It is a nice way to inject context or dependencies into functions without wrapping them in classes, and they're an awesome tool combined with iterators or to build callbacks:

let dbWrite: (dbConnection: DBConnection) => (data: string) => bool =
  (dbConnection) => (data) => ...

let productionDBWrite = dbWrite(productionDBConnection)

request.data.map(productionDBWrite)

BUT... you probably want to use `bind` instead!

As I said at the beginning of the article, I wrote it just for fun, I love to find how languages like Haskell inspire features and new ways of thinking in other more trendy languages.

In JavaScript you can use Function.prototype.bind() to achieve similar results:

function cat(a: string, b: string): string {
  return a + ' ' + b
}

let catHello = cat.bind(null, "Hello") 
// Take into account that the first parameter defines 
// where "this" points to in the bound function. It's 
// important to remember this if you're building a 
// bound function from a class method. As we don't 
// reference `this` in our function, it's fine to just 
// pass `null` here.

console.log(catHello('World'))
=> "Hello World"

We use this technique extensively in Booster Framework to reduce code complexity. Feel free to join our community and practice some hardcore TypeScript techniques there, contributions from any skill level are highly appreciated, there's nothing like learning together!

Become a better software engineer by opening yourself to different viewpoints

Javier Toledo — Sat, 07 Mar 2020 22:29:13 +0000

Originally posted in Linkedin. Photo by Alex on Unsplash

The natural human tendency toward polarization and the lack of reliable scientific data about methodologies, technical procedures, and tools can result in never-ending discussions and poor technical decisions.

If you're a software engineer, you’ve probably found yourself in one of those discussions that drive us all nuts. The debate could be over functional programming versus procedural, shared state versus stateless, tabs vs spaces, or whether you're doing TDD, or Scrum, or doing “the right way.™”

We all love passionate discussions about technology, and it's easy to argue in favor or against any of those topics with pros and cons. But the way we weight our arguments is rarely based on evidence—it’s often purely based on our own personal experiences or marvelous tales told by people or brands that we admire (“It was invented to solve the huge challenges in Facebook, so it should work for us too!” – we all said a few months before it ruined the entire web.)

Our opinions are very often not based on science. Nobody has run a serious study to measure how much a solid Haskell type system reduces the bug count compared to the lousy dynamic nature of Ruby (Disclaimer: I love both of those languages—this was just an example!), but we still love to argue about it anyway. Our opinions on those matters come basically from confirmation bias, the inherent tendency of all humans to interpret information in a way that strengthens their own convictions. This means that what you believe is likely influenced strongly by who your mentors were, what books you have read, and who you talk about tech with.

To make things worse, most of us usually hang out with groups that think alike, reinforcing our thoughts even more and making us tend to look for radical silver-bullet ideas: “If you don't do TDD correctly, you're not a developer”; “If you don't follow every point in scrum, you're not professional”; “If you still use classes, you're a dinosaur”; “We ALWAYS do this, so NEVER do it differently.”

The rate of “nevers” and “always” in a conversation about code could work as a perfect indicator of upcoming bad decisions.

This tendency is a well-studied social psychology phenomenon called group polarization, and, guess what: it's not doing anyone any favors. It makes us use the same tools or procedures for every situation, even when they are not applicable or it’s not the most practical approach. Being polarized and having extreme views on any topic in programming makes you a worse engineer, not a better one, but tragically, extremism is often confused with wisdom.

The Wikipedia page on software engineering reads /"Software engineering is the systematic application of engineering approaches to the development of software." The engineering page defines engineering as "the use of scientific principles to design and build machines, structures, and other items..."

So, where's the science in our day-to-day decisions? Are we really making decisions based on evidence, or is it just a mix of personal choices reinforced by the people around us?

The truth is that nothing is black or white in programming because programming is complex and we’re all learning as we go. Most approaches, techniques, and technologies were created to solve a specific problem, or try to solve it in a better way. Take a look at any specific tool, and you’ll find that it was created to be the perfect tool to solve a particular problem under a particular set of conditions. Otherwise it wouldn't exist! But we cannot drive our decisions based on what we like or what we hate. We have to fight our natural biases and understand the real pros and cons of the tools and methodologies we use, especially the context (budget, team knowledge, disposability of the software, etc.), if we want to keep evolving as programmers.

Hate or rejection never helped anyone: they’re usually just an indicator of what you don’t understand. Trying something that you don't like very much tends to make it slightly more appealing and broaden your perspective, and even though you may never decide to use it in a real project, you might come to understand in which situations that language or methodology could actually be the right choice. It's OK to have favorites, but to really develop yourself, you have to stop hating and do your best, even when you're not in your comfort zone. Learn a new language, try to change something in your processes, listen to people you used to ignore (or vilify) and try to put yourself in their shoes — I can assure you that you will become better at what you do!

So, let’s keep discussing, even arguing about technology — that’s fine! There's definitely a certain amount of team bonding involved in slamming that brand we all love to hate, call it JavaScript, PHP, Monoliths or anything else, but the next time you’re arguing with a colleague around making a decision, don’t let the hate or rejection make it for you: try putting yourself in your colleague’s shoes and understand why they believe what they’re saying. Do the exercise of inverting the discourse, making yourself come up with a list of pros in addition to just cons. That could help you reach middle ground and find alternatives that you’d never thought about. That’s how you become a better software engineer, enriching your opinions with diverse ways of thinking.