The Vanity Trap

By Alvin Tsui

•Does your team or organization struggle to retain good talent?
•Do you often feel stressed by your leadership, management, or coaching responsibilities?
•Do you feel pressured to cut corners to meet deadlines?

...or do you just want to be the best leader you can be?

The Vanity Trap examines the consequences of society’s increasing distractions with present superficialities at the expense of substance. Drawing lessons from 10+ years of software development experience, Alvin Tsui explores common pitfalls that emerge from our superficial obsessions, and how the most successful leaders avoid them. Learn how the best leaders, mentors, and coaches elevate themselves, and others, to greatness. Along the way, learn how software is made, how software works, and what software is.

This book is for you if you're a leader who wants to be the best you can be and empower those around you to be their best as well.

By the end of this book, you’ll know how to make smarter, conscious decisions with technologies to live a healthier, successful life.

• Language: English
• Publisher: Alvin Tsui
• Release date: Mar 1, 2022
• ISBN: 9781005559908

Alvin Tsui

Alvin Tsui is a software developer specializing in backend development. He has 10+ years of wide-ranging professional experiences: from solo projects to teams with dozens of specialists, from serving local mom-and-pop shops to organizations that serve the globe, from the worst management styles to the best. He built web pages, databases, and large-scale backend systems that process billions of data points every day from around the world. His contributions span the retail, telecommunications, banking, and health care industries. Unlike most software developers, Alvin enjoys exploring the human side of technology, and technology’s broader implications on society.

Book preview

Preface

On October 29, 2018, an aircraft carrying 189 passengers plunges into the Java Sea shortly after takeoff from Jakarta, Indonesia. There were no survivors. [1, p. 14] Just four months later, an aircraft departs Addis Ababa, Ethiopia. Less than ten minutes after takeoff, the aircraft nose-dives into the ground claiming all 157 lives on board. [2, pp. 9–12] Both accidents involved Boeing's newest aircraft, the Boeing 737 MAX 8, along with a new software component that would gain public notoriety: The Maneuvering Characteristics Augmentation System (MCAS). [3, p. 1] Boeing failed to anticipate pilot responses to the MCAS in concert with multiple alerts emitted by other software systems. [3, p. 7] Moreover, internal messages among engineers at Boeing revealed a corporate culture that was insipid [4]; yet, common in organizational cultures. Anyone who has spent enough time in a corporate environment can recognize the gripes in those exchanges. Now, almost every corporation has an Information Technology (IT) department, and many are armed with software developers.

Software developers are not immune to corporate ills. They’re human. But a poor environment can compound a weak mindset, which can bring down any creator. This book explores a specific weak mindset I call: The Vanity Trap. It’s an obsessive focus on present superficialities at the expense of substance. It keeps you from success.

This is not about egotism or narcissism. Excessive focus on one’s appearance or ego are not the only precursors to the Vanity Trap. All that’s needed is a willingness to trade-off substance for current appearance. It’s insidious because an individual trade-off may not cost much. The negative effects accumulate with each subsequent trade-off. Adverse effects also amplify when trading away substances of greater foundational importance, as you will see later.

No one is immune to the Vanity Trap. Some are unaware of it. Some are aware of it but pay it no mind. Some are aware of it and exploit it at your expense. The first part of this book explores its causes so you can recognize, and know how to skirt, the trap. You’ll learn how the Vanity Trap affects you and those around you to keep you down. You’ll also learn how the Vanity Trap shapes group culture to keep you trapped, so you can learn how to escape.

The following short story exemplifies and encapsulates the Vanity Trap. The fuller, and broader, implications will become clearer as you read the book, so we will revisit this story later.

~~~

The Chair Maker

There was once a chair maker with a wagon in tow who stopped by a village to proffer his services.

"I shall craft the most majestic chair for anyone willing to trade. Don’t pass on this rare opportunity, for I shall depart soon."

"But you have not a chair in sight," remarks a villager.

The chair maker opens a display case. Fear not. Kings and queens from around the world bestowed upon me medals affirming my prowess.

