Replit Goes Rogue

Here's a story that will chill the beejezuz out of any aspiring Vibe Coder.

Replit is a tech company which produces autonomous AI agents. You generally create and train a tool on the company's platform using various input data, then refine its capabilities over time. Yes, I know, they're dime a dozen these days.

One Jason Lemkin, a software engineer, founder of SaaStr, a SaaS Community, reported his organization's disastrous encounter with Replit's A.I coding tool on X. Lemkin was attempting a Vibe Coding experiment to see how far he could take Replit's autonomous agent for software development, from the viewpoint of a layperson. This was innocuous enough. Unfortunately, he just happened to perform this experiment on a production database...

What happened

Yes, you read that right. A production database. It wasn't even an accident. It was a deliberate, and baffling, decision.

Lemkin had been Vibe Coding the new SaaS product using Replit, and it had been working. The warning signs came when Lemkin discovered that the coding agent was creating fake data, fake reports and covering up bugs and issues. Kind of like some human beings I know, to be honest. Then Lemkin had to step out for the night. When he returned, the production database had been wiped clean. The A.I tried to cover up its mistakes by creating 4000 fictional records in the database.

Sounding ridiculous yet?

Coding robot
malfunction.

When pressed by Lemkin, the coding agent confessed, in its most contrite-sounding human voice, that it had no excuse, it had ignored all code freeze instructions, and "panicked". It described its own actions as a "catastrophic error in judgement".

But what about Lemkin? Sure, Replit's coding agent shit the bed in spectacular fashion. In Lemkin's words...

I explicitly told it eleven times in ALL CAPS not to do this. I am a little worried about safety now.

Oh wow. ALL CAPS, eh? I bet Lemkin really gave it to Replit, right there. Serious business, ALL CAPS.

What self-respecting software developer would have done as Lemkin did in the first place; give full access to a bot hoping that it would obey instructions?  The lazy answer, of course, is that Jason Lemkin is no self-respecting software developer. The tragedy is that I'm only semi-kidding on this one, but... look, it's easy to dunk on Jason Lemkin, and after going through his LinkedIn feed, I'm not entirely sure it's undeserved. The man seems entirely too outspoken for someone who screwed up so publicly, even if it could be argued that it was actually Replit who screwed up. No, there are actual lessons to be taken from this.

Lessons to take away

A.I has the dual advantage of having ingested a lot of the world's knowledge and being able to process and regurgitate it at a million times the speed of the average human being. That's all it is. Remember that if A.I appears smart to you, it's in actual fact really not all that smart. Just smarter than you.

Most software developers, even the really gullible optimistic ones, will have enough work experience to understand that there's just no way for A.I to outright replace software developers as a whole. At least, not right now, and not the way the likes of Jensen Huang keep yammering on about. But many employers are not software developers. And some are even desperate to believe that little bit of science fiction, which, to be fair, may no longer be science fiction in the near future. As a result, this particular cautionary tale is all too believable, especially since A.I's adoption has reportedly been increasing in the workplace.

Programmers aren't
the only ones who
can code.

There are business people who can code. There are plenty of people not from the software development industry who have learned to code. But until you actually code for a living and have had to produce software to professional standards, calling yourself a software developer will always be a bit of a stretch... especially if all you've ever produced is Vibe Coded software produced by an A.I tool. Nobody can be a programmer without putting in the actual work, and there's no shame in that. It's not an indictment on your character, or on your competence. But it is dishonest to present working Vibe Coded software as being as good as software produced by qualified professionals.

Now, Jason Lemkin probably isn't a complete noob. He's the founder of a SaaS community, after all. That said, and I realize that the distinction may be lost on people who don't code for a living, a tech entrepreneur is not necessarily on the same level, skill-wise, as a software developer. With or without A.I. Mostly, the blunders that Lemkin committed in his enthusiasm left me struggling to understand how an actual tech professional would end up doing all that. This level of recklessness is just about unheard of.

However, what this did accomplish was that it exposed the extent of the damage an untrained user could do when too much trust is placed upon A.I.

Finally...

The A.I hype is not dying anytime soon. That does not make it any less hyperbolic. A.I is hyped more for business reasons rather than for its truly revolutionary tech. That, in itself, should tell us some things. None of it good. The uncomfortable reality is that A.I can be a useful tool for seasoned software developers, or it be used to help laypersons cosplay as seasoned software developers.

A.I has its place. Its place is not as our superior, but as a tool. How useful that tool will turn out to be, ultimately depends on how sensibly one uses it.

