Five Unpleasant Things About Working With Front-end Technology

In tech, there are several technologies at each layer of the stack. The nuances are usually not covered by tech hiring, and this is usually divided into front-end and back-end. Today, my intention is to examine the two, especially front-end technology. And here are five reasons why you might not want to make front-end technology your career.

1. Rapid evolution

There are several aspects to front-end technology. There's your standard HTML, CSS and JavaScript... and that alone can be a nightmare to keep up with. HTML, if you're up to speed with the most commonly used features of HTML5, not so much. For CSS, the preprocessor packages and CSS3 updates can be slightly more of a pain in the ass.

Multiplying like guppies

But JavaScript? If you elect to go down that rabbit hole, JavaScript is constantly evolving. The core language alone has been through update after update, The jQuery library as well. But all the front-end frameworks - ReactJS, AngularJS, VueJS, just to name a few - are also constantly going through evolution. And new frameworks seem to be coming out of the goddamn woodwork all the time!

And that's only the tech part. The design part is certainly nothing to sniff at. Learning fonts and color schemes is only the tip of the proverbial iceberg. Design patterns and anti-patterns evolve all the time. A typical website in the 90s will look markedly different ten years later, and another ten years after that.

This sounds fun if you're a hobbyist. When you do this shit for a living, not so much.

2. Uncontrollable environment

Front-end code runs on web browsers. Each of which comes with user-controllable functionality a front-end developer may not have catered for.

Yes, you read that right. User-controllable. Not developer-controllable.

Your typical web browser may come with a Dark Mode. There may almost definitely will be controls to increase or decrease font size. This is going to mess with all your layout specifications.

What about Dark Mode?!

Add in the fact that your users may screw with your carefully crafted interface by refreshing the browser insistently, pressing the Back button and using browser functions in all sorts of unruly ways. It's certainly not like a back-end interface where there are limits to input.

3. Testing nightmare

Mobile technology in the past decade has seen a proliferation of different screen sizes - tablets and phones - in addition to the standard screen sizes. In addition, there may be differences in how certain browsers render HTML, CSS and JavaScript. These differences have largely been eliminated with the demise of Internet Explorer, but some remain.

A plethora of different devices.

All of this adds up to an almost untenable amount of user interface testing for the optimal amount of exposure to the market. It is not an enviable position.

Front-end frameworks and libraries such as Twitter Bootstrap, jQuery and such, mitigate much of the insanity. But these issues have remained through the decade and will likely continue to grow the more mobile technology evolves.

4. Vague KPIs

In back-end technology, things are binary. Input is defined, and output is defined. The output is either correct, or it is not. It either is produced quickly enough, or it is not. Things either conform to security standards, or they do not.

Back-end input and
output is simpler.

Front-end technology has all that, true. It also encompasses a whole host of KPIs that are, for the most part, subjective in nature. User experience. Aesthetic beauty. Ease of use. These are guaranteed to vary from user to user and therefore, there is no way to obtain a perfect score.

Imagine being in a situation where you have to live with having less than total success. That is front-end technology.

5. Everyone has an opinion

This is somewhat related to the last point. In back-end technology, laypeople generally have better sense than to ever touch this, because they have little to no understanding of the stack and they have no tech qualifications.

Everyone and their dog.

In front-end technology, however, which is mostly visual, suddenly everybody and their dog has an opinion. Suddenly, everyone feels the need to chime in on how stuff should look and feel like. Nobody is shy about commenting because, well, you don't need tech qualifications to talk about something which is largely visual. It's subjective, so there are no wrong answers.

This makes your work a lot more difficult, when you have to take so much extra feedback into account. And when a sizeable portion of that feedback comes from laypeople, this makes things even more difficult because laypeople don't quite speak the same language techies do, and they may not have a good grasp of what technically makes sense and what doesn't.

In conclusion

Front-end technology is far, far from a bed of roses.

Still, if it still looks intriguing, let nothing deter you from your path. The important thing is not to go in blind, and be aware of all the pitfalls that await you.

Just being up front!
T___T

Wuhan Coronavirus: A techie's random thoughts

The outbreak has arrived. It's been a week of worldwide panic as the 2019-nCoV, otherwise known as the Wuhan Coronavirus, started infectng the city-dwellers of Wuhan in the province of Hubei, China. Cases of infection soon hit Singapore and the rest of the world as Wuhan went into lockdown mode.

Contagion.

And this is of interest to me, why?

Well, firstly, here's the personal part. A few months ago, my Chinese national wife returned to her hometown of Zunyi in the province of Guizhou to celebrate the Lunar New Year with her family. Shortly after the outbreak in Wuhan began, there were three reported cases of infection in Guizhou. And as such, it's my matrimonial duty to stay on top of things. Underneath it all is the nagging fear that if things go really south, I could become a bereft husband instead of merely an anxious one.

Yes, this is how I manage anxiety - by blogging. Eat me.

Secondly, as a Singaporean, I have a vested interest in not having the Wuhan Coronavirus take root here. Although it may be a little late for that. As of today, the count of infected cases in Singapore has risen to ten, though thankfully there have been no deaths so far. More on that later...

And lastly, response to this outbreak has produced some truly neat stuff. I'd like to point to this real-time updated website by thebaselab.co which is a great example of a mobile-friendly API-data driven site.

