Ten Professional Hazards Of Writing Code For A Living

Human beings are creatures of habit. Any profession which entails long sustained periods of doing things or thinking a certain way, will have an influence on its practitioners. Years of being a programmer have changed me. In all fairness, some of these traits already existed way before I wrote my first Hello World program, though they were certainly magnified after that.

Here are some of the ways my job as a software developer have shaped me as a person. Some of these may make me look like an utter moron. I assure you that I am of at least average intelligence. It's just the job.

1. Counting from zero

Probably the most stereotypical quirk ever. "Programmers tend to count from zero". Yeah, right. The stereotype exists because in almost all programming languages, counting does begin from zero.

Do I count from zero? No, that's silly. I don't, for instance, look at a cluster of five apples and tell you there are four. Any programmers who do, I suspect, are just trying too hard for geek cred.

There are five apples, not four.

However, it does happen if I'm looking at rows of data. If I see an MS Excel worksheet with data all the way to number 100, I am going to think there are 101 rows of data. It could be because spreadsheets are usually the way I visualize arrays in my head (especially two-dimensional arrays) so my brain subconsciously thinks of spreadsheets as arrays.

Thus, while this stereotype is way overblown, there's some truth to it.

2. Being easily startled

When deep in the throes of writing code, programmers tend to concentrate really hard. I am no exception. There have been plenty of times when my brain is on a one-track highway through some programming logic when someone interrupts me by speaking in my ear or tapping me on the shoulder.

Violently startled.

And sometimes, my reaction can be... absurdly violent. Spilled coffee, sudden jumps, things like that.

This doesn't happen all that much these days. For one, I work from home. Very few people get to interrupt me. And even if they do, the fact is, I simply don't concentrate as hard as I used to.

3. Being very literal

One of the hallmarks of writing code is being drawn into the true or false dichotomy. Thus, there's this tendency to interpret everything as a "yes" or "no" question. To be fair, sometimes the question is literally phrased this way. But that's only as a manner of speaking; often, the asker means to ask a bigger question.

No capacity for nuance.

And because of this tendency, I tend to miss it.

I remember being at an interview where the hiring manager asked me if I knew how the PayPal IPN works. To me, the answer was obvious. Yes, I do. It was only after an awkward pause, and the interviewer rephrased his question, that I understood that he actually expected me to demonstrate how it works.

There were other interviews where I was asked similar questions where I simply said "Yes" or "No". But honestly, I also feel that if you're going to ask a programmer questions like that, you should also be prepared for replies like that.

4. Single-mindedness

This next one does not apply to all techs or even all programmers. But there's a fair number of programmers who tend to take a very insular view when writing code. This can be useful when you're writing a single-use method; as small as possible. Not so much if you're trying to design an entire system.

Laser focus... or just
tunnel vision.

And in real life, that can have negative consequences too. I've gotten into trouble with the wife for doing the correct thing... at the wrong time, or under the wrong conditions. Because the correct thing, in isolation, is the correct thing. But few things in life exist in isolation.

You don't want to wash the windows when it's raining. Or flush the toilet before taking a piss. All this is putting the cart before the horse, which can happen when you consider only the task at hand and fail to take the larger context into account.

5. Overusing techspeak

Tech work comes with a whole lot of terminology, some of which we're sometimes guilty of assuming that non-techies understand. After all, techspeak has become increasingly mainstream over the last decade as technology has become more entrenched with the general public.

This does not automatically mean that everyone knows what SSL is (despite a staggering majority of websites employing it). Or that a gateway doesn't always mean that entrance to a building enclosure. Or that when we refer to something as a "string literal", we actually just (kind of) mean "text".

No, not that kind of string.

And yes, I'm just as guilty as other tech geeks.

We're not trying to sound smart when we break out the tech jargon, cross my heart. Mostly because we are smart, and know it. No, it's largely because our work practically demands that we speak in what could almost be a different language.

6. Expecting output

As mentioned before, I tend to interpret things very literally. However, this also applies in reverse.

As a consequence of writing functions which expect very specific data type values in a very specific order, as input, and produce output which is also of a very specific data type, what happens is that this has a tendency to manifest when I ask questions of other people: I tend to expect a certain output and only that output. And when I ask for A, and people give me B, C and D in addition to A, I tend to get annoyed.

A lot of irrelevant information.

It's human nature; people want to be helpful. But what usually ends up happening is that they give you a lot of information that has nothing to do with what you wanted in the first place.

