A Software Developer's Vacation in... Singapore (Part 2/3)

The next part of my little vacation in Singapore was spent revisiting offices I worked in from 2009, up to a few years after. I was at the stage where I was finding my feet as a web developer, and struggling to break through that SGD 3,000 monthly wage ceiling.

2009

It was a weird point in my career, as my company in Middle Road moved operations to a little basement office in Holiday Inn Singapore Atrium, around Havelock Road. I remember spending countless nights in the office slaving away writing code. The air-conditioning was on twenty-four hours a day, it being a hotel and all. When I went back to visit it during my leave, that office had been replaced by some nightclub. Beside it, you can see the stairs I used to descend from the lobby to the office.

Holiday Inn
Singapore Atrium

My old office, now a nightclub.

Concorde Shopping Center

Wandering around the basement led me to Concorde Shopping Center. The provision shop I used to frequent was gone. Around it were suspicious-looking women in individual shops badgering me to go in for a "massage". One of them even pulled open her labcoat and flashed me. Ten years ago, I probably would have found this interesting. Now it was just... weird AF.

Zion Road

Great World City

There would be nights when I wandered the area aimlessly to take a break from the screen. During those times, I would go as far as Great World City, which was this huge-ass mall up along Zion Road. Now, I rarely actually went inside, as it was usually closed by the time I passed by. It was significantly more convenient to get there now, since the Havelock and Great World MRT stations are currently in existence.

Zion Riverside Food Center

Singapore River

No, the place I actually hung out at more often wasn't Great World City, but the block of shops just across the road. There was Zion Riverside Food Center (it may not have been called that at the time) and some bars, just by the Singapore River.

In fact, when I visited during my vacation, it struck me that this was the first time I'd seen the Singapore  River from this exact vantage point during the day. Amazing.

2010 to 2011

At that point, I had spent most of my career in the general vicinity of Bugis Street. This was soon to change as I landed a job further up, to the other, less glamorous, end of Beach Road. It wasn't that far away, but the vibes were markedly different. This was the year I spent in Golden Mile Complex, which was under reconstruction works when I visited it recently.

Golden Mile Complex

It was just a year, but what a year. I pulled twelve-hour days as was my wont. I saw things like barfights, sexual predators in toilets and the sordid nightlife that characterized life in Golden Mile Complex, colloquially known as Little Thailand. After sundown, Golden Mile Complex just turned into a completely different animal.

Golden Mile Complex, Golden Mile Tower and Golden Mile Food Center formed what I liked to call "the Golden Triangle".

Beach Road, again.

Golden Mile Food Center

Golden Mile Tower

Golden Mile Tower was further up Beach Road, and Golden Mile Food Center was on the other side of the road, housing the Beach Road Army Market. Shopping there is a habit I picked up from National Service, one that I never quite managed to break. Working nearby in Golden Mile certainly didn't help! The shops were still there when I visited. The food looked largely the same. Ah, nostalgia.

Nearby were the ultra-retro complexes known as Jalan Sultan Textile Center and Sultan Plaza.
Behind Sultan Plaza, was a little playground where I spent several evenings with my then-girlfriend, or drinking in seedy bars with my buddies. There were a ton of them in these parts. I've gone almost completely dry in the intervening years, but it was still fun to reminisce.

Sultan Plaza

Playground behind
Sultan Plaza

And then there was the Textile Center, the sister to the ancient creaking Sultan Plaza.

Jalan Sultan
Textile Center

Special little park behind
the Textile Center.