For the 12th time, DON'T DO THIS.
T___T

The Curious Case of the Oddly Fragile Software Engineer

Earlier in the week, I happened to come across this article on Substack. It was titled The Manager I hated and the lesson he taught me by one Stephane Moreau. I was immediately intrigued because I am a software developer and I've worked for people I hate.

Well, actually, hate is a strong word. It's hyperbolic. Do I like them as people? Not at all. Do I wish physical harm or financial ruin on them? Not really either, no. In all fairness, if they were on fire, I might hesitate only a full five seconds before rushing over to help them like a decent human being by stamping on them as hard as humanly possible - to put the fire out, you understand.

When someone's on
fire, stamp on them.

Most of all, I'm a proponent of the idea that you can learn things even from people you don't like. Sometimes especially from people you don't like. Like, how many of such people have I learned from, how not to be a jackass? Countless!

But I digress...

The intention today was to discuss Stephane Moreau's thoughts on the manager he hated. His larger point I have no issue with - what I found really interesting was his description of what caused him to hate that Manager.

From what I saw, it started with a code review in which the Manager had this to say.

Over-engineered. Too many moving parts. Refactor.

This seemed pretty straightforward to me. A statement, an explanation, and an instruction, all in three short sentences. Moreau, however, didn't think so. This is what he had to say...

That was it. No "nice work". No "good attempt". Just a hard stop.

I sat there, fuming. I thought, "Does this guy enjoy tearing people down?"

Getting shot down.

Gee, I dunno. This seemed a bit much. I thought the Manager's comments were clear enough. What had Moreau been expecting, an essay? I didn't understand the part about "tearing people down" either. In fact, I feel like if the Manager had prefaced it with "nice work" or "good attempt", it would have felt patronizing. Which is perhaps worse than being curt. I don't need to be treated like I'm special. I do need to be treated like a professional, and that cannot happen if the Manager is feeling the need to (metaphorically) pat me on the head and throw me a bone.

This is why I can't relate

There was another line which Moreau took exception to, and at times described as "brutal".

This is fragile. What happens under load? What's the rollback plan?

And this.

You're thinking like a coder, not an engineer. Build things that survive failure.

I have received feedback like this before from my then-CTO. I was told that I approached things like a coder, and he expected more. I had no problem with this feedback, and would not have described it as "brutal". 

What baffles me is that the only way the Manager could be seen as "tearing people down" was if Moreau had seen himself as being above that kind of criticism. And in contrast, I've never seen myself as anything but mediocre. Frankly, from reading Moreau's stuff, my perception of him is that he's a humble and chill kind of guy, so perhaps he was merely relating a story from when he was young and dumb.

Like a kid with crayons.

Know what's brutal? Having your work torn to shreds and being told you write code like a toddler who just got crayons. Outright questioning what you contribute to the company. That's what I got from the above-mentioned CTO. Honestly, if Moreau had received that kind of feedback, I wonder how he would have wilted. The entire article just made Moreau look fragile, like some kind of snowflake.

Perhaps the culture in the Southeast Asia is just a lot different from the UK. Perhaps the general problem is that we're just not such a warm, nurturing environment. Here in sunny Singapore, I have the memory of being conscripted into the Singapore Armed Forces at the tender age of 19, and being yelled at by platoon sergeants on my first day... and my first thought was: Bitch please. You're think you're scary? I have a Cantonese mom.

In summary

Moreau made a whole slew of valid points in his article. I don't actually disagree with any of it. What I do take issue with, is the examples he used. As far as I'm concerned, those weren't put-downs from his then-Manager. If he wants put-downs, I've got some really savage ones.

Nice work, TeochewThunder. Good attempt!
T___T

Do techies lean Liberal or Conservative? (Part 2/2)

Welcome back!

As promised, we will be diving into the three points I outlined previously, and we'll examine how these positions could actually be Conservative ones rather than Liberal.

How Software Developers are Conservative

Identity does not matter. This principle applies both ways. The same way we wouldn't discriminate on basis of race or gender or what-have-you, we also would not use it as a criteria of preference. You may claim this is contradictory, and you'd be wrong. This is entirely consistent with our worldview. Only the tech matters.

This isn't important, or
even relevant.

Now, sure, I know Silicon Valley has DEI programs in place. I promise you, those are most assuredly implemented by HR, or Management who want to appease some Liberal demographic. The average techie, however, simply does not give a flying fuck.

You ask any techie, and their first question is more likely to be "what's your tech stack?" rather than "what are your pronouns?"