Screenshot.

A cursory look at their source tells me it was quickly hammered out with Twitter Bootstrap and Google APIs. Impressive work. I might have slipped them a few bucks as a token of appreciation for their trouble, and if you found the information useful, you might want to do the same.

How Singaporeans have handled the situation so far

I've seen people step up in recent weeks.

Some have expressed concern for their fellow citizens and distributed supplies such as hand sanitizer and personal thermometers.

Singaporeans stepping up.

An ex-classmate of mine went the extra mile to source for surgical masks so that retailers would be limited in their ability to profiteer off this emergency. At this point, I'm not even sure the masks will be enough to prevent the spread, but come on, that effort has got to be worth something.

Some have done their part to combat the flood of fake news, conspiracy theories and stirred hysteria online, analyzing this outbreak in relation to previous ones such as SARS and MERS. The numbers, so far, have been somewhat reassuring.

Other Singaporeans... not so much.

There's been a petition going round to refuse entry to all Chinese nationals and travelers from China. The latter I could understand (even though that would not be in my personal interests, because obviously if my wife returned, she would be returning from China), but all Chinese nationals? Not all people with a Chinese passport have been to China in the past year. Some stay abroad for, y'know, work and shit. What, all Chinese nationals are suspect by virtue of simply being Chinese nationals? You know this looks suspiciously xenophobic, right? We're all understandably fearful for our families and all, but let's not get stupid.

This is what the SQL statement would look like. Imagine if tblArrivals was a relational table of all incoming people to our airport.

SELECT * FROM tblArrivals WHERE Nationality = 'PRC' and CountryOfOrigin = 'CH'

Number of records returned from that query? Definitely more than 1.4 billion. Because we would be including non-China citizens who just happened to be flying in from China.

Also, petitions don't work in Singapore. Period. A million of us could sign a petition and you would still have a better chance of winning the lottery twice in a row, than of pressuring the Singapore Government to do what we want. The Singapore Government will do what it deems fit, when it deems fit, which is pretty much their job in the first place. And honestly, if we knew better, we would be in governance.

Simply stopping incoming flights from Wuhan wouldn't accomplish anything. There are no incoming flights from Wuhan. As mentioned earlier, the city, indeed most of Hubei, is in lockdown.

What the Singapore Government has done, is stop entry or transit for new visitors who have traveled to Hubei in the last 14 days, as well as holders of Chinese passports issued in Hubei. This is a far more measured and reasonable approach.

This SQL query would look like this. In addition to the tblArrivals table, let's have a tblTravelHistory table.

SELECT * FROM tblArrivals WHERE PassportPlaceOfIssue = 'Hubei' AND ArrivalId IN
(
    SELECT TravellerId FROM tblTravelHistory WHERE Area = 'Hubei' AND Country = 'PRC' AND DateDeparted BETWEEN DATEADD(d, -14, GETDATE()) AND GETDATE()
)

That's a far smaller number than an absolute blanket ban on all Chinese nationals. Because if you really only want to prevent possible carriers from entering Singapore, remember that it's not actually their nationality that matters, but where they've been recently. A British visitor could be transiting from Malaysia, for example, having flown in from Hubei. A Chinese national could have been working in Malaysia for the past year and is now attempting to visit his cousin in Singapore. Who's the bigger risk?

Sorry, I'm rambling...

Did I mention that I'm anxious? God yes, I really fucking am.

The wife assures me that she's feeling fine. The streets are quiet and most of the city are staying indoors. The supermarkets are still open, though there's not much variety at the moment. I'm not a superstitious man by nature, but fingers crossed!

To your health,
T___T

How I Became A Software Engineer (Part 1/3)

Just over three years ago, my professional life swerved off-course. I recovered from it like a boss and went on to greater things. Mostly because I've had worse, but also because I prepared for this eventuality well in advance. Still makes for a great story, though... so read on!

I was in the company described here, where I applied my newly-won Bootstrap skills. Everything went peachy for the first year. I met deadlines, applied myself, and took a course in mobile app development. Off work, I even had time to work on this blog and play around with all the new stuff I was learning. All was well. It didn't matter that I was often the most technically-qualified person in the room, or that some of the my colleagues (including those in higher management, the horror!) could not figure out how to use their email, much less understand the complexity of a web developer's role. But I was getting paid more than I'd ever been in my life (at the time, anyway) and on one hell of a roll.

Gradually, though, the dissatisfaction crept in. Remember when I complained about people who treat their employees like kids and insist on micromanaging them? This company had it in spades. Worse, the people who wanted to micromanage me couldn't carry my shoes in a development role. My direct Manager got complaints all the time about my toilet breaks, smoke breaks, latecoming... and he brushed them all off. What a guy. If there was one person who made my job tolerable, it was him, the only other technical person in the company.

Pay cut!

Then the day came. My Manager warned me of an impending company-wide pay cut. In a WhatsApp chat group opened specially for management personnel in the company, the Towkay had shared an article that predicted an economic downturn later that year. And like every other fat cat cheap bastard (with a mansion and swimming pool) I had ever worked for, he was using it to justify the pay cut. Within another day, a company-wide memo was sent out. Those at managerial level would receive 30% pay cuts, while the others would have 10% pay cuts. There was much consternation. Every staff member was called in to a meeting with the COO and HR Manager, to sign a document of acknowledgement of the pay cut. I did a few calculations and reasoned that I could lose 10% without things getting too uncomfortable. Even though I had been drawing an unprecedented level of pay, I lived like a guy who still drew 2,000 SGD a month.