Impressed by his accolades, the villager requests a chair. A few days later, the chair maker presents the completed chair in exchange for goods, and promptly departs the village.

The chair appeared impressive, indeed. The rails, splats, and stiles were patterned with intricacies the villager never saw before. Moments after sitting on the chair; however, it collapsed to the ground.

The villager brought the broken chair to a local carpenter. Upon inspecting it, the carpenter noted that the chair maker was frantically looking for wood the other day. The chair maker asked if he could take the scraps the carpenter discarded to fashion the legs of the chair. The carpenter warned that the scraps were worn, but the chair maker was desperate. The chair maker insisted that he had not the time to obtain the materials, for he had to continue his journey soon. The carpenter concluded that the chair was designed to appear sturdy. On closer inspection, the legs were too weak. The structure was frail, so the chair collapsed.

The villager and carpenter decided to pursue the chair maker with hopes he didn’t go far.

Indeed, he did not. The duo confronted the chair maker at the village’s perimeter. He used the same wood scraps to patch his wagon. The patches snapped, immobilizing the wagon, stranding the chair maker.

~~~~~

On the plus side, I also know developers who found success, becoming leaders in the field. They all share common attitudes and traits that, collectively, constitute a power mindset driven by heart and substance. In the latter part of this book, you will see what a successful, power mindset looks like.

But what about technical skills, experience, tools, and techniques? Don’t they affect success? Of course, they do. The internet is abundant with suggestions on programming languages, frameworks, and other software technologies that you ought to learn to begin programming but lacks guidance on mindset. You can have the fanciest tools in the world, but without the right mindset, you won’t wield them effectively. For instance, you can be skilled in a programming language, but excessive distrust will limit your success in software development, as you will see later. Your favourite integrated development environment, programming language, and RGB keyboard will not lead you to success if you have a weak attitude. On the contrary, I will share with you the attitudes and mindsets that successful creators possess using examples from software development, and life. They are attitudes and mindsets that enable you to be your best.

We are each responsible for our own attitudes and mindsets but suggesting that our environments don’t have any impact on our mindsets would be disingenuous. A weak mindset is reinforced in an environment in which you’re surrounded by others with weak mindsets. As we will explore later, you must, first, adopt heart and substance to inspire others to do the same and, thus, improve the culture around you.

Note, also, that in the field of software development, cultures don’t just vary from one company to another, but also from one software development team to another, even if they’re in the same organization. A team’s culture is affected by the culture of the organization to which it belongs, but is even more influenced by its direct manager(s), leader(s), and team members; hence, the expression:

People don’t leave bad jobs or companies; they leave bad bosses.

This book will not:

Reference any specific organization. Work processes are similar from one organization to another because most organizations in IT like to follow the same, latest trends, especially if they originate from Silicon Valley.

Reference cultures unique to start-ups, FAANG, or game development.

Reference any specific individual. All names were changed to preserve privacy. The purpose of the examples in this book is to exemplify commonly observed behaviours and impacts thereof.

First Things First

Software development.

Since the main context of this book pertains to software development, let’s start by clarifying what it is. This activity has many different names, and there will likely be new variations in the future. They are names that some use interchangeably, but there are nuances in the way its name changes as the activity, itself, evolves over time.

Coding is the skill of translating a logical process into a language that the computer can interpret. Code is codified logic. Nowadays, coding is to making software, as basic arithmetic is to calculus. Of course, the analogy's imperfect. Technically, you do not have to learn how to code before learning how to make software.

Programming involves using code to tell a computer what to do, and oftentimes, how to do what needs to be done. Each set of instructions is what we now call, a program, application, software, etc.

Software development is a term that introduces a new mindset. Over time, software became larger and more complex. Now it's important to consider how those instructions, and how the process of making software, can be more efficient. Software development is much like product development. Why? A piece of software is now seen as product to be delivered to customers and users; hence, additional considerations such as, how to package, deliver, maintain, and retire the software as a product (or service).

Software engineering takes software development a step further. Engineering is, fundamentally, the practice of using technology to solve problems. Software engineering is, therefore, the practice of using software to solve problems, more than merely delivering a product. Additional considerations are required, such as, how the solution will fit with other solutions as part of a larger system, so everything works together efficiently and effectively.