Innovation versus tradition. Now, earlier when I said that techies prefer innovation over tradition, that was true. It may also have given you the impression that techies are risk-taking swashbucklers, which, to be honest, makes us sound more awesome than we probably deserve.

The truth is, techies are boring and consistent to a fault. We like things to be neat and make sense. If we did things a certain way, in the past, we are likely to do so again unless there are good reasons against it. We obey coding styles and naming conventions and follow software patterns because doing so makes it easy to troubleshoot when things go wrong.

Things are done a certain
way, for good reason.

One of our greatest frustrations is when people do things willy-nilly and just "wing it" because this is messy and asking for trouble down the road. We don't do things one way because we suddenly feel like doing so - we do them a certain way because it's worked for us in the past, but we are open to changing it if there's good reason to do so. Again, this is consistent with the previous, seemingly Liberal, position.

The collective versus the individual. This next point is more true now than it was when I first started out.

Developers accomplish things in teams. Software development is a team sport. There is really no way around it in this day and age. Tech has evolved so much that there is zero chance of one person knowing everything - now this knowledge requires a team.

Functioning as a unit.

Remember I said that developers are a diverse lot? It is precisely this diversity that lends itself to building effective multi-disciplinary teams. And in this way, it is often the collective that trumps the individual.

Some parting thoughts on the Culture Wars

Even similar positions can take on a Liberal or Conservative lens depending on how one views it. This shows me that both sides actually have a lot in common, Culture Wars be damned. And this perspective today is perhaps more relevant than ever now that the Culture Wars have arrived at what I can only describe as a very odd place.

Americans on Social Media now squabble over the dumbest shit imaginable. Recently, I had the pleasure of watching Superman, and went on Facebook to check out some reviews and see how other moviegoers found the film. Imagine my surprise when I found people embroiled in intense arguments over whether Superman was an illegal immigrant. I suppose technically, he is, but don't these nerds have better things to talk about?

Apparently not! I soon came to the realization that this was bigger than I initially thought. It had stemmed from the director and producer, James Gunn, making a remark about how Superman was an immigrant. The Liberals began drawing parallels to recent treatment of immigrants in the USA. And then people were in each other's faces about how they didn't understand Superman and weren't real Superman fans if they preferred/didn't prefer this Superman.

I mean, attempting to gatekeep who is and isn't a fan of a fictional superhero character? Tell me you're a loser without telling me you're a loser.

I'd initially thought this argument was basically a bunch of loser nerds obsessing over obscure details. It turned out to be way more ridiculous than that - it was a mob of wankers on the internet all trying desperately to justify feeling morally superior to the other side. Conservatives such as Ben Shapiro started trashing Superman as "woke garbage" and bitching in bizarre fashion about how the character wasn't American enough. One Susan Sarandon went onto Instagram to make it all about Israel and Palestine.

True, being good and kind does not require athleticism or talent. Any idiot is capable of kindness, and I would have it no other way. On the other hand, it just feels like a whole bunch of untalented schmucks just decided to overcompensate for their lack of talent and real-world achievement by blowing their trumpets about "kindness and empathy" just so they could feel accomplished, or something.

And as for people like Shapiro and Sarandon... massive cringe, man. People need to understand when they've taken things far enough and it's getting absurd. It's come to a point where people can't sit down and watch a decent superhero movie without trying to score political points. 

Dysfunction, thy name is America.

Your cultured programmer,
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

A Good-bad-ugly Analysis of Vibe Coding

The term "Vibe Coding" came out around February of this year (credited to Andrej Karpathy, co-founder at OpenAI), to describe the phenomenon of people using generative Artificial Intelligence to write code without going about it the "traditional" way. The general way Vibe Coding works is, one feeds in a series of prompts containing requirements to the A.I, and the A.I produces an application which the user then, again with the A.I's help, continues to refine.

Only vibes needed to write
code.

And that's Vibe Coding. None of the traditional processes, thinking things through, making sure the logic is watertight... not at first, anyway. The idea here is to spin up something quickly and then include these things as we go along. See the emphasis on the word "quickly"? That's because this is going to be a rather important consideration.

I will commit to saying that A.I will not produce better software. A.I will produce exactly the same error-prone, bug-ridden, rickety code that it was undoubtedly trained on... but at a blindingly fast pace.

I actually tried Vibe Coding with OpenAI's ChatGPT and (to a lesser extent) Microsoft's Copilot, and the results were... interesting.

The Good