7. Cynical

Expecting the worst, or not believing it when things go well, is something ingrained in developers who do a lot of testing, which, let's face it, is pretty much all devs at this point.

Does your code ever run perfectly the first time? And when it did, were you happy or wary?

Glass is always half-empty.

Unless it's something really simple that would have been expected to go right, sometimes when things go too smoothly, I get worried.

My time running code has taught me that when no warnings or errors are reported, it's rarely because I did everything right, especially if it's the first run. No, there are probably bugs and gotchas, and they're well-hidden!

8. The How 

One more quirk of being a web developer is that one of the first questions we tend to ask is the How question. It's a professional hazard that may be shared by engineers in general.

Even when I'm asking something like "why did I get an error 500 on this API endpoint call?" it usually gets formattered as "how the hell did I get an error 500 on this API endpoint call?"

Examining how things work.

That's relevant, I promise. Because even in my early days as a web developer, I was curious about how things worked. I would find stuff on the web, wonder how it was done, and then I would make my own, just to prove I could. This also applies to other things in my life, non-tech related. I'd look at something, figure out the how, and make my own. I'm not sure if I'm this way because I was a web dev, or I became a web dev because I'm this way.

9. Lack of sympathy

I've been accused of having a less than exemplary bedside manner when people complain about their shitty careers or lack of opportunities in the job market. I've also been less than impressed with people who claim to envy the fact that I work in tech.

Heart of stone.

Really? Do people want to potentially spend days sifting through code, making changes that may end up creating problems bigger than the one they're trying to solve? Would they enjoy having to constantly remind their less tech-savvy colleagues that software development is not witchcraft and still has to conform to logic? Do they want to go through the slog I did, in order to get where I am now?

I know I don't. I simply happen to enjoy writing code enough to not overly mind that rest of the bullshit I have to put up with. People want the perceived better pay and job security of tech, but the job itself would drive them nuts.

And I have no sympathy precisely because I know I'm not better than the average schmuck. In the sense that, the moment I'm of no use, I'll be put out to pasture like anyone else. Look at the mass layoffs happening in Big Tech if you're not convinced. Job security? What a joke, right?

10. Flowcharting

Agile practices include making use of a Kanban Board system. The use of said system is good for training an organized mind, and lends into the software development practice of breaking up a huge problem into smaller, more manageable tasks.

The good old
divide-and-conquer.

And this has translated over to my daily life, to things like chores and personal projects. Even long-term goals like language learning. Everything is obsessively broken up into smaller sub-components, then managed.

The wife thinks I'm certifiably insane. She doesn't understand why mopping the kitchen floor and mopping the living room floor are two separate tasks, and have to be scheduled. Honey, I'm just a software dev. It's who I am.

What a hazardous list!

Are you a programmer by trade, and if so, how many of these apply to you?

How many apples do you see?
T___T

Is the written component overrated in professional communication?

Communication is one of the most important parts of the software developer profession. Or indeed, just about any profession. Instructions get passed along, feedback is received and along the chain of events that happen, information mutates. This information may affect what other operations take place, and this in turn has an ever-widening effect on things further down the chain.

So yes, communication is vital. But just speaking of communication alone would be a scope too large for a single blogpot or article. Thus, for today, I would like to speak on something I discovered about verbal and written communication, as a software developer.

Written or verbal?

Written communication is generally preferred because there is a "paper" trail that can be referred to if clarification is required. Verbal communication is considered transient and informal. No corporation, for instance, would consider a verbal exchange a legally-binding contract. No team lead would ever rely solely on verbal communication to convey instructions. The main mode of communication is almost invariably task specifications written in a Kanban card, or even an email.

With written communication, one of the advantages is that people generally are able to carefully consider their words before hitting the Send button (not that everybody does, regrettably). Therefore, the consensus seems to be that written communication is generally clearer.

However...

Is written communication truly clearer than verbal? There are some instances where this is not the case.

Recently there was an incident in the company where I worked. My colleague encountered a problem with the system I was managing. To her credit, she went by the book - sent me screenshots, even a video, and what she thought was a clear explanation of what she had expected as output, and what was wrong with the output she had received.

The problem was with the last part - I understood not a single thing she was saying in her email. Even discounting typos and grammatical errors, I could not get a sense of what she was trying to tell me. After a couple of frustrating exchanges through email, we communicated via a video call. Within minutes of her speaking, the lightbulb went off in my head. Now when I looked back at her emails and her written descriptions, I knew exactly what she was saying.

