Five Tech Support Horror Stories

The early years of my career were in tech support. As with any other job, there were good days and there were bad days. After the third year at the job, the bad days started to outnumber the good. It all seems hilarious in hindsight now, but there were some days where things in this list caused me to question my career choices.

Until one day it all came to a head and I decided I'd had enough, and started over in web development.

Sometimes I get together with some friends who are still in tech support, and we trade horror stories of the users we have to help. These are some of the stories that get 'em, every time.

1. Plugging in

This is actually a fairly common one, but let's start small. You get called to a user's desk because the desktop computer refused to turn on no matter how many times they pressed the On/Off button. And they even checked if the main switch was on. And judging from the light, it was.

Not plugged in.

However, upon closer examination, it turned out that the cord wasn't plugged in. Yes, you read that right - the power was on but the plug was just halfway into the socket and needed to penetrate another two inches before the computer could actually benefit from that power source.

Sound stupid? Welcome to my life at that time, buddy.

2. Opening Excel

Another alarmingly commonplace occurence was getting called into the office of some hotshot executive who was encountering an issue opening a MS PowerPoint file in his (or sometimes, her) MS Excel application.

Now, if you're still scratching your head and wondering why that's a problem, reread the preceding sentence. MS PowerPoint file. MS Excel application.

Just a bad fit.

I dunno, that was the early 2000s, and attempting stuff like that smacked of trying to fit a square peg in a round hole. It was amusing the first couple times, and then it got old real fast.

3. Infinite scroll

This was was so cartoonish it was almost amusing. I got a panicked call to a user's desk because her MS Excel spreadsheet was scrolling endlessly downwards on her screen and she couldn't understand why. It conjured up images of getting hacked, a malfunctioning monitor and whatnot.

The truth was even funnier.

Held down the ENTER key.

I got there, and the first thing I did was remove the heavy binder from her keyboard, which had been pressing down on the ENTER key and causing MS Excel to react as though some user was holding down that key.

4. Email Signature

This particular incident did not happen during my years of Desktop Support, but rather during my fledgling years as a web developer. However, the incident in question made me more determined than ever to never get back to Desktop Support.

A user had asked me to help set up her email signature because she had no clue how to use MS Outlook. I obliged, because I know sometimes Microsoft software functionality can be hidden in the darnedest places. But then after I got into the interface, input the standard company email signature template, I asked her to type in her name into the box and click the SAVE button.

Yay! We're now
qualified to type
our own names!

Guess what she told me?

"You should do it. You have an IT Degree."

That level of entitlement was staggering. What was she implying now, that she needed an IT Degree to type in her own goddamn name? What foolishness was this? This wasn't a competence issue. This was an attitude issue. And the less of this I see in the workplace, the better. There's no place for this nonsense in any work environment. Hopefully this woman has since retired. At the very least, she's someone else's problem.

5. Emails

This is also a fairly common complaint among grunts, not just tech grunts - people feeling like they're entitled to your time outside of office hours.

I remember having a dinner appointment with someone, and Human Resources asking me to stay back because they needed me to, wait for it, retrieve some emails from the email server backups between three of the staff. Staff they were planning to terminate, thus they needed evidence of wrongdoing as leverage.

A whole bunch of
DVD backups.

Basically, nothing was on fire. They just needed me to help cover their asses. Hours later, as I was retrieving yet another batch (back then, it was the era where stuff like that was stored on DVDs), when HR asked me: "I'm sorry, did you have something on tonight?"

Seriously, lady, if the answer was "yes" would it have made a difference? If not, how about just shutting the fuck up? You know what's worse than people who don't care? People who don't care and try to act (badly) like they do.

Phew!

I wouldn't say any one incident turned me off of Desktop Support. Even on its own, it can be a repetitive grind that wears on the soul. But these were the war stories that I shared with the guys. And their reactions suggested that these occurrences weren't at all unheard of. Some of their stories were even more unbelievable than mine.

No, you don't need an IT Degree to read this,
T___T

Five Reasons to learn Web Development in 2025

Recent events such as the rise of generative A.I, have made tech work a little less attractive than it used to be. Web development, in particular, has suffered. That's probaby because a large chunk of web development is automatable, and even before A.I came on the scene, there had been numerous tools such as Content Management Systems and Low-code development platforms.

Thus, web development being automated by A.I was par for the course.

Robots writing websites.

Still, not all is lost. While web development might have lost much of its luster, there are still good, strong reasons to pick it up in ones tech career. Unlike the tech reporters and HR executives who write listicles like these, I have actually been a web developer before. I speak from experience, my dudes. And following are some of the most compelling reasons I had, in no particular order of importance, for going down this path.

1. No complicated installation