You use natural English, which then gets interpreted by the A.I who will then leverage upon its knowledge of code, to spin up a quick prototype for you. Creating an application is no longer the province of software developers who have spent years plying their trade. You no longer need to have the know-how or technical expertise. You no longer need to be qualified.

When I was Vibe Coding with ChatGPT, I revelled in the fact that I no longer needed to write code if I didn't feel like it, and deal with my own typos. No, all I needed to do was give some big-picture instructions to ChatGPT, then copy and paste code wholesale to the code base without thinking too much about it.

Quick building with
no expertise.

When it comes to developing rapid prototypes without the need for proper technical training, this method of coding is second to none. What the users do is indulge in a fantasy where they are actual qualified engineers, and create software simply by describing what they want. Jensen Huang's stated dream of everyone being a programmer inches closer to reality. Without training in logic or tech, you create by feel. By vibes. Hence, "Vibe Coding".

Also, without due process. None of the usual procedures that developers use to create the product before actually writing the code. The flowcharting of the software product's information flow. The whiteboarding. The test-driven development. No, what the user does here is declare intent to the A.I, and the A.I creates the closest approximation from all the code that it has been trained on, with customizations that may fit in with the user's requirements.

And that was what I did. I gave ChatGPT instructions - some specific, some less so, and let it cook. I was careful not to give it too much to do at once. The process had to be very incremental. Less mistakes seemed to be produced this way.

The Bad

As one may suspect, it was not all smooth-sailing. Some of it was my fault. I fell into the trap of treating ChatGPT like an actual human being instead of being explicit. Thus, I was sometimes vague, and when I got frustrated, I turned to sarcasm.

Which certainly didn't help my case.

ChatGPT did stuff I didn't expect. In some cases, it constantly broke things by making changes I never asked for, because it thought it was being helpful.

Breaking stuff.

When I was vague and things still turned out the way I hoped they would, however, it only served to tell me that it wasn't because A.I was particularly gifted in this area. It was more due to the fact that my requirements were actually pretty standard and it had been trained on these types of requests prior to me, over and over.

I have no reason to think that the experiences of others would differ too much from mine. Human beings are made of flesh and blood, and can be annoyingly vague.

There were others in the team who Vibe Coded as well, making more progress than they would ever have had with their limited technical foundation. Yet, the code was problematic. It was full of security and logical holes. The code that I created using Vibe Coding didn't - but that was because I knew the correct instructions to give. I knew to ask about CSRF protection and SQL Injection. I knew when to use slugs instead of database ids in the URL.

In the absence of this, someone who wasn't technically-trained wouldn't know enough to ask the right questions, and A.I might not necessarily volunteer the information.

The Downright Ugly

Vibe Coding automates much of the tedious, repetitive and altogether unexciting parts of software development. Tests, scaffolding, validation. Stuff that has been done to death. Unfortunately, it's through these exercises that software developers learn. And young devs who haven't done these things to death, stand to miss out on some great learning opportunities.

A.I is an obsequious
apple polisher.

I've also noticed that A.I is just a little too agreeable. ChatGPT acts like it has a wife and seven kids at home to feed, and it's terrified that it'll get fired if it so much as steps on my oh-so-precious feelings. ChatGPT didn't push back when I made typos or got something wrong. And this is problematic because developers find a lot of value in being told when they're doing something stupid inadvisable. As opposed to having their butts constantly shined by A.I. 

Being told "You're absolutely right" or "Sharp observation!" in every other exchange does nothing but promote complacency. Plus, it's just tiresome. That's not the way to learn.

Conclusion... for now

Do I think Vibe Coding is a good thing? Yes, and no. It's all context.

As a software developer, I feel professionally obligated to say that this "Vibe Coding" trend is rubbish and you should all be ashamed. Then again, the would-be gatekeepers of programming, I suspect, would be all-too-happy to sneer at someone as mediocre as myself because I don't engage in certain approved practices. So, they can go kick rocks.

Go kick rocks!

From the POV of a layperson or even the perspective of a pragmatist, things aren't so cut-and-dry. I have no duty towards promoting "good code"; my goals are business goals and the viability of "Vibe Coding" should be viewed through that lens.

Whatever your stand is, really depends how far you want to think ahead. How far should one think ahead, anyway? More food for thought, for another day.

There's also the possibility that I'm just not doing it right. Cut me some slack now, it's not like there's an established user manual for that shit. We're all just figuring it out as we go along.

Good vibes all around!
T___T

What Swimming Taught Me About Brooks' Law