This little park behind the Textile Center may look like just like any other, but it holds special meaning for me. In 2017 or so, when I could finally afford to take another then-girlfriend (who's now Mrs TeochewThunder) out somewhere nice, it was to the classic Nan Hua Chang Fish Head Steamboat Restaurant just a street away, and we came here for a post-meal snuggle later.

I know, this makes it sound like I really got around, but it was just those two ladies. Around these parts, anyway.

Next

An exploration of offices from 2011 onward.

More ways to declare colors in CSS!

Color codes used to be simple. If I ignored HSV and CMYK, RGB values were perfectly adequate. For more than a decade, I used rgb() and rgba() in CSS to get colors I wanted. This changed recently when I came across some new ways of using the rgb() function, quite by accident.

Fun with colors!

It began when I was doing this, using rgb() instead of rgba(). Obviously I wasn't using "HELLO WORLD" but this is the least complicated example I can think of.

<h1 style="color:rgb(200, 100, 50, 0.5)">HELLO WORLD</h1>

And it actually worked. That pale shade of orange!

HELLO WORLD

So I did a little bit of research into the rgb() function and it turned up a lot of stuff. Apparently this syntax is legacy, which means it's been around forever! 

But now that I was going down this rabbit hole, it appeared that there were other ways to use the rgb() function.

Without commas

rgb() can also be used without commas and with a forward slash if you want to specify opacity. Which sounds really counterintuitive, I know. Apparently some people find this easier. Go figure.

<h1 style="color:rgb(200 100 50 / 0.8)">HELLO WORLD</h1>

See? I upped the opacity.

HELLO WORLD

Using percentages

This is where it gets interesting. Instead of a value from 0 to 255, we can just quit the mental gymnastics and use percentage values. So if I do this...

<h1 style="color:rgb(80%, 50%, 0%, 90%)">HELLO WORLD</h1>

...or this...

<h1 style="color:rgb(80% 50% 0% / 90%)">HELLO WORLD</h1>

...I get this! Even more opacity!

HELLO WORLD

How is any of this useful?

It's really up to the individual web developer, isn't it? I personally prefer using commas, but being able to use percentage values is really cool.

The amazing thing is that this was all in place way before I discovered it, quite by accident. Truly, you learn something every day.

Well, color me flabbergasted!
T___T

Five Image File Formats For The Web

There are a variety of image file formats used on the internet. Some of them have been around for a very long time; others not so much. They come in various levels of utility and relevance to the web landscape. Understanding image file formats is arguably more of a design discipline than it is a tech discipline; nevertheless, it's web development know-how and useful for web developers worth their salt, to at least understand the basics.

Since we're only talking about images used for the web, we won't be discussing TIFFs (huge files used by photographers) or Bitmaps.

1. JPEG (.jpg or .jpeg)

The acronym stands for Joint Photographic Experts Group. This is a file format that has been around for almost as long as the internet has been alive. It is still extremely relevant today, though its place is very much under threat from WebP.

PNG (left), JPEG (right); for
the JPEG, logo is blurred
around the edges.

JPEGs are useful because they use a lossy compression format. This means that part of the color information will be lost when compressed, but that's OK because the parts that are lost are generally not the parts perceptible by human eyes. Thus the compression would have to be significantly lower than the original before one can perceive any degradation in quality. And that, in turn, means that file sizes can get significantly smaller.

Thus, especially for small to medium photographic images, JPEGs were (and in many ways, still are) the numero uno choice in the pre-broadband era of internet. Ever tried to access an online photo gallery on a 54kbps modem? It would be an absolute nightmare if low quality JPEG thumbnails weren't used. The economical file sizes were economical for those times, though this may be less of an issue today, now that internet speeds are streaming quality.

Its one weakness is noticeable image degradation in images with flat colors and sharp distinct edges.

Use it for: Photographic images where quality is negotiable.
Don't use it for: Images with flat colors such as simple illustrations and logos.

2. GIF (.gif)

This can be pronounced with a hard or soft "g". I personally think it should be pronounced with a hard sound because the "g" stands for "Graphic", as in Graphical Interchange Format.

This is a lossless compression format, though you would be sadly mistaken if you thought this meant there would be little to no image degradation. The image degradation occurs due to the conversion from a full color palette of a photographic image to the 256 colors in a GIF palette, and not due to the compression... though the distinction is probably lost on the average layperson. Simply put, there are a limited number of colors in a GIF palette, and if one was to convert a photographic image to GIF, unpleasant visual effects such as "banding" or "dithering" would appear.

JPEG (left), GIF (right); for
the GIF, image is dithered.

However, for flat colors and crisp edges such as logos or illustrations, GIFs are perfectly adequate.

GIFs were insanely popular back in the day where quality didn't matter so much if you had animation and transparency. And GIF supports both.

Use it for: Low-quality logos or illustrations, especially if transparency and animation are required.
Don't use it for: Photographic images, ever.

3. PNG (.png)

Portable Network Graphics files handle crisp edges and flat colors just as well as GIFs, with the added bonus of transparency and animation (though this requires the APNG extension) just like GIFs. Visually, they're an upgrade over GIFs since they can also handle photographic images without the dithering or banding that often occurs with GIFs.

Where transparency is concerned, it's worth noting that GIFs offer full or no transparency, while PNGs offer full to no transparency - another major upgrade.

Partial transparency is
possible with PNGs.

Compared to JPEGs, they suffer significantly when comparing compression file sizes, since, like GIFs, they use a lossless compression method.

Still, with transparency (partial or full) and animation options, and the ability to handle both flat or photographic images, PNGs offers increased flexibility.

Use it for: Logos or illustrations, especially if transparency and animation are required.
Don't use it for: Unless transparency and animation are required, JPEGs should be preferred for photographic images... though in that case WebPs are still the superior choice.

4. SVG (.svg)

Take note of the name. Scalable Vector Graphics are just that - scalable. This means that unlike all the other image file formats, they can be scaled up or down with no loss in quality. This is because they are basically XML files, with instructions on how to render them, encoded as text. The browser then renders the images based on these instructions. Since they handle gradients as well, and aren't limited to 256 colors, these graphics aren't limited to flat colors like GIFs.

With SVGs, images can be
scaled up or down with no
loss in quality.

SVGs can suffer in comparison to PNGs at higher levels of complexity, since, as mentioned, they are basically XML files. Thus, a very complex SVG might be a huge file, while the equivalent PNG would still be a flat file and relatively small.

Use it for: Simple logos or illustrations, especially if transparency and animation are required.
Don't use it for: Anything else. Photographic images absolutely can be imported into SVGs, but the results are sub-optimal at best.

5. WebP (.webp)

WebP is Google's offering, and it is the currently apex predator of the image file format jungle. Not only does it handle photographic images at comparable compression sizes like a JPEG, it also handles transparency and animation like a PNG.

The WebP logo.

At just over a decade and change since its inception, It's still the new kid on the block, but already, it's settled in well. It doesn't hurt, of course, that Google the web browser generally uses it to generate image thumbnails in the search engine.

WebP hasn't yet become as ubiquitous and widely-supported as the other file formats, but it's probably a matter of time.

Use it for: For most things image-related, webP handles it all like a champ.
Don't use it for: For scalable logos and illustrations, SVG's still the superior choice.

Conclusion

Things have changed since the beginning of the internet and the online space is a whole new world now. Even though slow internet speeds and severely limited bandwidths are largely a thing of the past, it's still good practice to use the correct image file format for the correct occasion.

Get the picture yet?
T___T

Tech skillsets: Go deep or go wide? (Part 2/2)

There are plenty of reasons, though, to choose to generalize rather than specialize. And by that, I mean good reasons, not things like a lack of focus or a limited attention span.

The case for generalizing over specializing

It's dangerous to put all your eggs in one basket. An extreme example is if programmers specialized in VBScript to the exclusion of all else. The probability of those programmers having a job as of 2023, are approaching zero. I love VBScript, but it is what it is. Professionally, I cut my teeth on ASP and VBScript back in the 2000s. But what would have happened had I stubbornly refused to branch out? The thought makes me shudder.

Speaking of branching out, what makes it relatively easy for me to pick up new programming languages and frameworks is that I've been doing it repeatedly over the years. Instead of focusing on one specific thing to get good at, I identified certain things one new area had with the one I already knew, and worked from there. Got my fingers in as many related pies as possible. And as I learned more new stuff, my frame of reference only got stronger. All the stuff I learned, fed into each other. It's unclear just how good I would be at picking up new stuff if I had specialized instead.

Fingers in many pies.

The other advantage being a generalist gave me, was that I got plenty of attention from cheapskate financially strapped employers who saw the wisdom of getting me to do many different things at once, because I was decent at all those things. And often, for small startups, that's just what they need. The end result was that even in poor economic times, I rarely had trouble finding employment. I did not have to apply only for front-end jobs, or back-end jobs. I could apply to all of them.

Back in the day, I had been working for a law firm and maintaining their corporate website as one of my many duties. When I eventually left for greener pastures, the guy they hired to replace me was a more accomplished network infrastructure guy. More specialized, I would say. I went on to ply my trade as a web developer, but occasionally I would check back on my former company's corporate website to see what was shaking. Imagine my surprise one day when I went to the ABOUT US page where the hotshot attorneys were presented, and found a whole bunch of distorted profile photos! And that was after waiting a good couple minutes for all these images to load.

Apparently my replacement not only did not understand optimizing images for the internet, he also did not know about resizing images to fit the HTML img tag placeholders. He had simply taken the photographs he had been presented with, and used them as-is.

Was that his fault? No, not at all. My then-Manager had specifically wanted a network specialist, as opposed to me, a web developer who could follow simple network instructions. And his wish had been granted. But specialization comes at a cost. Things like image optimization for the web, just weren't covered in the guy's extensive networking knowledge. In the job, not only had I needed to help with network and infrastructure, I'd had to develop web applications and maintain websites, and my skillset had grown accordingly. These were the things the company had learned to take for granted where my position was concerned.

Ultimately...

Let me just say it again - the industry needs both specialists and generalists. Without generalists, specialists would have trouble plugging all the other technical gaps that their very specific skillsets do not cover. Hiring specialists for every area just isn't practical. On the other hand, without specialists, it would be devilishly hard for just generalists to raise the quality of the product to its optimal level.

Most of all, it would be really difficult to be a specialist in a world without generalists. And vice versa. Not only are both needed, the two need each other.

Specially for you,
T___T

Tech skillsets: Go deep or go wide? (Part 1/2)

"Jack of all trades, master of none" is a term I've heard all too often when fellow techies describe my stint as a web developer. Back then, I was a generalist dipping my sticky fingers into every new and shiny tech I encountered. In a sense, I'm still that web developer. Just with more money.

Go deep or go wide?

I want to explore the pros and cons of generalizing as opposed to specializing, especially in the context of today's tech landscape. The industry needs both specialists and generalists. That's a simple fact that shouldn't need some nobody tech blogger pointing out, but sometimes people get overly emotional about defending their stance. Want to specialize? Cool, do that. Want to generalize? Also cool, go crazy. But we need to be cognizant of the tradeoffs.

The case for specializing over generalizing

Before every tech and his dog started calling themselves "full-stack developers", specialists seemed to earn a whole lot of money. That was back when I was reading job ads asking for "deep expertise" and extensive work experience in more narrow scopes such as back-end programming and database administration. Some areas, such as COBOL programming, pay a lot for the simple reason that COBOL is still largely in use but COBOL programmers appear to be a dying breed. I've touched a lot of programming languages, but just enough to qualify as a hobbyist in each one. I have a decent frame for comparison between them - a Python lecturer of mine was actually quite entertained at my comparisons of the language to PHP and Ruby - but that often isn't very useful in the professional sense.

Specialists earn big.

The companies whose budgets are large enough to afford to pay for specialists, also tend to use these specialists for projects that are grand in scale. Projects that actually require deep expertise. Projects that add incalculable value to one's CV.

Deep knowledge is also useful for judging the extent of one's resolve and commitment. After all, it takes plenty of both to spend the effort. I personally know someone who specializes in HTML and CSS. It's a very narrow niche and perhaps not very profitable, but undeniably impressive.

Generalists - quite unfairly, I might add - seem to have developed a reputation for being easily distracted. Lacking the necessary discipline and focus required to specialize. I would actually say it takes an extraordinary amount of discipline to avoid going too deeply down one rabbit hole and shutting out everything else, but that's not the general sentiment. Therefore, in some circles, generalists are seen as those who were unable to specialize as opposed to specialists being unable to generalize.

The conventional advice when it comes to tech specialization, is to specialize in one area while simultaneously being decent in a few related areas. For instance, if you're a Data Analytics guru, you may want to specialize in statistical analysis and mathematics, but at the same time get reasonably good with Data Visualization tools and learn a bit of Python. If you're a primarily a Front-end Developer, learning some simple database concepts would be a useful addition to HTML, CSS and JavaScript. Maybe pick up a few frameworks such as ReactJS or VueJS, just to round things out.

I won't argue against that advice, but these days it feels like nothing is ever enough.

Next

We explore the opposite case!

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 AI, 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 AI 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 AI 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