Pay cut!

There was only one problem. They wanted to cut my pay by 30% instead of 10%.

The General Manager and HR Manager explained this by saying that I was drawing a salary on par with, or higher, than that of some of my colleagues who were Managers. And that was even after my Manager argued on my behalf that I didn't have the same benefits of actual Managers in the company. The COO and HR Manager then started to bring up my performance at work, such as latecoming, smoke breaks, and so on... somehow conveniently leaving out all the deadlines I'd met. And the fact that I'd never missed a day of work due to illness. That was when I realized just how much they resented me for not conforming to their long-cherished - and severely outdated - notions of what a valuable employee needs to bring to the table. Incidentally, this is one of the reasons I refuse to work directly for laypeople anymore.

I shut them up with an upraised hand and refused to sign the document, and told them I'd sleep on it and give them an answer the next day. So I did give it some serious thought.

I could leave the company, of course. The Towkay was playing this douchebaggy game of Chicken, banking on people being too afraid to do just that due to the projected economic downturn, and was taking this opportunity to squeeze his employees. Just on principle alone, I would have left. However, my Reservist duty was coming up in a month, and no company was going to hire me with that looming over my head. The best I could hope for was hunt for a new job after performing my Reservist duty, and then quit.

Back to the pressing issue of the pay cut. What if I reduced my working hours or took a couple days unpaid leave every week? Then they could deduct even more of my pay, and I would have more free time to code, work on my projects and maybe even find a new job. This was a win-win proposal, or so I thought.

Surprise - they turned me down. Apparently the Towkay was very insistent on his employees taking less pay for the same hours put in. (Again, see why I refuse to work for guys like these?) Once again, I refused to sign the document, and told them I would be discussing the issue with my Manager. The COO and HR Manager told me I should feel free to tell them how much of a pay cut I would be comfortable with. I promised to think about it, and give them an answer by the end of the day.

Putting on that friendly caring face.

At the third meeting, I started to tell them 30% was too much of a cut, and they told me this wasn't a negotiation. They just wanted to talk in order to get a better understanding of the difficulties of each employee... basically they wanted to appear sympathetic but their ultimate aim was to make us sign the document anyway. This was getting more ridiculous by the minute. The COO started to plead and I had this horrible feeling she was going to cry any moment out of exasperation. Tired of this charade, I patted her on the hand like she was this pitiful old aunty and signed the document. They tried to feed me more crap about how the company was going through hard times and we should all pull together. I'd had enough bullshit for one day and left the room.

Taking a 30% pay cut is one thing. But now I saw that they had begrudged me every cent they paid me since the beginning... because in their minds, people below managerial level should not be earning that much money. And from there, my decision to leave was cemented. In all honesty, I had been planning my exit for a while. I had merely thought to delay it for a year because they had facilitated the enrollment for the tech course I had recently graduated from. And using those new credentials to get a new job immediately after graduation just seemed wrong. But with their latest antics, they'd waived whatever professional courtesy and goodwill I might have owed them. And I had just brought the projected day of my exit very much forward.

My preparations for this day had been fairly extensive, and had started way before this entire episode. They mostly involved boosting my online credentials. For starters, I had my blog. The writing was sometimes amateurishly profanity-laden (still is, actually) but I had some nice writings on current affairs in tech which I replicated on my website. Sure, there weren't any extraordinarily deep thoughts in there, but at least it would show any prospective employers that I kept myself updated, and I actually bothered to pen my thoughts. I also had a GitHub account where I had uploaded code repositories. Working demos were hosted on my website. Again, the code wasn't groundbreaking; in fact it was really basic stuff that I had written web tutorials for. But actually having a GitHub account with working and tested code in it, is a visible measure of effort that does not necessarily speak for the quality of a developer, but definitely speaks for his enthusiasm. 

It all sounds like overkill, but you don't get by on a resume alone. Not in tech. And for my planned exit, preparation was key. All that stuff in addition to monitoring the job market and updating the resume. Remember what I said about resigning in a fit of pique? Yep, that's for noobs. You want to leave, fine. You better plan the shit out of it.

Surviving the pay cut

But first, I had to survive on reduced pay for a couple months until Reservist, after which I would be free to be hired by another company. Now that I had a plan and a timeline, living on a tight budget seemed really trivial. I didn't cut the amount I regularly gave my mother (hell, I didn't even tell her. Didn't want her to worry. I'm a grown-ass man and I can handle my own damn problems); instead I tightened the belt in every other area - cigarettes, food, and so on.

Tightening the belt.

Coincidentally, my appetite seemed to have shrunk (along with my waistline) during that period, and now with having to watch the expenses very carefully, I must have dropped about 10 KG in the ensuing few months. Honestly, having to make my own food daily and count my cigarette usage seemed to have done me a world of good.

My other colleagues were coping in their own way. Some tendered their resignation. Some took to mysteriously falling ill every other day and maxing out their MCs. Some just lengthened the duration and frequency of their breaks. The latter two cases were a source of consternation for management - apparently they'd been having this fantasy that those who chose to stay on would simply let themselves be squeezed.