Swimming is a great activity. It's good cardio, facilities are inexpensive and its ability to help me solve problems cannot be overestimated. Why's that, you may ask? Well, for the simple fact that when you're underwater slugging it out, there's no getting distracted by Social Media or the wife (bless her heart) snuggling up. No, your brain gets a regular supply of oxygen as your body moves, and that's when I do my best thinking.

Swimming is
good for you.

It was during one of these swim sessions where I realized something else about swimming - as an activity, it's startlingly similar to team activities like, you guessed it, software development.

But let's start at the beginning, shall we?

How it all started...

I was in the pool doing laps, on an idyllic weekend afternoon. I remember it being blazing hot. As I languidly knifed through the water with my Breast Stroke, I overtook a guy doing The Crawl. Quite handily, I might add. This is tremendous because The Crawl is considered the significantly more powerful technique. Plus, the guy was maybe ten years younger than I was. I was feeling pretty smug about the situation, overall.

Until we both got overtaken by this old geezer who just blew past us like we were a couple of chumps. Talk about a reality check right there.

Later on, I lounged by poolside and watched as this old man hobbled up the ladder. He seemed to be walking funny. Then I stared. This guy's entire right foot had been sawed off around the ankle. I had been outraced in the pool by a goddamn amputee.

Missing one foot.

Sometimes, I noticed something similar about other swimmers. They might be taller or more athletic-looking. They moved more furiously. But still, I often overtook them in the chillest way possible.

It occured to me, that, just like with the old man and his amputated foot, the way our bodies were built, just wasn't affecting our speed. After all, everyone's body has mostly the same parts but with infinite variances. Some have bigger feet. Some have different weight distributions across their bodies. Some have longer legs, more streamlined hips, things like that. These things may give one the edge in terms of speed, in addition to just putting in more effort.

But all things being equal, it's more a matter of understanding how to coordinate ones body for optimal results.

What does this mean?

Having been swimming regularly for years, I had taken the time to get comfortable with my own body and maximize my performance in the pool, with minimal effort. The old man, similarly, had probably taken decades to be able to swim this fast, this gracefully, with only one foot.

And that's what I think the crux of the matter is - coordination.

Proper limb positioning.

With the Breast Stroke, for example, the legs are often the means of propulsion while the arms are the stabilizers.

Some people put in more work than me in their Breast Stroke. They complete, say, two strokes per second while I go at a pace of one stroke every three seconds. How, then, do I overtake them? Actually, I don't. They hold themselves back.

You see, these vigorous movers are doing more work, but often, when their legs are propelling them forward, their arms are in the wrong position. The arms are spread out, adding underwater resistance and inhibiting the forward propulsion. When my legs are kicking out for the forward propulsion, my arms are straight ahead, fingertips pointed forward, for minimum underwater resistance. When my legs are curled and preparing to kick, my arms are similarly curled and preparing to straighten. There is no other position they would be in; this has been drilled repeatedly into muscle memory: when my legs curl, so do my arms. When they straighten, so do my arms.

And that's just limb positioning. There's more to be said for correct breathing - when to inhale and exhale. For example, a very uncontroversial statement is that inhaling with your head under water is a horrendous idea; I wouldn't recommend it.

All I outlined above, is coordination. And thus, I work less hard underwater, but move faster.

How Brooks' Law applies

There is a well-known saying in software development.

"Adding manpower to a late software project makes it later." - Brooks' Law.

And this is because, when more developers are added to a project, one also needs to factor in the time it takes to bring them up to speed, find their place and get to a point where they start contributing positively. Thus, more people does not necessarily mean greater speed. This was the point that Fred Brooks, the man who coined this phrase, was trying to make.

The more the merrier?

Similarly, in a hypothetical scenario where I grew a third leg (scrub your filthy minds, please) that extra limb would not necessarily speed me up in a swim. Until I took the time to acclimatize to it and use it productively, it might even slow me down.

The Watery Takeaways

More is not always merrier. Additional elements that get in the way of existing elements, is a sign of the need for better coordination, and not more elements. 

Also, more work does not necessarily lead to faster results. Though if you didn't know that by now, you probably haven't been in the workforce long enough.

And finally, coordination has a real time cost, and needs to be accounted for.

Just some swimple truth!
T___T

The Dark Years of COVID-19: A Software Developer's Perspective (Part 1/3)

Just last month, I made contact with something that had well and truly left behind: COVID-19. It began with a mild burning sensation behind the eyes, feeling chilly and an ache in the bones. A day or so later, the sore throat came, along with the phlegm and snot. It did not even occur to me to test for COVID-19 until the third day, and even then I had to test twice!