Ever tried to learn a language like PHP or Java? Every single one of these languages requires you to set up some kind of compiler or interpreter environment. PHP requires an Apache server. Java needs the Java Runtime Environment. You can write all the code you want, but until the code gets compiled or interpreted by the environment that you have to install and set up, you're not getting even a Hello World program done.

All you need is a browser.

HTML, CSS and JavaScript, however, do not. All of them already run in any major browser - Firefox, Chrome, and so on. In effect, the environment is right there for you.

This is not to say that you will never need to do any complicated installation. But for the basic building blocks - again, HTML, CSS and JavaScript - of web development, you don't. You will need to do that when you want to pick up a server-side language and maybe databases and definitely for the NodeJS style of development. But for basic stuff? Even the slightly more advanced stuff? Nope, not even a little bit. That is a lot more than you could ever say about other programming languages or platforms.

2. Good skill spread

When you learn web development, you learn HTML, CSS and JavaScript as a base starting point. That's already a good spread right there.

HTML and CSS are where you learn front-end and possibly even design. When you learn JavaScript, in addition to all the things you pick up when learning a programming language such as operators, arrays, branching and iterative logic, you also learn asynchronous operations and DOM manipulation.

A good spread of tools.

That's not to say that other tech disciplines don't have their own unique perks. But where it comes to the skill spread, web development wins. I don't think anything else even comes close.

Once you get past the basic toolset of HTML, CSS and JavaScript, back-end programming and databases will come into play. It's never just web development. Even if you are averse to the thought of being a humble web developer for the rest of your career, there are far worse places to start.

3. Resources

Now, when I say "resources", I don't just mean documentation, references and learning materials, though there's plenty of that, yes. But web development is not special in that regard because any other tech discipline boasts plenty of learning resources and a community dedicated to helping each other learn.

A good learning
community.

Though, in this case, web development has something extra.

You see, every humble HTML page on the internet can have its source viewed and played with in the browser, reverse engineered, and so on. Every URL on the internet is potentially a resource for learning, much like how I learned to cobble together JavaScript widgets decades ago.

In contrast, it's not possible to just take any desktop application and reverse-engineer the code, because the code has already been compiled and is no longer human-readable.

4. Ready use case

Often, when learning a programming language, it's helpful to be able to use newly-acquired skills to build something, so as to really hammer home the muscle memory. Something both relevant and useful, preferably. Not that Hello World programs don't have their place, but if one wishes to level up, better use cases are the order of the day.

And with web development, those use cases are almost too easy to find. Web development creates web pages, at the minimum. And after that, at varying levels of complexity, web applications. One does not have to stretch too far to find something worth building... and because it already exists, you know that it is both worth building and possible to build.

Applying what you learn.

My larger point is that what you learn can readily be applied. Not just in creating and editing websites, but in general software development. This also means that your chances of landing a job with that skillset cannot be understated. In this day and age, web developers are perhaps not nearly as in demand as they were a decade ago, or paid nearly as well, but the skillset goes beyond just web development.

For example, a lot of existing software already leverage things like REST API endpoints. These are basically URLs, which are pretty much the backbone of the web. REST is an almost inescapable part of the whole web development deal. Ergo, if you deal in web development, at some point you are going to be dealing with REST endpoints, which overlaps a large part of software development regardless of discipline.

Or even mobile development. In case you weren't aware, a large chunk of mobile tech is basically HTML, CSS and JavaScript.

I could go on... but do I really need to?

5. No gatekeeping

In the legal profession, there's the Bar Exam. In the medical profession, there's the Medical Regulatory Authority. In tech? Other than job interviews which exist at almost every industry, there's almost no gatekeeping in tech. Even the requirement for Degrees of Diplomas is not a really hard one.

When I say "no gatekeeping", I don't mean that nobody tries to gatekeep. The fact is that many people try to gatekeep, but it just doesn't work because to gatekeep, one needs a unified set of standards. It's almost impossible to establish said standards in a landscape as varied as tech, whose goalposts shift constantly.

The gatekeeper.

And while this inability to gatekeep exists in many areas of tech, none moreso than web development. HTML, CSS and JavaScript are fairly stable at this point, but these are just the base technologies. Their offshoots - frameworks, libraries and the like - keep springing up like mushrooms. And when you consider databases and backend programming languages, the possibilities multiply even more.

All in all, one could come in anytime in web development, and still be relatively fresh and relevant. No one can stop you from making and publishing web pages and applications, not in the same way they can stop you from practising law. You don't need a license to write code, so nobody can revoke it.

Some clarifications

The reasons stated here are in relation to those for choosing other tech fields. Why, for instance, web development when you could go for Data Analytics or cybersecurity? Reasons specific to web development.