Me? I didn't have time for any of that shit. Too busy planning my exit.

Company collapse

The day for Reservist drew near. I stepped up my efforts and prepared to put my plan into action. Everything seemed in place; the only thing I worried about was explaining why I had left this last job. Saying I had left due to a company-wide pay cut might give prospective employers the idea that I was open to exploitation.

Then the CEO dropped another bombshell. I was summoned into the meeting room, where the CEO, COO, HR Manager and my own Manager were waiting. I wondered what all this was about - what would warrant such a setup? I did not have long to find out. The CEO informed me, looking quite chagrined and regretful, that he had no choice but to let go an entire department (which included me, apparently) due to a botched client contract that rendered half the company obsolete.

Upset? Heck, no.

Were they expecting me to feel upset? It certainly looked that way. All of them were wearing expressions that suggested they were attending a funeral service. Me? Heck no, I was elated. Being let go due to the company crashing and burning was a hell of a lot easier to explain at my next interview, than a resignation. One of my biggest problems, solved right there. Plus, there was paid gardening leave. Things looked pretty sweet right there. I think it's safe to say I was the only dude smiling in the room. I was patting the CEO on the arm and going "Why the long face? Cheer up, life goes on!" Though I think the people most unhappy with this development were those who had already given their notice and weren't entitled to gardening leave.

So yes, Your Teochewness was free, and things had worked out even better than I'd expected.

What's this company?

I have a policy regarding speaking ill of my ex-colleagues and former places of employment. If I'm going to do that at all, they won't be mentioned by name. No, I'm not afraid of a lawsuit. I just have certain lines that can't be crossed.

Epilogue

A few months after I left, the company ceased operations. What a surprise.

Next

That's only the beginning. The trials that followed were pretty aggravating!

Five comparisons between Twitter Bootstrap and Semantic UI

There are plenty of CSS and layout frameworks on the market. I've had the privilege of using two of them - Twitter Bootstrap and Semantic UI. Both frameworks are used to provide responsive layouts and improve the UI. While they're similar in very basic ways, they are different enough to warrant a comparison.

Here are 5 ways they compare...

1. Features

Both Twitter Bootstrap and Semantic UI use a grid layout for responsiveness. Twitter Bootstrap uses as 12-column grid while Semantic UI uses a default of 16 columns (which can be changed). Some say this increased granularity gives Semantic UI the edge, but from my perspective I'm not sure it makes that much of a difference.

They both have features like button groups, accordions and beautified form inputs. This is where Semantic UI arguably has the advantage, as it boasts many more variations on those features than Twitter Bootstrap. Semantic UI's icon set, for example, has about 617 in 25 categories to Twitter Bootstrap's 264... the free ones anyway.

Twitter Bootstrap's icon set (left)
Semantic UI's icon set (right)

Both Twitter Bootstrap and Semantic UI offer features that the other do not. For example, Twitter Bootstrap has a Jumbotron feature, and Semantic UI has a really nifty-looking rotating cube feature. But even on quantity alone, Semantic UI has the obvious edge.

2. Marketability

Twitter Bootstrap is almost a household name among developers. Most devs have used it since 2011, at one time or other, to do up websites. Semantic UI, on the other hand, is the relative new kid on the block, having been here since only 2015, and at this time does not even have a Wikipedia entry.

The obvious inference here, of course, is that Twitter Bootstrap has way more support and documentation.

I know Bootstrap!

But the real edge is that almost everyone has heard of Twitter Bootstrap, whereas fewer have heard of Semantic UI. So putting Twitter Bootstrap on your resume is more likely to get you jobs. Even during interviews, I've had interviewers nod sagely when I mentioned Twitter Bootstrap, and give me blank looks when I mentioned Semantic UI.

If you mention Twitter Bootstrap, most people will immediately assume you understand Responsive Design. Which isn't strictly true, but perception is what it is.

3. Look-and-feel

Twitter Bootstrap isn't considered generic without good reason. Most people use the free default theme, which results in Every Fucking Bootstrap Website Ever. Which can be a shame because Twitter Bootstrap can look really good, if you're willing to pay for different themes. Even if not, contributors have offered their own Twitter Bootstrap themes, which can add some variety.

Semantic UI's default and optional themes, all free of charge, already promise a dizzying array of effects that won't immediately scream SEMANTIC to people who view them. Of course, the fact that Semantic UI isn't famous like Twitter Bootstrap, probably helps.

Twitter Bootstrap's color scheme (top)
Semantic UI's color scheme (bottom)