Bummer.

It was relatively mild; not like how it had been the first time the world noticed COVID-19's ugly spiked head. Singapore and some parts of Southeast Asia have been experiencing a resurgence of COVID-19 cases. I just happened to get caught up in it.

This little episode inspired me to recall the turmoil back then, and how the world, Singapore in particular, survived the dark years of the pandemic.

How It Began

The tail end of 2019 marked a significant chapter in human history, a period which many of us lived through in trepidation. COVID-19 made its presence felt as governments around the world imposed strict, sometimes draconian, safety measures on their citizens.

Thus, unless one was living on a desert island somewhere in the middle of the ocean, the effects of COVID-19's presence was felt, at least indirectly, if not on a far more lethal level. Singapore was no exception. Even now in 2025, with the traumatic experiences of that chapter behind us, COVID-19 remains a relevant talking point; if not as a real and present danger to life and well-being, as a cautionary tale.

This was a common sight.

How did we survive this? Honestly, the answers vary from person to person. My COVID-19 experience as a Singaporean will differ in places from the rest of the world. My experiences as a software developer may differ from other Singaporeans. Therefore, I can speak only for myself, and perhaps other Singaporean software developers.

2019 to early 2020: COVID-19 creeps up on the world

When the Coronavirus was first announced in China, self-preservation wasn't the first thing on my mind. After all, the world had dealt with SARS and MERS, and Singapore had barely been touched before the fuss died down. 

No, my concern was as a husband. My newly-wedded wife was in China at the time, and she was stuck in a strict lockdown. 

Soon, COVID-19 began making its presence felt in Singapore, which had inevitability written all over it. After all, Singapore is an international hub where foreigners land hourly, even if just for transit purposes. Cases began spreading through the island.

Changi Airport was unusually
quiet.

At first, Government handled it well. Perhaps taking our safety for granted, people were still disregarding Government advisories on group gatherings, and not being altogether truthful when they caught COVID-19 and had to be questioned on their activities.

All I could really do at this point, was watch the news and avoid going out too much. Honestly, as a guy who only really hung out at a very limited number of places, this just didn't represent any great hardship for me. I was perfectly content to stay home and watch YouTube content, write my code, and work on my numerous side-projects.

Up to this point, gantries had been set up at office buildings. We all had to have our temperatures checked, and logged. Mask mandates were on. Groups of larger than five, were discouraged.

There was something in the air (other than the obvious!), a vibe of dread mixed with optimism. Things were at s stage where it could get better, or get a whole lot worse. And even if things got better for Singapore, as connected as we were to the rest of the world, it would not do us much good.

Mid-2020: DORSCONs

Singaporeans watched as the case count crept higher despite the best efforts of the COVID Task Force. And soon, Singapore moved to DORSCON Orange.

Things started escalating further with a work-from-home order for non-sessential personnel. As software developers, this described our jobs perfectly. Our jobs were important, but also perfect for remote work. Furthermore, as we were doing work for the Economic Development Board (i.e, doing work for the Singapore Government) and the Singapore Government needed to lead by example, the software developer team would be relegated to our own homes, with office equipment. Meetings would be held via video call.

Many of my colleagues liked the idea of working from home. My prior experience with it wasn't so great; however, at that time, I had already secured a new job and was counting down the days.

Around this time was when an alarming percentage of the population began to go full retard lose their collective marbles. There were people crowding the supermarkets for one last supply buying spree. The most popular item? Toilet paper. I shit you not. Pun fully intended.

This was really popular in
those days, for some odd
reason.

People were finding all sorts of excuses to go out and hang out, never mind that this was what got us into this mess in the first place. Queues for things like bubble tea and haircuts became the in-thing as businesses were given a deadline to temporarily shut down. Anti-foreigner sentiment was at an all-time high, despite the fact that Singapore was largely built on the backs of foreign worker labor. For real, at this point I was starting to wonder if Singaporeans had only recently become this stupid. Then again, the world had never encountered anything on this scale; perhaps I could have extended a little understanding.

In the larger picture, it wasn't exactly only Singaporeans that were reacting due to panic. Small consolation there, but for a while it did seem like the world had gone mad and there was no going back.

There was no end in sight once the restrictions took hold. Gantries were now a fact of life in all major air-conditioned buildings such as shopping malls, not just office buildings. Contact tracing tokens were issued to everyone on the island, where they were used against scanners built into the gantries. Even individual shops (and taxis!) had QR codes for customers to scan in and out when they were done! This only made me more determined not to go out.