Hearing words
makes a difference.

Was what she had written in the emails, different from what she had verbally said? Now that I had a chance to do a side-by-side comparison, not so much. The difference was mainly in inflection and tone - both of which were missing in her written emails, and probably in most written media. However, in our local lingo, both inflection and tone convey a multitude of different meanings, and as such they play a huge part in the communication process. Listening to her speak was simply not the same as reading her writing. Probably because she tended to write the way she spoke - another cardinal sin of communication, but one we won't get into today.

In another example...

I had a similar experience on the Clubhouse app. I was in a room where this woman from Trinidad And Tobago in the continent of Africa, was reading from a novel set in that area. I had previously read a bit of the novel, but given up halfway because the dialogue, on the written page, was incomprehensible to me.

However, as I heard her say the words of the dialogue, which was in the Trini slang, using her Trini accent, suddenly it all made perfect sense.

I don't know exactly why that would be the case. I do know that if I were to read the dialogue again, it would be from a position where, having already heard it, I would now know what it meant.

The Communicative Conclusion

Verbal communication can be more powerful than people realize. With audio, one can convey some other dimension in the communication, pieces which may be missing in a written medium. One might argue that being more proficient at written English might solve the problem. It will mitigate the problem, certainly, but it will never replace what verbal communication brings to the table.

Let's have this in writing!
T___T

Using Trello outside of the professional workplace

As Project Management tools go, Trello by Atlassian is probably one of the best-known ones out there. It is used by both tech practitioners as well as business people. Trello is an online version of the Kanban Board popularized by the Japanese. And for the entirety of 2021, I have been using it to manage my non-professional projects; i.e, my personal life.

I will show you how soon, but first things first...

What is a Kanban Board?

This link can probably explain it better, but here goes: the Kanban Board is a visualization that represents the progress of a task, or a series of tasks. These tasks are placed on the board at positions that denote the stage at which the progress of that task has arrived at. For example - Backlog, In Progress, Completed.

A typical Kanban Board.

The tasks are then moved when progress takes place, until the tasks are completed. The overall effect is a visual of where each task is at, at the current time.

Now that this is hopefully clear, let us examine how the use of this tool can be used in the personal life of a tech professional.

What does Trello manage for me?

What I have used Trello to manage all the fun little code projects I work on, the blogposts that make it onto this blog, some crafts projects and learning assignments.

Chores managed by Trello.

Also, I use Trello to schedule my weekend household chores. Dental. Banking appointments. All that mundane stuff.

Breakdowns into sub-tasks

Checklists can be used in each card to break the task down into smaller chunks. When items in the checklist are checked, there is an indication on the card reflecting how much of the task has been completed. This is important because while the overall status of a task remains binary (i.e, completed or not completed), there is a huge difference between 10% of a task having been completed, and, say, 90%.

Checklists

Also, breaking a task down makes it more manageable. I get to tackle bite-sized chunks instead of an entire otherwise gargantuan task. Take for example, a task like "Learn Japanese". Learning an entirely new language is daunting in itself. But if we broke it down into multiple checklists for reading, writing and speaking, with each checklist further broken down into different sub-tasks, it now looks doable. And these tasks are segregated into logical groups, which lets me see which parts of Japanese I am progressing in more - reading, writing or speaking. What I may want to concentrate on more - vocabulary or grammar. It provides significantly more insight into the task than simply "Learn Japanese".

Daily tasks

Daily tasks are a list of things I want to work on or get done on any given day. They could be an existing card on the board that I need to do work on. They could be some entirely new items that needs to be done on that day, like laundry or grocery shopping.

Miscellaneous tasks

In the case of the latter, those tasks take priority because they have to be finished on the day itself. Therefore I would recommend that there is a limited number of these such items on any given day.

In the case of the former, it is a little more nuanced. The objective is not to finish the task, but rather do work on it. So if I do enough work for one or more items on the checklist to be checked off, it counts. How much work I do on that task does not matter; only that I spend time on it. If I spend time on that task but do not actually manage to check off any items, then obviously I did not break down that task thoroughly enough. Therefore, if I follow my own rules, this forces me to at least do one thing on the checklist. If I do this consistently, eventually, the task gets completed. This serves to enforce discipline.

Overall benefits

I've explained how Trello helps in organization of my personal life and all my required tasks. That is an undeniable benefit, especially since I have to break down tasks to fit into the Kanban Board system, and group these sub-tasks logically. This also means that I get real practice using a system like Trello.