I was inspired to compile this list because there are a lot of vague, generic and - to be brutally honest - trite lists out there on the web that extol the virtues of web development. Hopefully this is a better list.

<html>Bye for now,</html>
T___T

Buttons or Divs? What to use, and when

With the power of CSS, HTML is significantly more visually versatile than it was in its inception more than two decades ago. Especially with divs. You can make divs appear as anything - paragraphs, block quotes and images. In extreme examples, you could even render entire paintings using many, many divs. 

A huge variety of shapes,
especially rectangular.

The humble div tag, coupled with CSS, is no longer just a rectangle on the browser. Using properties such as transform, border-radius, width and height, among others, a web developer can achieve a myriad of looks.

And this manifests quite frequently, in buttons. Previously, I discussed whether button or input tags would be preferable, but today we make a separate comparison between divs and buttons.

Divs as buttons

Making divs look like buttons is simple enough. How about behavior? Well, for that, JavaScript accomplishes this fairly easily.

One is a button and the other is a div.

<button>This is a button</button>
<div style="cursor:pointer; background-color:rgb(230, 230, 230); border:1px solid rgb(100, 100, 100); border-radius: 3px; font-family: sans-serif; font-size: 12px; width: 8em; padding: 0.2em; text-align: center">
This is a div
</div>

But they can both be made to perform certain actions on a click.

<button onclick="alert('I am a button');">This is a button</button>
<div onclick="alert('I am a div');" style="cursor:pointer; background-color:rgb(230, 230, 230); border:1px solid rgb(100, 100, 100); border-radius: 3px; font-family: sans-serif; font-size: 12px; width: 8em; padding: 0.2em; text-align: center">
This is a div
</div>

Depending on the browser, you should see no appreciable difference between these.

This is a div

How about submitting a form? Well, a button usually does this.

<form id="frmTest">
    <button>Submit<button>
</form>

But if you want a div to do this, all you really need is a bit more code.

<form id="frmTest">
    <div onclick="document.getElementById('frmTest').submit()">Submit<div>
</form>

Definitely possible, but should we?

Visually, there's not a lot of difference. In fact, styling divs to look like buttons, could even potentially offset visual differences of button rendering between browsers. For example, we take the code written earlier.

This is how it looks on Chrome.

This is how it looks on Safari. See? There's no visual change in the div we styled, but the button looks remarkably different.

However, not everything is about the visual. Especially not to the visually-impaired. The button tag and a div tag reads differently in semantics. On a screen reader, the button tag immediately stands out as a control to be clicked, while a div is semantically no different from any other div.

That is the greatest, and most significant difference. Not being blind, it is understandably difficult to imagine perceiving anything other than in visual terms, since a large part of what people like us perceive, is in the visual medium.

Conclusion

The internet was not only made for people like myself. The internet was meant as an equalizer where it came to information access. Not only did it mean that the average person now had access to information that was not available readily in the past, people with visual disabilities were supposed to be able to access this information.

And that access could be compromised if code was written with the visual intent in mind rather than the semantic.

T___T

How I Quit Smoking Using Software Development Principles

This is the story of how I quit smoking, for the second time in my life. The first time was back in 2012.  What happened was that I took stock of how much I was spending on cigarettes in a month. It amounted to SGD 300 and change. And I gave it to Mom, fed her some bullshit story about being promoted at work and this being my pay rise. I thought it was brilliant back then - I'd committed to giving her that money now, and couldn't take it back. And just like that, I stopped buying cigarettes, and smoking them.

Stubbing the habit out.

After a bit of a struggle in the first few months, I was clean. All this lasted a full year. And then I changed jobs. I was still a web developer, but now in a company with significantly more resources.

Guess how much more the new job paid me? Yep, about SGD 300 per month. Can't fight fate, amirite? Soon I was right back at smoking with a vengeance, and never stopped for the next twelve years. In fact, it got worse during COVID-19, when I was working from home. I was also smoking in the bathroom, kitchen and living room constantly. I was averaging a pack a day, sometimes more.

And now I was earning significantly more money, perhaps double. Back then, being a consistently broke web developer, I could use a lack of funds as a way to stop myself. Now, it was no longer feasible. One could say I was a victim of my own success.

Quitting for the second time

Fast forward to 2024. I had just moved house and the thought of smoking in an otherwise clean new apartment just felt wrong. Besides, I'd managed to stop smoking in the bedroom due to being married and all, I figured it was no big deal to expand the no-smoking zone to the entire apartment. Thus, I kept my cigarettes in the mailbox on the first floor. Every time I needed a smoke, I would take the elevator all the way down to the first floor. As I live on the twenty-fourth storey of my apartment block, you can imagine this got old pretty quickly.