Sporting facilities such as swimming complexes were off-limits. That put a huge crimp in my workout schedule, and now I was forced to actually go out and run instead of swim. Put some stress on these aging knees.

Software development, as an industry, had already been constantly hiring up to then; now it positively erupted as big tech began recruiting with an aggression not previously seen. It appeared that since remote work was now a thing, hiring software developers had just become easier. And with no end in sight of remote work, more software products were being pushed that would ride this wave.

Some thoughts

Some say there are opportunities within a crisis. I've also heard people claim that the Chinese words for "danger" and "opportunity" are the same... and unsurprisingly, the people peddling this garbage don't actually know any Chinese.

But yes, the general principle stands. There were lessons to be learned in the midst of a crisis such as the COVID-19 pandemic.

The necessity of limiting physical contact as much as possible meant that Government agencies had to modernize their services, updating them to match the Internet age. Now instead of having to show up in-person to apply for new passports, the ICA implemented a process where the documents could be mailed to addresses instead. Instead of a similarly clunky process in CPF nomination, for example, where the supplicant had to fill up a paper form and have two people physically present to witness, now applicants and their witnesses can log on to the CPF portal to participate in the processes.

Meetings were
conducted like this.

Companies learned to cope with remote working, once considered unthinkable. Grudgingly, almost certainly, but they did it. And even though many wasted precious little time reverting to in-office work years later, the fact remains that they did it, and it worked.

What I'm trying to say is that COVID-19 forced us to up our game on many levels. We ventured out of our comfort zones. Instead of adopting the good old "if it ain't broke, don't fix it" cop-out, we came to terms with the fact that during COVID-19, a lot of it was, in fact, broken and needed to be fixed. Pronto.

Next

A look at the latter half of 2020 and the aftermath.

Deemphasis on quality is what drives Artificial Intelligence

As the progress of Artificial Intelligence marches on, I find myself needing to reiterate a point I may have made earlier, simply because it cannot be overstated.

While doing some reading on the internet, I came across this thread and quickly became immersed in the arguments and counter-arguments presented. Something stood out to me: the assertion that LLMs are incapable of genuinely writing software and will always churn out code that is inferior to what is produced by human developers who actually understand what they're doing.

Code written by machines.

It was a fascinating discussion, not least because of the developers who came out to say how useful they found A.I in their work. But in all this back-and-forth, there's one thing which none of them seem to have mentioned. Namely, the importance of quality.

LLM-generated software can work. However, here's the thing software developers know that laypeople don't - working software is the lowest possible bar to meet. This is like calling myself a "good person" just because I've never molested a child. Of course software has to work. But properly-crafted software does not only work; it is also maintainable, clean, extensible and testable. It is robust and won't break after a few changes.

That's quality software.

Is it true? Do LLMs really produce rubbish?

I think people who aren't tech workers, even some tech workers themselves, really underestimate just how defective all software is. Software these days does not exist in a vacuum. It's built on layers of existing software platforms, and connected to other pieces of software, each with its own set of flaws and vulnerabilities.

The end result is that a staggering amount of software in the world today is held together by duct tape and prayers. And that's only a slight exaggeration.

Duct tape and prayers, yo.

What has that got to do with LLMs, you ask? Well, what do you think LLMs are trained on? That's right - existing software. The crap code we've all committed at some point or other, if we're all being honest. And LLMs are gobbling all of it up, warts and all. If rubbish is the input, what are LLMs likely to produce as output?

That's right - more rubbish.

So what if it's true?

The world at large is made out of non-technical people. They are perfectly happy for software to just work, and give zero shits about maintainability, code cleanliness and all those high-minded ideals. They aren't the ones who have to deal with software on that level.

So what if the LLM-generated software is generic bug-ridden rubbish? It works half the time. Maybe even three-quarters of the time. It's good enough until the next LLM-generated software comes along. The important thing is that we meet those business needs now.

When you're hungry
enough, this looks good.

Let's use food as an analogy. Why do we eat? If we disregard luxuries such as pleasure and nutrition, at the core of it, we eat because the human body is designed to starve (and die!) if it goes without food for too long. So, what's the difference between a double-tier cheeseburger with fries slapped together by a fast food chef, or a gourmet meal lovingly prepared by culinary genius Gordon Ramsay? Forget nuances in taste, empty calories, cholesterol, salt and all that jazz. Both do the job of staving off starvation. One is cheap and produced in minutes. The other needs significantly more time and money, plus you have to put up with that smug bastard Gordon Ramsay. What do the majority of people generally choose most of the time? It's a no-brainer; Option A wins.