Task management.

As mentioned, Trello (or other systems like it) are in use professionally for task management. Being familiar with something like that lends me a professional edge.

Not only does Trello play a role in my professional life as a software developer, it also plays a role in my personal life. In the larger picture, Trello has kept me pretty much on track.

Completed,
T___T

2020 - Three Jobs In a Year (Part 1/3)

2020 was a roller-coaster ride for the entire world, for obvious reasons. COVID-19 made its toxic presence felt, and lives were merrily thrown into disarray. For me, professionally, there was an extra layer of chaos because it was during this year I went through an experience that I had hoped never to repeat from 2011 - going through three different employers in one year.

At the beginning of the year, I was a tech contractor from one of the world's largest tech firms, outsourced to a Government Statutory Board. My finances were healthy, I had learned plenty of new stuff, and once I learned to look past certain things, my colleagues were tolerable. Trouble was, I was bored out of my mind and it was beginning to show. I was goofing off at work, dozing off during meetings and basically not being altogether useful. It didn't help that the project I had been hired to work on was coming to an end, and all I had to look forward to, even if my contract was renewed for a third time, was another year of dreary maintenance work. There was very little in it for me to stay.

Running out of time.

To cut a long story short, I wanted out. It had been good while it lasted, but I really didn't need another year of this.

At that time, COVID-19 had just hit the sunny shores of Singapore and changing jobs was looking increasingly like a terrible idea. On the other hand, it was a now-or-never situation.

Preparing to Leave

Six months before my contract was due for renewal, preparations were well under way. I polished up my resume with all the value-adding stuff that had been accumulating the past few years. I sent forth my job applications like a commander releasing his battleships, and embarked on job interviews.

And that was how I ended up interviewing at the startup that was to be my next job. The interview went well enough, and at the end of it, I did the obligatory online assessment and went for a third round with the CTO, going through some tech scenario. The place was near home, and everything looked promising. If I landed the job, I would have to be comfortable with PHP Laravel. But to be honest, after all these years experimenting and actually working with so many different frameworks, they were all starting to look the same by now.

Life went on after the interview, and there were a few weeks left before the end of the contract with my employer. They offered me a contract renewal, but I needed time to think about it. That night, I got a call. It was from the HR of the startup that I had interviewed at. She was calling to offer me a contract. When she actually sent the PDF over, I didn't hesitate to sign it.

New horizons.

The money wasn't much better than what I was already making as a contractor, and I was fairly confident that had I accepted a contract renewal, I would have been making the same amount of money. But not everything in life is about the money. When you gotta move, you gotta move.

Leaving

The next day when I broke the news, my Manager's reaction was priceless. He said that according to the contract, I was supposed to give a month's notice before tendering my resignation. I pointed out that he was absolutely correct... but I wasn't tendering my resignation. I was merely declaring my intention to see out the remainder of my existing contract (all three weeks of it) and declining the offer of a renewal.

On a side note, this struck me as amusing because I've seen contractors being let go, and they always claim they weren't fired, but rather that their contract was not renewed, which is technically true. And now I was declaring the exact opposite - I wasn't tendering my resignation, just not renewing my contract.

The next few weeks went by fast. COVID-19 started making its presence felt in Southeast Asia, and very soon, we would all be asked to work from home. On the last day in the office, I wrote a short and sweet farewell email.

Dear all,

Goodbyes are awkward. Have some pastries instead.

Farewell food.

I left a bunch of curry puffs and fruit tarts on the common desk, went out for a smoke break, and when I returned to my desk, a good three-quarters of it was gone. I also took care to thank my contract agent for the years of managing my contract and negotiating pay raises on my behalf (side note, this guy is amazing and did better for me than I would ever have done myself) and at his request, even wrote a complimentary review which ended up on the company website.

Thoughts about the contract situation

If my company had renewed my contract much sooner, it's very likely I would have stayed for lack of other options. Unfortunately for them, they took their time about it. On its own, losing me is no big deal, but I wasn't the only one who declined a renewal. Including me, a full quarter of the team left; and the Manager of the our service account at the Government Statutory Board was put in the unpleasant position of simultaneously dealing with the fallout of a global pandemic, which meant that very few people were about to take the risk of leaving their current jobs for a contract position.

A long line for the job.