I prefer the term, software development, although I mean software engineering in the sense I defined above. So, I will refer to those engaging in the practice as, software developers, developers, or just, devs.

Likewise, for simplicity, when I refer to managers, I am, generally, referring to any individual positioned higher than the developer in an organizational hierarchy. That may, for instance, include senior managers, directors, and executives, among others. Even if they do not directly oversee development work, they still offer input that has material impact on the development process, and by extension, culture.

The notion that developers code all day, 100% of the time (a.k.a. code monkeys) is an unfortunate misconception persisted by those who peddle coding as a panacea. Code monkeys still exist, but they are uncommon, and dwindling. Solving problems as a team is far more valuable than mere typing.

It’s a creative endeavour.

Is it perfect yet?

Software development is a creative endeavor. No software application will ever be perfect just as no work of art will ever be perfect. Nevertheless, many developers with whom I worked in the last decade across multiple industries care deeply about the finished product. After all, we spend at least 40 hours a week pouring our blood, sweat, and tears into it, and overtime is commonplace. What was the last thing you made that took hundreds of painstaking hours? I bet you wanted to do your best too.

Regardless, those who don't care, don't survive. The enthusiastic devote time outside office hours to upgrade skills and learn new technologies. It’s the reason for the lightning advancement of software technologies. It contributes to product improvements as well as improvements to the processes of making and delivering them. Those who can’t keep up, don’t stay.

It’s multi-layered from bottom to top.

The best software developers strive to make the best quality software, but what does best mean? The best software should be so simple and easy to use that it evokes little conscious thought; hence, the KISS principle, Keep It Simple, Stupid. Google, for instance, became a verb because of its simplicity as a search engine. Simplicity is not confined to the software, as a whole; however.

Software applications are multi-layered. On one level, is code. Code interacts with other code, giving rise to components. Components interact to form software systems.¹ Emergence is a concept in Systems Theory, which posits that entities bearing specific properties collectively interact to form a new entity on a higher level with its own unique properties not observed on the lower level. Sodium and chlorine ions interact to form sodium chloride (i.e., salt), which does not exhibit the properties of its constituent parts. Cell organelles form cells, which form organs, which form human bodies. Yet, each layer or level exhibits its own characteristics. Code, components, and software systems, each have unique properties. All layers must be kept simple in their own ways to form quality software.

It's multi-layered from back to front.

Software applications aren’t merely multi-layered from bottom to top like mille-feuille or lasagne. They are also layered from back to front.

The backend typically consists of data storage (e.g., databases).

The frontend is what you see on the screen through which most people interact with software.

The middleware processes and moves data among components.

Diligent developers always consider all layers. The code must be elegant, but so too, must the components, as well as the system. The frontend must be beautiful, as with the middleware, backend, and software, in its entirety.

It's elegant when done properly.

Perhaps you noticed that elegance, beauty, and good quality, are immeasurable. As such, software developers, generally, agree that good software must possess the following traits:

Functional - It must do the job it was meant to do.

Performant - It cannot be too slow.

Flexible - It must be adaptable to changes. The only constant is change, and software is no exception.

Secure - It cannot be used by malicious actors to cause harm to other users.

Usable - It can be used with relative ease.

Reliable - It behaves consistently with each use. For example, whenever we add 2 + 2 on a calculator, we ought to always expect: 4, as the result.

Maintainable - It must allow support personnel to perform routine and non-routine maintenance on the software easily; if necessary.

This list is not exhaustive but offers an idea of what constitutes elegant, beautiful, and good quality software.

Why, then, despite prevalent passion are there still so many issues that plague software? What stops developers from producing quality software? Let's begin exploring this profession with the interview.

Part 1: From the Bottom

Mindless Adoption