If you want hard numbers though, just consider color schemes. Twitter Bootstraps default theme comes with 6 colors. Semantic UI has 12 (in both cases, we're not counting black). And this can be a simple but huge factor in flexibility of design.

Also, Twitter Bootstrap has 4 size categories - lg (large), md (medium), sm (small) and xs (extra small). Semantic UI has 8 of them - massive, huge, big, large, medium, small, tiny and mini. Though it's worth noting that Semantic UI's size categories aren't rendered with perfect consistency throughout their elements.

4. Difficulty level

Twitter Bootstrap is easier for someone with totally no jQuery knowledge, to use effectively. For Semantic UI, it's a lot harder because jQuery is used often, either as an initializer or to manipulate the controls. Even though many features have a non-jQuery version, this results in a drastically less rich user interface.

If you're only using Twitter Bootstrap or Semantic UI for responsiveness, then this doesn't matter.

Semantic UI's code sample

Personally, I like Semantic UI's style. The jQuery animation features in its feature set allows me to do a lot of cool things without actually writing my own.

Although if you want to really customize stuff, it might be easier in Twitter Bootstrap. Semantic UI offers a lot of customization options, but it can't cover everything and sometimes trying to shoehorn their existing options into what you want exactly, is a pain in the ass.

5. Class names

Twitter Bootstrap uses class names that don't read like normal English.

<div class="row">
    <div class="col-xs-12 col-sm-6 col-md-8">Column 1</div>
    <div class="col-xs-6 col-md-4">Column 2</div>
</div>

Semantic UI's class names look like this.

<div class="row">
    <div class="twelve wide computer six wide phone eight wide tablet column">Column 1</div>
    <div class="six wide computer four wide tablet column">Column 2</div>
</div>

Some say this makes Semantic UI friendlier to use. I'm ambivalent here. See, I have this habit of writing my own CSS classes. And it's far harder to clash with CSS class names like btn-lg than with names like segment or basic.

Conclusion

Personally, I'd take Semantic UI any day of the week. It's got features I need, and I don't have a problem with using jQuery. But Twitter Bootstrap might be better for people who want decent results with a minimum of fuss, and more if they're willing to cough up the cash. And in any given professional environment, the chances of Twitter Bootstrap being already in use are astronomically higher.

Pick up a CSS framework today. It's a xs effort for massive gains.
T___T

How I Learned Bootstrap (Part 2/2)

After doing the required reading on Twitter Bootstrap and getting a feel of how it was used, it didn't seem so damn hard. That was because Bootstrap is what a wheelchair is to a double amputee. You can't walk, but it will still get you from Point A to Point B by leveraging on a different set of tools, i.e, your hands. In the case of Bootstrap, the user does not have to understand Responsive Design - he just needs to leverage on HTML. The CSS files provided will do the rest.

More action

And then it was time to wade in further. Playtime was over.

Time to go deeper.

I accepted a commission from a friend to build a site. I charged him a shamefully low price for my services, but on one condition - I was to be allowed to use Twitter Bootstrap even though I had no professional experience in it. For months, I slaved over the look and feel. Money wasn't the issue here. I wanted to produce something using Bootstrap, something that would actually be put on public domain. With each UAT, each iteration, I grew stronger. Sure, I wasn't exactly becoming a guru in Responsive Design. But learning to use Twitter Bootstrap was a good first step.

And then I discovered something strange.

When I viewed the source of my HTML, it now looked suspiciously familiar. In fact, it was pretty much identical to what my colleague was doing. She had been using Bootstrap, and the clueless noob that was my CEO had bought into the narrative that this made her the expert in Responsive Design. Although at his level, I'm pretty sure it made no difference whatsoever. The end result was there.

Now, this is not meant to be a criticism of my ex-CEO. There's plenty to criticize, but that's neither here nor there. No, this is basically how the average layman thinks. They see the end result, but they're not privy to the process and they have no clue what differentiates a tool-user from a real expert. Resenting it would not make an iota of difference. Instead, I resolved to take full advantage of it.

How?

Performing "magic".

I quit my job. And then I left that company for another company full of the same clueless noobs, and presented my newfound skills in Bootstrap as mastery in Responsive Design. It worked like a charm. They had wanted Responsive Design, and what I gave them was a whole lot of shameless Bootstrapping. They never understood the difference.

Why did I quit the company?

That's the burning question. Some of my ex-colleagues, due to the timing of my departure coinciding with the promotion of my new colleague over me, thought I left out of bitterness. That's their opinion, but I think they were projecting a fair bit. I didn't care about the promotion. Being a "Senior" or a "Manager" has never mattered to me, especially when said title is being bestowed by some clueless jackass.

So why did I want to leave? After all, I'd already overcome my front-end handicap. There was no longer a need to leave, right?

Wrong.

You see, biases run deep. I had been hired by a Manager who had been on his way out. In fact, his last day was the day I joined. My new colleague had been hired by the CEO himself. When push came to shove, I knew whose side he would be on. It's just human nature.

Also, the sensation of coming in every morning to a workday filled with endless grunt work was... unpleasant. It wasn't the volume of work that I minded. It was the complexity, or lack thereof. Seriously, I was a web developer. Why would I want to spend another year coping with EDMs, writing registration forms and performing maintenance work that an intern could do? The money was good, but this was ultimately career suicide. I was a diesel truck doing the work of a horse cart.

On top of all that, was knowing that I was working for a guy who did not rate me, and was simply looking for an excuse to get rid of me. If not the front-end excuse, eventually some other thing. I could have tried harder to prove myself, but I simply did not see the need to prove myself to a dude who didn't know jackshit. What was the point?

Learning Bootstrap did not eliminate the need to leave. Rather, it facilitated my desire to leave.

The Takeaway

You may think this sounds utterly cynical, and on a certain level, it sure as hell is. But there's a lesson (or a few) to be learned in all this. Sometimes it makes no sense to beat them, when you can simply join them. The result of this was that I picked up a few new skills to add to my ever-growing toolbox.

The first, obviously, was Twitter Bootstrap.

The second, not so obviously, was that sometimes being an expert is too much work when you can just fool people into thinking you're an expert.

The third, if I do say so myself, is that I'm pretty good at turning lemons into lemonade.

I guess we could call this a... re-boot?
T___T

How I Learned Bootstrap (Part 1/2)

In recent years, I've been busy stepping up to the demands of front-end web development. With the explosion of mobile technology and all the other nifty portable tech devices, front-end has never been so hot.

But I certainly didn't just wake up one morning and decide, I am going to pick up my front-end game. No, it sparked from a certain conversation I had a couple years back, augmented with tons of soul-searching.

Here's how it began

It was 2013. I was slaving away in a media house maintaining all their websites and microsites, for a CEO who obviously felt (and had expressed his disappointment) that my skill in coding did not translate to "beautiful" interfaces. At that time, even with a working knowledge of HTML, CSS and JavaScript, I was pretty much a server-side and database guy. Most people understood that web design and web development were two different disciplines. Not this fella. For his money, he expected someone who could make stuff work, maintain his servers and make stuff look pretty.

And then he hired this girl, who actually did make stuff look pretty. The animations, colors and responsive layouts she incorporated into her work made my spartan (white background, black text) style look positively horrendous. I viewed the source of her code, and the stuff I found in there bamboozled me.

I understood then, that no matter how many deadlines I met, no matter how hard I worked, no matter how many weekends I burned, my job was in jeopardy.

Then my Manager took me aside and confirmed my suspicions. Our CEO favored his new hire, not just because she was his new hire (though that didn't hurt, I'm sure) but because she made stuff look nice and shiny. This was the media and publications industry, my Manager explained. That was just the way it was. However brilliant I thought my code was on the server, it would go unappreciated. In this business, what mattered first and foremost was appearance. Also, to a lesser extent, this reflected the worldwide trend. Server-side and back-end stuff wasn't dying, but it was certainly not growing as fast as front-end, which was really taking off at that point.

In short, I ignored the front-end portion of my web dev game at my own peril. I had neglected it for years while learning new databases and scripting languages. And now my Manager's little nudge sent me in the right direction. The writing was clear on the wall.

Time to think...

Over the course of a five-minute smoke break, I made up my mind. I would pick up my front-end game. But my time in the company was over. The CEO was merely tolerating my presence because I got shit done. Once his new hire got into the swing of things (and stopped pissing our colleagues off, but that's another story for another day), my days in the company were numbered. I would be gone faster than you could say "Hypertext Transfer Protocol".

For all my faults, and believe me there are plenty, I've never been one to outstay my welcome.

Taking that first step

There were ex-colleagues on my network. I reached out and made a few calls, asking basically the same question.

How do I improve the front-end aspect of my skillset?

Lifelines

I'm glad I was nice to my ex-colleagues back then. Because, oh boy, they really came through for me now.

Some of them gave me advice. Better, some gave me links. The common thread was bootstrapping. Using a grid system to lock the front-end into a responsive layout. And finally, my search brought me to Twitter Bootstrap. One of my ex-colleagues swore by it.

Action 

Now that I had made up my mind to learn Bootstrap in order to beef up my front-end game, the rest was easy. Well, not easy, per se, but simple enough. The direction had been settled, the immediate steps defined. Now all that was required was action.

For a couple weeks, I dedicated myself to this task. Over weekends, I read the documentation. I perused the examples, explored the links, and marveled at the results as I tried out line after line of Bootstrapped HTML. Researching something as general as Responsive Design had been intimidating. Learning Twitter Bootstrap, which was merely a tool, was a lot more manageable. There were library books. Online tutorials. For a guy who had picked up VBScript and PHP from reading a book, this was familiar ground.

Next

Details about how I cut my teeth in Bootstrap.

Instant gratification and a quick Fixx

On the 8th of this month, there was an article in the Straits Times detailing a possible shortfall of graduates in the IT industry by 2017. One quote from the article stands out.

"When fresh graduates come to us, the coding languages they know have already been phased out"
- Mr Darren Lee, managing director of Fixx Digital.

Now admittedly I don't know the finer details of how Mr Lee runs his company, but this strikes me as fundamentally wrong and shockingly short-sighted. Programming languages, or as Mr Lee puts it, coding languages, are nothing more than tools. If you hire people based on their knowledge of a tool; when that tool inevitably becomes obsolete, these people become obsolete as well.

But they can learn new tools, right? 

That is precisely the point. Hire people who have the foundation to learn new tools, not people who know one particular set of tools. Arrays, iterative loops, MVC, human-computer interaction - what do they have in common? They are concepts. Concepts that have changed little since the day they were introduced. Languages evolve, but they will always go back to those basics.

When you do object-oriented programming, whether it's in Java, C++ or PHP, you are dealing with constructs, encapsulation and inheritance. The only thing that differs in syntax.

When you create a website, whether it's in Twitter Bootstrap or hand-coded HTML5, it still deals with HTTP and W3c compliance still applies.

No matter what version of Android API you're using to code that mobile app, the standard life cycle of an app has not changed since day one.

Whatever fancy new databases emerge on the market, they're more than likely to be queried via SQL.

There is a good reason why schools are not teaching students the latest, greatest breakthroughs in technology. Because it just isn't feasible. Technology evolves faster than you can establish a curriculum for. All you can do, is give students the foundation to build on. I may not be the biggest fan of Singapore's educational system, but let's be fair. If a school, any school, were to insist that their IT students are versed only in the latest technology, the students would never graduate. In a sense, that is true of the average developer - we never stop studying.

Learn to invest in people instead

You only want to hire people who know your stuff and can get cracking right away without having to learn it on the job? No problemo. But you're taking a huge risk here. If you hire a guy who knows the new fancy tools you've built your company around, all will be fine and dandy... until technology evolves. And this being technology, it will evolve. You can take that to the bank.

Don't hire tool users. Hire developers. 

Developers are constantly upgrading. It's part and parcel of this industry. Developers know the basics. It is the new emerging tools they need to familiarize themselves with. There is no such animal as a developer who already knows everything he needs to know and can get by without learning new things.

Companies that are not in the web industry will not understand this, nor are they expected to. They will hire based on the tools that their candidate should know now. Quite understandable. But Fixx Digital is a web design company. What's its excuse?

Get rid of that unhealthy Fixxation today.
T___T

Frameworks in Perspective

Frameworks are increasingly becoming the in-thing. From scripting languages (CodeIgniter and Symfony for PHP, Django and Pyramid for Python, etc) to front-end (AngularJS) and now even CSS (Bootstrap), frameworks are here to stay and are fast becoming mainstream, if not already firmly a part of it. Increasingly, firms are now looking for developers who not only know their way around scripting languages, but also frameworks.

What's not to love about frameworks? They take care of the nitty-gritty stuff, speed up development considerably and have great support worldwide. Knowing a framework or two adds glamor to your resume.

But here's the rub: I don't love frameworks.

Sure, I acknowledge that they are getting increasingly popular, for legitimate reasons. I acknowledge their place in the industry. I may even have used a few myself. But, call me old-fashioned, I tend to like getting things done without frameworks. Don't get me wrong, frameworks are great for business. With reduced development times and nifty things like code reuse, projects get completed faster. Deadlines get met and vendors get paid (hopefully!) sooner.

Yes, I'm going to say it again - frameworks are great for business. But I'm not a businessman. I'm a geek.

Here are some reasons why I would prefer to do without frameworks. I call them the three "Overs".

Overuse

This is web development, and there are no blanket solutions. The solution you choose should depend on the context. But some developers forget that. They think they've found this great one-size-fits-all framework and insist on using it for everything.

"I suppose it is tempting, if the only tool you have is a hammer, to treat everything as if it were a nail." - Abraham Maslov

I once worked with a developer who used CodeIgniter for every damn thing - including Contact Us forms! And - get this - a guy who wanted to go ASP.NET MVC for a static website. That's another "Over" right there - overkill.

And seriously, if what you need is a no-frills web application that doesn't have to look pretty or be used on mobile, why would you even bother trying to use Twitter Bootstrap for it? This is insane!

It's like using a hammer to break an egg.

Uh-oh

jQuery, for example, boasts that it will drastically cut the number of lines of JavaScript code you write. Let's assume that I load the jQuery file and now instead of 20 lines per function, I write only 5 lines. If I have 50 functions in there, I would have saved (15x50) 1250 lines of code. But what if I only had 5 functions? I would still have to load the entire jQuery library. Doesn't it, then, stand to reason that I'm only getting enough bang for my buck if I use jQuery for far, far bigger things?

Now replace "jQuery" with the name of any framework out there and you'll why I facepalm at this silliness.

Overhype

As mentioned earlier, frameworks benefit the businesses by speeding up the development process. Consequently, business owners set great store by developers who can develop using frameworks. This can lead to developers thinking they're hot shit simply because they can code using a framework.

And that is sometimes implausibly stretching the truth.

You see, it is entirely possible to learn the framework without learning the foundation behind it. Knowing one does not mean knowing the other. You can learn Django without learning Python the same way one can learn jQuery without learning JavaScript. And some developers do precisely that. They start using the framework as a crutch for all the gaps in their knowledge, and that's where the problem begins.

Don't know about sanitizing input? No worries, the framework takes care of that. Don't know how to prevent SQL Injection? Framework takes care of that too. Don't know about responsive design? No problem, we use a framework!

Excuse me for a minute there, I feel the sudden urge to puke.

Gag. *hurk*

Knowing how to code in a framework is a good thing. But only if your foundation is rock solid. Otherwise, you are merely a tool user masquerading as a developer.

The framework and its source technology are not interchangeable. If you're going to use a framework, for the love of God, please make sure you're not helpless without it. Frameworks are meant to make your life easier. It's a lot like riding a jet ski without knowing how to swim. The slowest jet ski moves a lot faster than the average swimmer, but if the engine ever stalls out at sea, buddy, you are screwed.

Overhead

The overhead. Oh Christ, the overhead. They say that frameworks help you code less - by introducing a lot of predefined code, 10% of which your project may actually use. That's a gross exaggeration, but it's true that not everything in a framework will be of use in the application it's used for.

Getting a little crowded in here, guys.

But really, that's not the issue here. I can live with some wastage. Until it takes on ridiculous proportions.

I've had to use plugins before, while working on Joomla! and WordPress projects. Each plugin invariably installed its own version of jQuery or MooTools. That led to many copies of jQuery at any given time. Seriously, how is this a good thing? Again, call me old-fashioned... but the part of me whose roots came from C++ and having to manage memory, positively recoils in horror.

Or, if you want a serious miscarriage of justice, look at ASP.NET 3.0. You write the code in C# or VB.NET, and the server compiles the code to generate the pages. View the source of the generated pages, and you'll see chunks of server-generated JavaScript, both to preserve state and to simulate the action of the various ASP.NET Web Objects you probably dragged and dropped into the page. Yes, even a humble label is a Web Object!

Framing the Issue

So there you go. Do I hate frameworks? Not really. They have their place. Frameworks are not really to blame here. They're a tool like any other... and sometimes a blooming annoyance. The real issue is with the people who use them. Think about it: Is it the fault of a framework if an overenthusiastic developer decides to use it for every damn thing? Is the framework to blame if developers use it to cover up their own inadequacies? OK fine, overhead is a framework's problem, but is it really fair to blame frameworks for the other problems I've listed?

Technology's fine. It's people who suck.

Over and out.
T___T

So you want to be a Web Developer? (Part 1/4)

Think web development's the life for you? Want to get your hands dirty and be part of the process? Want to get into the industry but aren't sure what skills to pick up? Hey, look no further. This four-parter shows you the bare minimum you'll need to get started.

If we exclude design and SEO, which are just about separate and distinct disciplines anyway, the areas you'll want to look into are front-end, back-end and databases.

Front-end

If you're thinking HTML, you're right. But only partially right. What you should really be thinking of is HTML, JavaScript and CSS. Seriously, if you only know HTML, don't even bother mentioning it to an interviewer.

I thought JavaScript and CSS were optional!

Technically, it's true that HTML can work on its own, while JavaScript and CSS need to be embedded in a HTML page in order to work. In practice, we have a term for aspiring web developers who only know HTML: secondary school kids. You can make a living with only knowledge of HTML. But unless you want to spend your entire career writing EDMs, do consider picking up the rest.

We live in an exciting age where JavaScript and CSS are no longer just nifty add-ons to make your pages more interesting. Knowing JavaScript is a precursor to mastering AJAX, which adds a whole new dimension to the interactivity of your pages altogether. And CSS is great for styling and layout, and pretty damn useful for large-scale projects. That's not even mentioning the fact that CSS3 now does for web development what Flash did years back - great animations.

What you must know

You'll need to know all these like the back of your hand. Off the top of your head. It better be more familiar to you than your mother's birthday.

For HTML,
- Basic page anatomy, ie head and body tags, and what goes into each.
- Form elements and their attributes.
- Color codes.
- W3C Compliance.

For CSS
- Text formatting.
- Layout, in particular the position property.
- Responsive and adaptive design.

For JavaScript
- The DOM (Document Object Model), elements and properties.
- Data types.
- Operators.
- Number and date formatting.
- Arrays.
- Programming constructs, ie. For, While, If-Else, etc.

HTML5

When you're done with basic HTML, know the ins and outs of form and page elements, the next useful thing to know would be HTML5. It's the way of the future, or at least it will be once the World Wide Web Consortium stops dicking around and actually cements some industry standards.

More about HTML5 (http://www.w3.org/html/wg/drafts/html/master/)

Good-to-haves

I would never recommend that you start off with these. But they're such a mainstream part of the web development landscape, they're worth a mention. If you're up to speed with the basics, you may want to consider expanding in the directions listed below.

HTML5 Boilerplate and Twitter Bootstrap work great if you're pressed for time and you're trying to make it look like you know your shit.

HTML5 Boilerplate (https://html5boilerplate.com/)
Twitter Bootstrap (http://getbootstrap.com/)

If you're good with JavaScript, JavaScript libraries such as jQuery or MooTools is the next logical step in that direction. You'll do fine without them because they can be a right pain in the posterior. But they're respectable items in the resume.

jQuery (http://jquery.com/)
MooTools (http://mootools.net/)

CSS Frameworks such as SASS and LESS would come after you've mastered CSS syntax. Again, not compulsory. Know your basics first.

SASS (http://sass-lang.com/)
LESS (http://lesscss.org/)

And then there are the CMS platforms. These require a quite a bit of tweaking, a lot of it on the front-end. There are two ways to interact with these - as a non-technical user, and as a developer. You will, of course, be doing the latter.

WordPress (https://wordpress.org/)
Drupal (https://www.drupal.org/)
Joomla! (http://www.joomla.org/)
Magento (http://magento.com/)

For the record, I absolutely hate this crap. Worked with Joomla! and WordPress over a year, and never found a reason to like them.

What are my career options?

If you only know HTML, there's still a job for you in Marketing. You know those mass emails they send out, with advertisements, newsletters and all that jazz? Those are called EDMs. (Electronic Direct Marketing). Since email clients have not caught up with browser standards, the safest way to render them would be using only HTML - no CSS, no JavaScript, no forms.

But that kind of job pays miserably. Plus, if you say you want to go into web development, I assume that means you're up for a challenge.

If you know your HTML, CSS and JavaScript, and know the best practices that come with using them (W3C Compliance and cross-platform compatibility, etc), and don't wish to expand your skill-set any further beyond the front-end, you can still hack it as a Web Designer.

Next

What you need to have in your back-end repertoire.