It's unclear and what point I decided to work towards quitting smoking altogether so I could do away with this annoying hassle, but the plan to cut down was soon in motion. I restricted myself further; there should be no going downstairs just to smoke. If I was going downstairs, it had to be for some other reason, such as checking my mail, or training at the outdoor gym.

That was when I decided to see if I could recapture my vigorous youth. My chin-ups record stood at fifteen. I wanted to see if this aging body still had it to reach those heights. And, from experience, this would require muscular conditioning, which meant consistent training. And with what I had mandated with regard to smoking, this looked like an excellent opportunity to kill two birds with one stone.

As a software developer interested in Data Analytics, I even compiled some statistics beginning from the 4th of March. The point was to exercise enough discipline to compile those stats, and track progress.

A combo chart!

Soon, I was down to five sticks a day. And on the 19th of June, 2024, I smoked my final cigarette.

Strangely enough, psychologically, there was nothing to fight. One day I was a smoker, and then the next day, I simply wasn't. I even forgot all about trying to quit (other than faithfully filling in the data once daily) until my wife checked in to see how I was coping. The only time I felt any kind of craving was directly after a workout, and even then it was manageable.

I seem to remember the process of quitting being a lot tougher than this. Perhaps it was because I had turned smoking from a pleasure to a chore.

Aftereffects

Not needing to smoke has, given me a sense of freedom. No longer do I feel the need to stick to areas where smoking is allowed, or feel under-equipped if I leave home without cigarettes or a lighter. And while the Missus was agnostic to me being a non-smoker, she really grew to like having an extra SGD 500 in our joint account every month. (I know, cigarettes got so much more expensive in the past ten years. Crazy, right?)

Saving money.

The most obvious question, however, would be: how much healthier has this made me?

Sorry to disappoint, but it hasn't made me feel appreciably healthier. I assume I'm at lower risk of lung cancer and heart disease, but short of a thorough medical checkup, there's simply no way to tell.

I seemed to have put on almost 10 kilograms. Whereas before this I was weighing at a range between 69 to 72 kilos, now I was weighing between 77 to 82. Apparently, the regular nicotine intake had been doing a number on my heart rate; and now without it, my heart wasn't working quite as hard. Which is great, but I wasn't shedding excess weight as fast either. Good to know, I guess.

As for symptoms like fatigue, grumpiness and anxiety... I didn't notice anything. I mean, not more than usual. Insomnia? Not at all. Even with the Missus snoring like a cow beside me every night, I slept like a baby.

Applying software development principles

What I'd done here was programming. Not programming in the sense of me typing in commands into a computer that would then execute those commands faithfully, but programming nonetheless. Programming of the incremental, conditioning kind. Most programmers would have come across a warning from their IDEs at some point or other - Unreachable Code. Code that technically existed in the system, but due to the way the program was structured, would never be arrived at during an execution.

I had used my training as a software developer, and applied it. First, instead of outright stopping myself from smoking, I imposed restrictions around it. I could still smoke, but only if an increasing number of conditions were met. Thus, if I wanted to badly enough, I could jump through a lot of hoops. At some point, my natural laziness won out. Theoretically, I could still smoke if I wanted to, but the combination of conditions I would have to meet pretty much turned that into Unreachable Code.

Setting up roadblocks.

Another principle which I took advantage of, was that of optimization at the point of bottleneck. It's probably more a manufacturing principle than a software one, but still applicable nonetheless.

In any system, there exists one (or more) points where throughput is constrained, and the only way to increase throughput is to optimize at the bottleneck, not away from it. This means that we need to understand what the bottleneck is. In my case, I wanted to make smoking less easy, not more, so one might say I took the principle and inverted it for my purposes.

Why had I been smoking so much? Basically, because I could. There was an ashtray in almost every room in the house, and I had pretty much given myself permission to smoke wherever I wanted. It was convenient. Thus, if I wanted to make it less convenient to smoke, I had to impose restrictions. Barriers to doing so. As such, I identified the "bottleneck" (more like a leak, really), and fixed it.

Of course, I could have just told myself that smoking was bad for me and I should just stop. But telling that to a guy who already works out five days a week and survives largely on oatmeal, is ineffective.

Epilogue

It's been eight months, give or take, since I last smoked. Ostensibly, the lifestyle change should have been considered to take hold once past my second month, so I'm gonna take the win. Go, me!

Unfortunately, my little foray into chin-ups did not quite go as well. After I managed to hit ten chin-ups, my right elbow gave up on me. Golfer's Elbow, they call it. That's another story for another time.

Much tobacco-fuelled love,
T___T

Shout-out to Lance Storm of Storm Wrestling!