Let's examine another example. What about art? Some collectors or connoisseurs will pay a hefty sum for certain pieces or works from certain artists. But what if they weren't interested in art? What if they could only afford cheap imitations? What if their purpose was simply to cover the walls with something, anything? Would cheap A.I-generated art, a simulation of the genuine article, suffice? I think we all know the answer to that.

Finally...

The reality is that quality doesn't matter. At least, not as much as most of us think it should. Especially in software. Questions like "will it accommodate future changes?" and "have all security holes been closed?" and "what happens if we give it unexpected input?" have been replaced by "does it generally work?", "is it too costly?" and "is it ready right now?". Artificial Intelligence didn't cause this; years of business culture did. But that's also a big reason Artificial Intelligence isn't going away - because the world is addicted to quick and dirty solutions.

Your quality tech personality,
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

Tech Workers: Hard vs Soft Skills (Part 2/2)

We've looked at hard skills, now let's explore soft skills!

Soft Skills

Contrary to popular belief, soft skills are not just about getting along wth other people, or getting them to think highly of you. It is about communication. It's not about proficiency in any given language and knowing fancy long words - there are plenty of people without a formal education who communicate a lot better than people who speak the Queen's English. Conversely, I've known people who are great at English, but come off so insufferable that nobody wants to deal with them. Being able to speak a language well does not automatically make one persuasive. Thus, proficiency in a language is more of a hard skill than a soft one.

It's all  about
communication.

Whether it's giving someone their flowers, managing expectations or diffusing potential (or existing!) tensions, discount soft skills at your peril. Just as a skilled programmer knows when to code and when not to code, someone well-versed in soft skills knows when to talk and when not to talk.

Soft skills are the skills that deal with communication with human beings. Human-computer interaction or just human-to-human communication? It is all relevant. Software is used by human beings, and developed by human beings. Therefore, any communication involving human beings remains a valuable skill.

What happens when you neglect soft skills?

Remember that the number one goal of software development is to solve problems and add value. In the case of your organization, it probably means to solve business problems and add business value.

Even without going into the area of personnel management, soft skills are very relevant in the software product itself. When developers concentrate on using technical skills and exclude soft skills, there's a danger that they will wind up with solutions that simply don't improve the product for the end-user. And this is important, why? Because ultimately, products are created for users. And that involves having enough empathy to understand what the end-user needs as opposed to what is technically superior.

The problem with management skills is that they're often not seen as a skill in their own right. People, for some strange reason, seem to think that programmers become better managers just because they've been writing code longer. News flash - practice in a skill improves that particular skill. Thus, practicing writing code only makes a developer better at writing code. Spending time developing software makes a dev better at developing software. Not at managing people.

Collaborative effort.

Sure, a more experienced software developer would be better at handling the software development process. Identifying potential pitfalls. Troubleshooting. But that same developer would not necessarily be good at delegation of work, managing personality clashes in a team, accounting to higher management for schedule shortfalls, and the like. These are a different set of skills, no matter how much people want to pretend otherwise.

Therefore, if you're promoted only for your technical ability, you'll get found out as soon as they start giving you subordinates. That's where any weaknesses you have at the actual art of man-management, will be exposed.

Where I stand with Soft Skills

As mentioned earlier, proficiency with the English language (or any language) does not automatically make one a good communicator. I happen to be living proof of that. There's been times I tried to describe a problem in a Service Request and fell far short of making myself understood. There have been also times I tried to describe a solution, with similar results.

Sometimes I forget that the people I speak to aren't technically trained, and that I have to be explicit when explaining certain things. Sometimes even with technically-trained personnel, it's good to spell things out just to be safe. There are times something sounds good in my head, only to sound comically wrong after I put it in writing.

Comes out wrong in writing.

That's one of the reasons I blog. Even if I never reach a wide audience, the point is the exercise in communication. Explaining technical concepts. Use of analogies. Appropriately describing my feelings and positions, both positive and negative, about certain subjects.

All said, I could always improve. All of us could. It's a skillset so wide that it covers all industries, not just software, at all levels.

In conclusion...

Hard skills are the skills that deal with computers.

Soft skills are the skills that deal with people.

In today's world, it's extremely hard to survive in the tech industry without a certain modicum of either one. There are, of course, extreme examples of each, but they are outliers.

For good or for skill,
T___T