Whether you are coding software or managing a company that creates software, the name of the game is optimization: there’s always a better way to do things, a wrinkle to iron out, a bump to flatten quickly. However, even if we somehow reach a perfect process, it will probably not last long. Technology is always moving forward.
Then why is it often difficult to adjust your development practices to ensure you always obtain a better outcome? Why is it so hard to leave behind “tried and true” methods of development to try new ideas to better the efficiency of any process?
It’s not surprising to find out that the root of a lot of these issues lay within human psychology, specifically a phenomenon that can help us understand how we conceive our practices, and the sooner we can work towards mastering how it works, the better our outcomes will become: cognitive inertia.
The human side of change.
“Cognitive inertia” is a term gaining popularity in software development, and with a good reason: it aptly describes why it might be so hard to change approaches to development, even in the face of an evident need of trying something else:
“Changing management is an age-old problem; migrating to a new process with new technologies can represent a big change. The management teams are met with cognitive inertia and a long list of reasons why new methods and technologies will not work. So, instead, they work harder, and the harder they work, the farther behind they get”, points out Barry Hutt, CRO at Viviota Software, in his post “Cognitive Inertia a great challenge to innovation.”
It’s a paradoxical outcome, but to begin to understand this issue, we should define clearly what “cognitive inertia” is. Cognitive inertia is not “belief perseverance”, or the phenomenon of maintaining the same belief even when presented with new information. Instead, cognitive inertia is the inability to change how a person processes information, which is a much more complicated framework that involves motivation, emotion, and developmental factors.
Its consequences can be seen easily in software development when we think of practices like testing or brainstorming, which makes the old adage “work smarter, not harder” a difficult one to implement, especially as a project or an organization grows in complexity.
“Cognitive inertia evolved because the brain optimizes energy efficiency. If you keep the same behavior and don’t question it, your brain conserves space and can make faster, simpler decisions. On a social level, maintaining consistent behavior preserves social cohesion by maintaining social roles and responses”, explains the blog “Cognitive Inertia: The Status Quo Bias” by Joseph Adebisi.
However, it’s obvious why in a field like software development this can bring problems in the long run. After all, even if roles in a development team are clearly defined, the multitude of solutions that need to be reached at every step of the process (from the ultimate goal of the client to fixing the smallest of bugs) benefit from the creativity that surges from having multiple approaches.
The key to collaboration
The approach of Scio to this issue, both internally and in the work, we do with our clients, is knowing that a “solution” is more than having the seemingly right answer for everything; it is developing a process that lets you question and rework the methods you used to arrive at to fine-tune the outcome.
“When you build walls, it’s easy to keep piling bricks on, one after another, in every house you build. That might work for a while, but if now you are looking to build something with a different purpose, like a cathedral or a hospital, will that approach still be the best?” comments Luis Aburto, CEO, and Co-Founder of Scio. “What happens when you partner with someone that comes and says ‘hey, maybe this bricklaying will not support the multiple stories we need for a hospital, so what if we try this instead?’”
A culture of constant sharing through collaboration, then, might be a way to avoid the pitfalls of cognitive inertia. After all, cognitive inertia, as real inertia does, keeps the same trajectory if nothing initiates a change, so the more different perspectives you have, the stronger the final product may be.
“Human beings love to help. Doing it productively and seeing people overcome obstacles it’s a very rewarding experience, and at a company like Scio, where collaboration is a key part of us, you also get the benefit of cross-pollinating different parts of your organization”, says Yamila Solari, Co-Founder and Coaching Leader at Scio. “If you create a culture of mutual help and support, where one person talks to another and so on, your culture is always enriching itself.”
This makes coaching one of the best tools Scio has to keep our organization moving forward, making sure that knowledge gets shared around between collaborators to strengthen the outcomes of every person and every team. This circles back to our earlier article about outputs and outcomes in software development, where we try to understand the purpose and goals of any project we collaborate with before deciding on the approach that will work best for that specific job. Sometimes laying bricks in the usual way will be enough, but that doesn’t mean that developers shouldn’t have an open mind to try new things if they hit a snag during development.
Cognitive inertia in the day-to-day
However, one should not assume that the issue of cognitive inertia only affects an organization at the macro level, or that it is always a bad thing; it’s part of our daily work whether we notice it or not. For example: if you are focused on a task, and an interruption comes (be it a software update, an Internet outage, an unforeseen meeting, or even a coworker just stopping by to ask something), how difficult is it for you to resume your rhythm at full speed?
Martin Cracauer, CTO of the software development firm Third Law, holds the opinion that the way our brain absorbs information and uses it in the short term is a form of cognitive inertia, and keeping information properly compartmentalized is a way to ensure a task, or a whole project, doesn’t get derailed:
“A lunch break absorbing lots of information that has nothing to do with your work task is relaxing because it does not compete with the work task memory. But a work meeting that touches actual work stuff competes for the same cognitive machinery. […] Your Company makes its money on the programming tasks that are completed today, so you just traded away the brain state needed for Today’s Task in favor of some imaginary later benefit.”
What this means is that some form of cognitive inertia (the one that puts a developer “in the zone” when writing code) can be used to the advantage of the development cycle if we structure the project with clear goals and purposes that need minimal interruptions, and let the developer to fully focus in the day to day progress.
The Agile methodologies, when well implemented, help with this as it lets organizations like Scio maintain a high level of cohesion in the development cycle that doesn’t give enough space for distractions. A well-managed team knows its goals, the potential pitfalls, and biases that can surge in development, and has the support to focus on the tasks that actually get things done, letting the outcome dictate everything else the product might need.
Cognitive inertia, then, is not inherently a good or bad thing in software development; a well-balanced organization can manage, and even use it to its advantage. After all, the software is not about working harder, it’s about implementing the smartest approach and letting the results speak for themselves.
The Key Takeaways:
Cognitive inertia is not stubbornness, it’s the way some people get used to processing information in their day today.
Changing this inertia can be difficult, but is not an insurmountable problem, and it’s a critical need for software development.
Collaboration and tools like coaching can be effective in mitigating the effects of cognitive inertia, feeding constant new information to avoid settling on a single approach.
However, cognitive inertia is not all bad; it helps a developer to focus as long as interruptions and problems derived from sudden changes of course are avoided.
It all comes down to good management. Being aware of bias and cognitive traps, constantly encouraging new knowledge between collaborators, coaching and a good implementation of Agile methodologies can result in a healthy development environment that guarantees a good outcome.
There aren’t many professions without a stereotype attached, and programming is sure among them. But are these ideas about the personality of programmers accurate, or are we missing something else? Let’s look into these old myths, and see if they hold up.
By Scio Team
When we think about programming and software, we tend to conjure a specific image in our minds, a stereotype that has accompanied the profession almost since the beginning: the image of a coder hacking away at the keyboard, immersed in a world of their own, without the need of much company.
However, if this was true at some point, it still is? The stereotype of the introverted programmer is an even mix of fact and myth, and here at Scio, where we know perfectly the talent we work with, we want to shed some light on the reality of people applying a special skill to create software.
Is it possible to profile a personality?
Since the days of the classic “Temperament Theory”, which tried to divide people into 4 distinct types (namely: Sanguine, Choleric, Melancholic, and Phlegmatic, which are pretty weird classifications if we are being honest), people had the impulse to try and understand their personalities, where they come from and how they affect their everyday lives.
More scientific approaches to these questions have evolved from the 20th century onwards, and today we understand that personality, affinities, and preferences are more fluid and flexible than we once thought, even if we simplify the whole idea for the sake of practicality.
The Myers-Briggs Type Indicator nowadays is one of the most popular systems to tackle this subject, going more in-depth on the inner workings of a person instead of just focusing on their outward behavior.
Going back to the idea of programmers as introverts, things like the MBTI bring some very interesting insights about this professional field and the people who feel compelled to it. What can we find there?
Let’s define “introversion”
What you need to know right now, is that the “introvert/extrovert” dichotomy is a little outdated, simplifying a vast swath of personality types into two neat boxes with little in-between. What the definition of “introversion” tries to convey under this understanding, is people who don’t have much affinity for a specific kind of social interactions, prefer more individual activities, or with a pretty select group of people.
Although many probably feel this way, reducing it to only these signifiers leaves a lot out. What the Myer-Briggs does is check the balance between the following:
Extraversion (E) versus introversion (I)
Sensing (S) versus intuition (N)
Thinking (T) versus feeling (F)
Judging (J) versus perceiving (P)
What this system maps out is the preference of the person, rather than the ability, so the metrics here assign percentages based on what a person would prefer to do in a given situation, ending up with a combination of 4 letters based on their highest percentages, like INTP or ESTJ. Please take note of the use of the word “extraversion” instead of “extroversion”, which will be important in a minute.
There are pros and cons to this approach, but the important part here is that we have a lot of historical data to see what large swathes of the population prefer, and in programming, the results are pretty interesting overall, challenging many of our notions about the “introvert coder” stereotype.
So… are programmers introverted or not?
We are getting there. First of all, since we are looking into preference instead of abilities, it’s important to note that certain groups, as a whole, will pick one instead of the other; it’s a decision (even if a subconscious one) instead of instinct, or impulse. For programmers, this preference goes towards Thinking (T) instead of Feeling (F), meaning that they like to analyze situations from a more objective point of view, not giving as much consideration to the emotional side of things
Now, this doesn’t mean they only do one of these things. It means that when compelled to act, people will feel more comfortable with a single approach, so if we look at coding, programming, or engineering (where you see lots of interconnected mechanisms balanced between “needs” and “wants”) people prefer Thinking (T) will be better at it. This post, titled “Does being an introvert make you a better coder?” puts it nicely:
“A typical software developer likes there to be a logical consistency behind a decision. It might not matter much what that consistency is, so long as it’s there. By contrast, other people prefer the ‘feel’ of the situation, using empathy and imagining what it is like more from other people’s point of view. In other words, there is a difference between coders and others, in how they tend to justify a decision.”
And as you can see, this has nothing to do with social preferences, or the ability to relate to people in any situation. That’s why this profiling system uses the word “extraversion”, referring to “the world of action, people, and things”, in contrast with “introversion”, or the world of ideas and reflection, both useful for doing complex things such as programming software.
“MBTI introverts prefer fewer, deeper, and more involved interactions with people, whereas extraverts prefer shorter and more frequent interaction. For getting to know users quickly, extraversion can be an advantage, but introverts are perfectly good at deep social interaction”, goes the cited blog. And it’s true; avoiding people has little to do with introversion, and the stereotype comes from misunderstanding what these words try to convey.
An alternative definition of the “introverted programmer”
So, to wrap things up, where does this leave the myth? As we said, maybe at some point in the past, before the development of agile methodologies or the normalization of a remote model of working, the stereotype of the “introverted programmer” was true and functional, but it no longer works that way.
People are more complicated than many of these systems will tell you, and lots of different preferences and abilities are desirable in any well-balanced team. What is true in the age of remote work, though, is that knowing how to interact and communicate well with your coworkers, clients, and managers at a distance are going to be a very valuable skill moving forward, and this has nothing to do with how one approaches the challenges of programming.
So we can leave behind all that and start thinking of the people best adapted to the work of programming in a different way; is no longer an introverted programmer, but a thinking one, whose intuition and affinity for code can be supplemented in a great way by social understanding and the clear communication that only the best Nearshore companies can offer.
We know the winter holidays are for kicking back, getting closer to your favorite people, and reflecting on everything that has happened in the last 12 months. And, if you are hunting for a new job, it’s also a seemingly perfect moment to look for an opportunity and give your career the change it needs.
However, is December truly the best month to start sending resumes? We at Scio know all about talent and opportunities, so let continue this month’s celebrations by dispelling some myths that might hinder, instead of advance, your career.
December is the best month to find a job.
This is a common piece of advice, but one that needs to be taken with a few caveats. After all, the winter holidays are some of the busiest days of the year, and the administration and HR departments of every company in the world are going to be overwhelmed by the usual Christmas stress: giving out bonuses, preparing budgets, closing projects with clients, scheduling times off, etc.
Never mind that many people making hiring decisions will be taking vacations, and generally, things get slower as Christmas approaches.
Now, it’s true that a lot of positions may open during these days (see our next point about that…), but it also means that it’s more likely that your application will get lost in the shuffle. So what to do?
Take it easy. What December can bring you is enough free time to prepare your resume, customize it to your needs, curate the projects you did all year, and start building a company “hit list” to start looking for that perfect job.
January is the best time to send resumes, because most of the year’s new projects will start, and there’s a lot of things needing to be picked up after the December slump. So hit the ground running by taking the proper time to prepare for these holidays.
Lots of openings mean lots of opportunities.
Yes, but it depends on how you define “opportunity”. As we mentioned, December is a popular month to leave jobs, as the New Year serves as motivation to try new things, and the Christmas bonuses give people enough confidence to leave.
And when that happens, it inevitably means a lot of work will go undone unless HR departments and project managers do something about it, which sometimes involves offering temporary positions just to get things done.
Now, entering into a company, even with a temporary job, is not bad at all: gets your foot in the door, gives them the chance to know you and consider you for a full-time position, or at least can serve you to hone some skills that can be useful elsewhere.
However, if you plan to change careers or try to find a better job, these kinds of openings might not offer you what you are looking for.
Study the openings to understand what skills the company needs, as these “emergency” positions will be very clear and to the point about what they want. In software terms, you might find specific methods, frameworks, or languages the company usually employs, and you will have the chance to become familiar with them before applying.
Get an early advantage by the time January starts!
Finding a job isn’t all about the timing
It’s more about persistence. Our earlier points might paint December a “dead” moment to look for a job, but far from it. It’s about building momentum in your applications, honing your resume, practicing interviews, and looking at what you’ve been doing right and wrong.
Don’t stop, it will be harder to pick up your pace again in January (when it might count) if you stop during December, and the perfect opportunity might come at any moment, even during Christmas.
Remember, these holidays are ideal to celebrate everything you accomplished, learned, and mastered during the year. Use it to your full advantage, keep aiming higher, and never get discouraged.
Who knows, maybe you are someone that Scio doesn’t know they need yet!