2001. Picture a year where the Internet was a vastly different place. Ethernet had just taken off, rapidly eliminating those charming dialup modems. Websites, however, hadn't caught on that quickly, the vast majority (or at least, those I visited), still designed as though they had to abide by network bandwidth restrictions. Clunky graphics, clumsy animation, that sort of thing.

And it was during this time where I watched pro wrestling. In the 90s and early 2000s, pro wrestling was filled with all manner of colorful characters, and one such character was the Canadian pro wrestler Lance Evers, ring name Lance Storm. He had (and still has) his own website, Storm Wrestling.

There's a storm
coming.

It was a cozy spot on the Internet where Lance Storm discussed wrestling with fans and had his own little community. I was all for it, and even joined his book club!

But mostly, Mr Evers served as an inspiration for a young I.T Degree graduate and burgeoning web developer.

How was Storm Wrestling an inspiration?

Simple. No matter how crappy one might think the website was - mostly by today's standards, it was definitely cool back then - the fact remained that Lance Storm was not in the tech business. He was a pro wrestler.

And nevertheless, he registered a domain name and made a website. Again, a shitty website by today's standards, but still! Come on!

A relic of bygone times.

What kind of excuse did I, an actual web developer, have for not having my own website? None. Nada. Just pure laziness. Lack of motivation.

Registering a domain name and paying for hosting aren't extremely expensive. Honestly, if you wouldn't invest that much in your own career, why should any prospective employer?

No, I didn't get my own website right away. A lot still had to happen before I got off my ass to do shit. But it did kick-start the thinking process. And for that, I'll always be grateful.

Epilogue

It has been more than twenty years. And now I do have my own website and domain name. This has opened countless doors. Storm Wrestling inspired Teochew Thunder. Pretty poetic, wouldn't you say?

Stealing your thunder,
T___T