Perhaps they felt that as one of the largest tech firms worldwide, there would be no shortage of people willing to take up contract positions for them, and they could afford to take their time. Perhaps they felt that a firm in their position was, shall we say, leading the dance. But they failed to consider the fact that with the caliber of the people they hired for these positions, these people generally have options. And people who have options are generally not known to be content with lying back and just hoping for the best.

Take nothing for granted. Ever. This applies to both employers and employees.

The Next Job

The rest of my contract was served from home, and I began prepping for my next job by taking a crash course in Laravel. Gradually, I began feeling something that had been missing from my professional life for the last couple years - excitement. In the process of trying to pick up Laravel, I also learned VueJS. Some quick experimentation led to the code from The Easter VueJS Puzzle.

The first day at my new job was also the day that Singapore's Circuit-breaker began. It would be the first time I had ever joined a new company without meeting my colleagues. The only person I met was the CTO, who issued me a MacBook Pro and a list of software to install.

And thus began life at my new company. It was on.

Singapore's Circuit-breaker was very much in force in my first few months at work. People had to adjust to working remotely. That meant online meetings and collaboration through chat. It actually wasn't so bad because code and commits are tools developers use all the time. I had to get used to the other tools that the CTO introduced - bug-tracking suites, Kanban boards, API clients. We used Slack to communicate and share files.

My home workstation.

There was also this small matter of getting used to the MacBook Pro. I hadn't used a Mac since 2017. I did, however, get a sweet setup going at a standing desk in the living room.

The CTO also said that he would ease me in slowly with some small tasks first. I implemented a couple of new small features along with corresponding unit tests, a user logout feature and a dashboard that featured some Data Visualization (I was psyched to finally use D3 in an actual scenario). I was having a lot more fun in the first three weeks than I'd had in three years in the previous company.

Some early disturbing signs

However, all wasn't rosy as time went by. My CTO gave me the distinct impression that he was low on patience, had a short fuse, a bit of a control freak and was prone to finger-pointing - qualities that I don't consider admirable of any person in a position of authority. His criticisms of my code, however, were valid, and I took whatever lessons I could get from the code reviews. I was a big boy; I could handle bluntness and a lack of social graces. After all, nobody's perfect.


Still, while perusing the code base for a new feature I was to implement, I came across something I found deeply troubling. Above a block of code that had been commented out, there was a comment that had been left there a few months before I joined.

// Fucking idiot programming logic

Now, it would be hypocritical of me to get my knickers in a bunch over some profanities, considering I've been known to use them quite freely myself. What I objected to, was that it had been written in the code base. This was highly unprofessional, and I had a bad feeling that I knew who had put it there. Sure enough, after a bit of digging into the code repository, my worst fears were confirmed. My own CTO was the culprit.

Why was I disturbed over this? As mentioned, it wasn't so much the profanities. It was the fact that he had opted for such a juvenile way of expressing himself rather than confront this openly. A quick search found other sarcastic and vitriol-laden remarks in the commit comments directed at God-knows-who, ranging from a few months ago to years. Suddenly, my CTO wasn't looking like such a great guy after all. He certainly had long-running unresolved personal issues.

Willfully blind.

How did I handle this? I'm not proud of it, but I opted to ignore it for now. I was still under probation and didn't want to rock the boat. Perhaps he had simply been in a bad mood on those occasions. Perhaps it was work pressure. Maybe nobody told him he was handsome. At this point, I was just making excuses for bad behavior, and trying to rationalize it away.

Next

The next five months were excruciating. It's a long story, so make yourself comfortable.

Ten Problematic Tech Terms

The tech world has been a-buzz recently. Following the Black Lives Matter riots across the USA, some tech firms have declared their intention to help eradicate racism - by erasing problematic language from their code bases. The overall objective is to be inclusive and avoid insensitive references.

How this is going to help exactly, remains a mystery to many of us. It's tempting to simply dismiss all this as just another poorly-disguised attempt at virtue-signalling. But in the spirit of joining in the fun, let's take a look at some of the terms slated for erasure and their proposed replacements. And some terms that haven't yet had the dubious honor.

1. Master/Slave

This term is used in tech to describe situations where one process or entity controls another, or where one is an original and the others (the "slaves") take reference from it. Ostensibly, tech such as GitHub, Python and Twitter (and even MySQL!) have decided that they will no longer use the terms "master" or "slave" in their code repositories. Instead, terms such as "main" and "replica" will be used.

No more master-slave relationships!

It's a bit of a stretch of the imagination to equate a "Master" branch in GitHub with slavery, but what do I know, right? I'm not a marginalized race in the US. Hell, I don't even live in the US!