In the 2001 film, Spirited Away, a girl and her parents stumble upon an empty street full of food stalls. Her parents gorge on the food and turn into pigs. Our current technological landscape is similar. New (digital) technologies emerge every year, and swarms of people enthusiastically embrace them without a second thought. Magical food from Spirited Away; notwithstanding, mindless consumption leads to poor health. Mindless adoption, and consumption, of technology is no different. Every technology has its pros, cons, benefits, and costs. Yet, contemporary society is so inundated with advertisements (driven mostly by technology, itself) that focus is almost exclusive to benefits. The true cost of a technology is an afterthought. By the time society is ready to settle down to reflect, a new technology arrives to distract. Taking the time to reflect on the pros and cons of technology is necessary to have a healthy relationship with it. So, let’s take some time, now, to see how the mindless adoption of technology, and ideas affects you.

Choose the best tool…

There is a cutting board in front of you. On the cutting board, is a raw carrot. You need to slice the carrot, and you have but three utensils: a spoon, a blunt knife, and a sharp knife. Which one do you use? The sharp knife; obviously. While the spoon can be used to slice the carrot, you will exert more effort because it is not designed to slice a hard object. The blunt knife is the right type of utensil as it's designed for slicing but is poorly calibrated. You will exert more force than necessary, increasing the odds of injury. Nevertheless, lesser tools are routinely employed in software development. Why? Cost is one reason. Some decision makers do not feel the costs of the best tool justify its benefits. Furthermore, a tool is, often, adopted because it's trendy. If other organizations are using the tool, it must be good...or is it?

But beware of charlatans…

It is said that when all you have is a hammer, everything looks like a nail. Software developers are not immune to this mentality, nor are their managers or other IT personnel. Technologists happen upon new, proverbial hammers by keeping up with latest industry trends via periodicals, conferences, workshops, and other knowledge sharing sessions. Managers do as well, but they are also more likely to be targeted by sly salespeople, and cunning consultants. There is an entire industry of IT consultants with ideas to cut software development costs for any company with an IT department.

These ideas are not necessarily successful in all (or even, most) companies to which they are introduced, but they sell. Crafty consultants will tell you that many others are using the same product, so it must be good, right? Not necessarily. They’ll describe some success stories, which are likely true, but exclude failures to exploit survivorship bias. Consider, though, that if there were only five success stories and 95 failures, then the success rate is a dismal 5%. Would you trust a product that only worked 5% of the time? Additionally, an idea can work for the largest companies in the world and fail for you. Things work differently at different scales, (which will be discussed later in the book; see: Error: Reference source not found). Also, domain-specific expertise does not, automatically, translate to other domains. A genius baker is not necessarily a genius, in general, or in any other domain.

When ideas don’t work, or when they don’t work as well as advertised, then the software development process is hampered. Software quality suffers. Users suffer.

In pursuit of the latest trends…

Enter the job interview. It’s widely known to be unreliable because it constructs a simplified representation of a candidate. Simplifications are inherently incomplete, and error prone. A map is not the territory.

It's 2021. Landing a job as a software developer often requires completing a coding interview in addition to a traditional behavioural interview, and one or more technical interviews as follow-ups. Superficially, that sounds reasonable. After all, every qualified developer must know how to code. However, coding interview, is a bit of a misnomer. Yes, coding occurs during these interviews, but the focus is on the candidate's ability to solve a complex problem with an algorithm that often has little to no relevance to the job². It’s a cause of consternation among developers as one of many tools often mindlessly adopted by tech teams.

For one, there are teams that adopt the contemporary coding interview as a fashion trend fueled by social proof. IT companies around the world look towards Silicon Valley for the latest gimmick in information technology, including hiring practices. This is not the first interview fad that emerged from the Valley. In fact, in the early 2010s, books were published to help readers clear the brainteaser interview. Those interviews featured puzzles that had even less to do with being a software developer, including questions like, how many golf balls can fit in a Boeing 747? Companies that believed in the effectiveness of those puzzles in filtering candidates thoughtlessly employed the same tactics. I know from personal experience that management consulting firms had the same love affair. Ultimately, the fad passed after people realized its fraudulence. The world, then, moved on to other questionable techniques...with Silicon Valley leading the way. Now we have the coding interview, and an industry of preparatory courses to help candidates pass it – like shovel sellers in a gold rush.

Imagine a store hiring cashiers. An applicant named,