Why people should (and shouldn't) hire older software developers

Seven years ago, I wrote this post on my 40th birthday. Today, as I turn 47 in a few days, here are some more thoughts.

On my website, I described myself as "an aging software developer". Some people have told me that this could reflect negatively on me. They're mistaken, but I forgive them - they aren't from the tech sector and don't know better. You see, when I say the word "aging", this is not me being humble. This is me flexing the fuck out.

Just showin' off.

But please, hear me out. I swear, I'm not going to pull out lazy clichés like "older programmers are more experienced, more mature, have more gravitas, etc" not just because they're lazy clichés, but also because they're not true. And if I have to explain why they're not true, perhaps this is not a conversation you're ready for.

And because I enjoy being contrary even against myself, I will follow that up by explaining why older devs aren't necessarily the best choice. In the same spirit, I will avoid the stereotypes of being inflexible, slow and outdated. Again, those are lazy clichés and we should rise above them.

Why older devs are nothing to sniff at

You see, software technology is an industry which demands constant reinvention. As a result, past a certain number of years in the business, older devs tend to go "fuck this constant re-learning. I'm gonna go drive a cab or something".

In short, it's an industry where you find few old folks. And you know what they say about being wary of old men in a trade where men die young. Well, programmers aren't dying per se, but they're certainly quitting once they hit a certain age, because, if one was just doing it for the money to begin with, at that point it's just not rewarding anymore.

And because software technology is an industry which demands constant reinvention, it almost goes without saying that anyone who's had to stick around for that long, has gone through quite a bit of that. Me personally, I went from desktop support to web portals, to commercial websites, to web and mobile applications, to having to shoulder the duties of an entire infocomm department all by my lonesome. Sure, one could say people who have survived that long in the industry are merely lucky, but very few people are that lucky.

Adaptability is key.

So, if you needed someone highly adaptable that could adapt to the constant change that defines this industry, who would you choose?

An enthusiastic youth with lots of potential to learn and grow and evolve and theoretically should be able to adapt? Or an older programmer who's actually evolved over and over through the years and survived to tell the tale?

The conventional wisdom, of course, is to go for the proven product rather than the one that has potential -in theory. Yes, some of us older folks can be rigid and stuck in our ways, but the nature of this industry weeds such people out fairly quickly. You're left with the people who are adaptable enough to survive this industry (because we have!), and in this day and age, that's no small thing.

Again, no argument would be complete without presenting the other side. And there are plenty of compelling reasons why the modern employer might not want an older developer.

Why you should avoid older devs

Older software developers, unless they totally mismanaged their wealth, tend to have money. The industry pays well, and even a mediocre dev like myself might be earning more than Middle Management at an SME. As such, you're not going to get one for cheap. We more than likely don't need the peanuts you're reserving for code monkeys.

Peanuts, anyone?

Manipulation. No matter how noble a person an employer thinks they are, this is an organization and as such, there's always something of that sort going on, to one degree or another. Against manipulation, many older devs have developed, if not outright immunity, at least a discomforting degree of resistance to it.

Past a certain age, most older devs already have whatever we ever wanted out of life. We're there. We're comfortable. We're not hungry and desperate as the younger ones probably are. We're not going to kill ourselves for "exposure". Or submit to opportunistic lowballing (c'mon, we all know it happens) just to add to our resume. And that is an absolute negative because cold as it may sound, it makes us less open to manipulation.

Older devs do come with experience, and part of that experience is security. We're generally zen about the fact that we'll probably die and be forgotten. We've come to terms with the realization that if we were really destined to do anything truly exceptional, statistically we would have done it decades ago. Most of us are too tired, or probably done too much, to feel that we need to prove a damn thing. And if you're the sort of employer who likes to make your staff jump through flaming hoops to prove themselves, again, that kind of security and self-assuredness makes us untenable as employees.

All in all, older developers aren't cheap, and we're not desperate or hungry enough to run through walls at your command. And I can't in good conscience paint that as a positive for employers.

In a nutshell

For the right kind of employer, older software developers are an exceptional resource.

Also, consider this - with the news that Artificial Intelligence is going to make programmers obsolete, whether it's true or not, this is going to impact the number of young developers available on the market. Because if younger programmers think that this career path is no longer viable, they're just going to leave, and who could blame them?

Us older programmers? We're dug in, and we have little to lose. Chew on that!

Old but gold,
T___T

How worried should software developers be about Devin AI? (Part 2/2)

On the subject of Artificial Intelligence taking over software development, there's both good news and bad news. Actually, most of it is bad. But let's start with the good.

Your edge against Artificial Intelligence

Computer processors have grown faster over time. That's a bit of an understatement; processing speed and power have increased at an astonishing rate over the past few decades. Faxes used to take twenty minutes to travel the world; now email performs the same function in seconds, or less.

But however fast computers are now, they're still at best capable of accessing and processing information millions of times faster than humans. Their ability to create new things is an illusion - creating what appears to be new things using existing content as input. The creativity factor is probably a zero. And mathematically, zero multiplied by millions, is still zero. Thus, no matter how fast computers get, they aren't any closer to true creativity than they were decades ago.

Machines are always
significantly faster.

Human beings on the other hand... while it's difficult to objectively measure creativity, I think it's safe to say that the creativity factor of the most brilliant minds on the planet, is probably above zero. Therefore, no matter how slow human beings are compared to computers, we still have that edge.

I've also mentioned before that machines aren't capable of loving their work. They aren't capable of being motivated by things like pride and passion. All that requires flesh and blood. So, for whatever it's worth, that is one thing that no A.I can ever replicate. For the simple reason that whatever A.I is capable of, is what humans have been able to define, just performed at significantly higher speeds. No human has ever been able to successfully formulate love, passion and pride. Subsequently, no A.I is capable of those things.

Artificial Intelligence's edge against you

One may think that A.I's lack of pride works against them. But this also means A.I, doesn't have an ego. A.I is not programmed to give up out of frustration, or refuse to learn because their non-existent pride forbids it. A.I is relentless, and keeps going. And because A.I is programmed to learn, at some point it will write better code than any human.

If, as a software developer, you have predicated your entire career around your ability to write clean, beautiful, well-documented and nicely structured code, you have spectacularly missed the point. A software developer's job is not coding. Your job is to solve problems and provide business value. Sometimes, that involves writing code. If there are people who can write code as well or better than you, since Devin AI can trawl the internet and get their code; subsequently Devin AI can code better than you, faster than you, and with a lot less effort.

Whose code is better?
Who cares?

Is it true that A.I can code better than the average software developer? That's the wrong question to ask. The correct question is, how badly do employers want it to be true?

We can argue until the cows come home, about the qualities human software developers bring - passion, pride, possibly better code. But none of it matters. When your bosses ask you about the progress of a project, do they ask how clean or beautiful the code is? No, they ask how soon it will be ready for production. The sad fact of the matter is, code quality is an engineering concern, and business people primarily care about profits. So even if human beings were truly able to write better code, business owners would probably still be more forgiving of whatever flaws A.I produced, as long as it didn't affect the bottom line.

One could argue that bad code does affect the bottom line. But again, how much would it matter to the customer base?

You could say you would support human-created art over computer-generated art. But when it comes right down to it, would you be able to tell the difference? Similarly, would the average consumer be able to tell if it was a human who wrote the code, or A.I? Would the average consumer even care as long as shit worked to an acceptable degree?

Twenty years ago, I was a web developer. I made database-driven websites for a living. Then came website builders that automated everything I was doing, and put the power of website creation squarely in the hands of non-technical people. Thankfully, I had already moved on to bigger things before this happened. Would these website builders truly be able to outdo the creativity of the human mind? Maybe not. Would it matter if they didn't? Would the average web surfer be able to tell the difference, or even care? How creative or cutting-edge do we truly need websites to be?

Think about all the writers whose work A.I is generating new content based on. Or filmmakers who may be going out of a job once A.I can replicate their work and create seemingly-new work imitating their style. Unless users have consumed enough media, books and films to distinguish A.I generated content from the "real" thing, there is going to be a market. And the machines can churn out more of this stuff quicker than humans ever can. Imagine the profits. By that point, would those profiting care about authenticity? Would consumers care enough to make a difference?

Therefore, it's no longer even about who can do the better job. It's about who can do an acceptable job, for much cheaper.

In summary

To answer the question in the title, how afraid should software developers be?

I don't want to underestimate the power of A.I. At the same time, though, let's not get carried away. Either way, I'm at the sunset of my career and I have just about no skin in the game. If A.I takes over, great. If it doesn't, also great. Either way, I doubt I'll be losing much sleep over it.

This is your world now, kids. Enjoy.

Keep calm and code on,
T___T

Separating Text Editors from IDEs

The acronym "IDE" stands for Integrated Development Environment. There is a little bit of confusion as to what IDEs are, leading to questions like "Is TextPad an IDE?" (Spoiler: The answer is No).

TextPad is a text editor. There are distinct differences between a text editor and an IDE, even though they may look similar to a layperson. Chief of which, a text editor is part of an IDE. An IDE comprises of many components, one of which is a code editor of some sort.

What Text Editors do

Text editors edit text. It could be a block of code, a poem about dinosaurs or a dissertation about why dolphins are such jerks. Think of your text editor as a drum. The thing you beat with a stick so it makes sounds? Yeah, I know, that sounds wrong. But anyway...

Now a text editor isn't exactly a code editor, but it's awfully close. A code editor edits code, which is basically text. It's essentially a specialized kind of text editor, highlighting code structures and syntax errors, autocomplete suggestions and maybe even beautifying it for human eyes.

Now if you think of your text editor as a drum, think of your code editor as a full drum set with cymbals.

Full drum set.

Technically, not all code is text, but for most high-level programming languages, they are. Sublime Text, for example, can edit code for PHP, HTML, Python and a host of other languages. Notepad will edit the text just fine, but won't highlight syntax. That's pretty much the difference between editing code and editing text. Most text editors can edit code in a pinch, and vice versa.

As a web developer, I've had to use text editors to edit HTML, JavaScript and CSS code. And generally didn't encounter many problems. You could still do that for code that needs to be compiled, such as Java or C#, but that would make the process of development way harder than it needs to be.

What IDEs do

IDEs consolidate common developer tools onto one interface, so this potentially eliminates the need to individually configure separate software packages. At the very least, an IDE provides a code editor and an environment for running the code.

Now if following the earlier analogies, think of your IDE as a rock band setup with drums, keyboard, bass guitar and drum set, all in one place!

A full rock band setup.

Some IDEs provide other features, such as:
- file versioning.
- deployment management for DevOps.
- workflow and project management features.
- build automation
- specialized interfaces for mobile development, such as Android Studio.

An example of an IDE would be Eclipse (for Java and Python, among others) and Visual Studio (which handles C#, HTML and so on). They are called IDEs because they also run the code in addition to editing it. They can debug the code and point out syntax and (some) logical errors.

In a Nutshell

Text editors basically process and format text. IDEs almost always include a text editor of some sort, but the function of an IDE goes beyond text editing.

Text you later,
T___T

That strange feeling that comes with achieving that prize

It's an odd sensation. Early this year, I received another salary increment, which put my pay bracket - and subsequently, my total monthly income - at three times what it had been back in 2012. And it is strange because back then, I was a struggling web developer who was regularly pulling twelve-hour workdays dreaming of one day making a certain amount of money every month. And what was that lofty goal, one might ask? Why, that amount I was aspiring to, is less than half what I make now. Significantly less.

In other words, I'm making more than I ever wanted to.

Was it inflation? No. I did the math. Even with inflation, I'm still making substantially more.

Sure, I make a lot less than many people who are younger than me. But given the fact that I spend like I'm still on that miserable monthly wage twelve years ago, I can feel a hell of a lot more secure than the average millennial.

How?

Spending within your means is merely one way of saving money. Any financial advisor worth their salt will be the first to tell you that saving money isn't the way to increasing your income. It's just a way to minimize your chances of becoming desperately poor. Of ensuring that you always have something in reserve. But it will not make you rich.

It's not working hard and education, either. Sure, I did both. But neither of them, on their own, or even in tandem, got me money. No, it was keeping one eye open for the next opportunity and ruthlessly moving on for a significant pay bump. I always (well, mostly) enjoyed my work, but made sure never to get too comfortable. My first disastrous six-year stint as a desktop support guy taught me that much.

And that brings us back to the issue of always having something in reserve. Living a very financially sustainable lifestyle is what gave me the freedom to just move on whenever I felt like it. No waiting for bonuses or bullshit like that. No, when the TeochewThunder Train moves, it moves.

The train moves on.

Living like you're on your last dollar isn't a lot of fun. Let me tell you what is even less fun - actually being on your last dollar. Living from paycheck to paycheck. Relying on the goodwill of friends and relatives. Taking handouts from the Singapore Government. Relinquishing your last shred of dignity to survive another month. Thankfully I've never had to go that far, partly because I never allowed myself to.

I lived as though I was on my last dollar for years out of necessity, then I started living like this so that I would never again need to live like this.

I mean, what is money really for? Overseas vacations, fancy restaurants, the trappings of the high life? Rubbish. Those are irrelevant. What money ultimately really gets you is freedom. Freedom to do whatever you want, on your own time. I want money so that I don't need to worry about not having any.

That's all it is. That's all it ever was.

And now...

I work a lot less. Partly because with experience, I can recognize lost causes and dial back accordingly. I can get more done with less effort.

And partly because at this point, I have very little left to prove. I'm 47. In ten years, I'm either dead, retired, or well on my way there. If not sooner. I have no kids, or even pets. Being recognized as a valuable member of the company does nothing for me psychologically or emotionally. I lived, I will die, and in my time here I did nothing that would shake the world, or echo through the centuries to come. I am no better than the average schmuck, and I'm perfectly OK with that.

I lived, and I will die.

And also because I've built up a respectable nest egg... and unless I lose it all through a random act of stupidity, I'm good. Thus, I'm not afraid of losing my job or anything like that. I can work without that millstone hanging around my neck. I can actually enjoy my work. It can't be overstated how important that is.

Final Notes

I've been seeing Singapore Parliamentary debates about how ineffectual the WSQ framework is with regard to improving employment. People have been complaining about not being able to get good jobs despite upskilling and upgrading. That's because it's not meant to work that way. The Good Jobs Genie isn't going to suddenly appear and let you have your pick of jobs just because you got a certification in whatever. Upgrading is not a silver bullet that will solve all your problems. It's just one step in a series of many steps, some meant to be taken concurrently.

You owe the world nothing, and in turn, it owes you nothing. Whatever you have is what you can get, and more importantly, what you can keep.

$ee you later!
T___T

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

A Comparison Between Tables and Divs (Part 2/2)

Divs have been the de facto standard for web layout for over a decade since the advent of CSS. The versatility of divs cannot be overstated, though it is possible (and alarmingly easy!) to overuse them.

Deep levels of nesting.

Any web developer who has ever run into front-end maintenance problems due to multiple levels of nested div tags, will know exactly what I mean. This, of course, naturally leads to the question: Can tables be nested too? The answer is yes, and those seriously disturbed individuals who have attempted this will doubtless live to regret such depravity.

Learning curve

Divs are usually used as containers for HTML elements and content (including other divs) and then styled using CSS. This can lead to a whole ton of nested divs if a web developer is not careful. Again, as with tables, any missing open or closing tags leads to malformed HTML, thus it is important to keep them as simple as possible. Unlike tables, this is actually possible for divs, since the minimum viable HTML for one div is a single div tag.

<div>Content</div>

The learning curve for divs by themselves isn't huge, though CSS is another matter entirely. There are tons of options that can drastically change the visuals of your site. In addition to learning about the CSS Box Model, a web developer also needs to understand the position property if fancier shenanigans are required.

Use cases

Web layout now predominantly uses divs for many reasons, chief of which is mobile layout. Div layouts are easily made to be scalable (due to CSS) and this a site can be easily fitted to whichever screen size is required, without needing to make a lot of changes.

Different devices and
screen sizes.

Divs can also be used for tabular layout with a few interesting options depending on the library used, but this also tends to complicate matters; and in my opinion, does not significantly have less problems than simply using table tags for such use cases.

SEO

The ability to separate styling from content is one of the greatest boons of div tags and CSS. This solves many problems that table-based layouts are prone to.

Crawling the web.

For example, when using div tags for layout, it is possible to position important content in the HTML for web crawlers to pick up first, while visually repositioning the content elsewhere or even hiding it. Not only is it possible, CSS makes it almost ridiculously easy.

Conclusion

Tables and divs both have their place. Divs are ubiquitious. Tables fulfill a smaller, but still vital, place in the HTML ecosystem. It is important to use both for their respective best use cases.

Your div-ine web developer,
T___T