2. Black/White

Google claims that the terms "blacklist" and "blackhat" have negative connotations associated with the color, and this is somehow denigrating African-Americans. Instead, we should be using terms such as "rejectlist" and "allowlist" to replace "blacklist" and "whitelist", respectively.

We can't be blackhats
anymore?

To be fair, "rejectlist" and "allowlist" are a lot more obvious than "blacklist" and "whitelist". It's objectively a good change. I just think the reasons behind it feel kind of forced. It's almost like someone's trying a little too hard not to offend black people.

3. Chief Technical Officer

Hey, how about "Chief" Technical Officer? Or "Chief" anything? Isn't that insulting to Native Americans who actually earned that title? Non-native Americans, you can do better.

So Sioux me!

Native American cultural appropriation is a real thing, yo. Just ask Chris Hemsworth.

4. Ninja

Eradicating the word "ninja" from tech vocabulary will be welcome. That's also cultural appropriation. Imagine how the real ninjas feel, having that term co-opted by a bunch of computer geeks who probably couldn't throw a shuriken worth a damn.

Won't someone please
think of the ninjas?

Also, it's incredibly lame to describe yourself as a "code ninja". Please just fucking stop.

5. Kanban

Another case of cultural appropriation. The Kanban was originally used in manufacturing operations in Japan. Then this got taken to the USA, and some time later, the tech industry took to using this to manage software development processes. We can still use Kanban boards, though maybe we should start calling them something else?

Yeah, call 'em something else!

I seriously doubt the Japanese are anything less than smug that the Kanban got adopted by the Americans. But wait... does this whole movement actually have anything to do with the feelings of other cultures, or is it just an excuse to make tech companies feel all progressive and shit?

6. Sanity Check

The term "sanity check" is usually in the context of testing. However, the word "sanity" might be sensitive to people who suffer from mental illness. I'm no expert here, and far be it for me to sound unsympathetic, but could that be because they suffer from mental illness?

Who're you
calling insane?!

The term "smoke test" has been suggested as a substitute. But it appears that the term already exists, and there's actually a difference. You know what, this is crazy (no pun intended) and I'm just gonna let the experts sort this out.

7. Dummy

A "dummy" anything is usually used in software development as a stand-in for the real thing. A dummy account. A dummy file. Dummy content. Just like crash-test dummies are used in place of real people.

I surrender to the awesome power
of your Wokeness.

But no, what if it triggers people who are, say, not the brightest bulb in the chandelier? We want to be inclusive, right? Twitter has suggested "placeholder", which actually isn't that bad. Unlike the case of "blacklist" and whitelist", however,  the term "dummy" was actually pretty obvious already and I don't think it needed changing.

8. Throttling

In software, "throttling" is the process of regulating the rate of processing, because sometimes you gotta slow stuff down in order for things to go smoothly. After all, resources are limited, and we don't want the system to bite off more than it can chew.

Just choking, folks!

But geez, this term is just so violent. It brings to mind wringing of necks and MMA chokeholds. Why such a hostile term? How about "hugging"?

9. Penetration Testing

This is actually a term used in computer security, to assess the defenses and robustness of any particular system. But it's kind of lewd, isn't it? Penetration?

Such penetrating insight!

Think of all the locker room jokes we computer nerds could make if this term were still in use. How about we just scrap it so people don't feel, y'know,  uncomfortable?

10. Alpha/Beta

Alpha release. Beta release. These terms are commonly used to describe software versions. You know what else they're used to describe? Males.

That's Alpha AF.

Maybe usage of this term encourages toxic masculinity. Should we chance it? I mean, if we're going to deprecate the use of "master" and "slave", surely this is next!

Conclusion

Yes, I'm being really facetious here. But let's be real for a minute.

Naming things is one of the great struggles of software development. Congratulations, we just made it a whole lot harder.

It's not that I think tech terms are set in stone and shouldn't change at all. Obviously, some change is for the better. Even more obviously, it would be better if they were done for the right reasons. If done to improve clarity or sustainability of maintenance; some objectively beneficial metric, yes I'm all for it.

But if it's done just for the sake of appealing to the Social Justice mob, I think it's ill-advised. Because there's no end to this sort of thing. People are always going to be offended by something or other. The world doesn't revolve around the USA and their great struggle with racism and their history as slave-owners, and it's time people realized that.

Now that's a master main stroke!
T___T