No Blanket Solutions

There exists in the spoken language, a supreme contradiction. A sentence that manages to be simultaneously profound in its humility and stunning in its arrogance.

"If I can do it, anyone should be able to do it." - every douchebag ever.

Why is this humble? Well, on the surface, it seems like people who say this are modestly describing their achievements as mediocre. They feel that they're not special, so if someone as unexceptional as them can do something, there's no reason why most other people wouldn't be able to do it. For example, I quit smoking almost two years ago. I did it far easier than many people did, with no lingering physical or psychological side-effects despite having been a pack-a-day guy for the better part of twenty years. No discipline was required; the struggle was non-existent for me. However, I'm also reasonably certain that this isn't that uncommon. There are plenty of people, wired the same way as me, who could accomplish that. Acknowledging that you're not special, is humility.

Why is this arrogant? At the same time,  if I were to claim that I quit smoking without much fuss, and there is something wrong with people who can't simply follow my example; that's a problematic stance to take. Assuming that oneself is the standard on which everyone else should be based around, is both immature and pretty egoistical. It lacks self-awareness.

And both positions are wrong.

We're not all the same.

They're wrong for the very uncomplicated reason that we're all built different. We don't all come off some assembly line with the exact same characteristics. There are significant variances across data points like culture, upbringing, physical and environmental.

For example, people who spent their formative years in a Southeast Asian multicultural country like Singapore or Malaysia would have significantly less trouble picking up a third or fourth language as opposed to, say, an Englishman born and bred in the UK. Incidentally, that's why people coo and act impressed when a white guy speaks Mandarin (even if his pronounciation is dogshit). Whereas nobody bats an eyelid when an Asian guy speaks English well. Why? Because a white dude even attempting to speak anything other than dodgy English is impressive, whereas for an Asian guy it's just another Tuesday.

Is it fair? Well, of course not; but if we're going to acknowledge that everyone's built different, then nothing is fair.

The tech space

"There are no blanket solutions" is a favorite refrain of mine, because it's true especially in the tech space. You can have all the best practices in the world, but they have to be evaluated against the exact context in which you're applying them. The concept of best practices is a good thing, don't get me wrong, but only if not applied blindly.

Frameworks aren't always the way to go; I've said this before over and over. They're often the way to go in software development, but not in every situation.

Not every data storage solution has to include a database.

Not every 2FA solution
looks the same.

Not every 2FA solution looks the same - some involve texts to mobile phone and some involve a third-party authenticator app.

You wouldn't use Python to code every damn thing, just the same way you wouldn't use Java to do it. At least, I hope not.

While we're at it, almost every organization's implementation of Agile Methodology looks different from the next.

But while all I've said so far is uncontroversial, that's for the tech space. The software development context.

In a personal context

Someone once told me he wanted to be like me. I had a place of my own. I was doing well financially with no debt. While I wasn't filthy rich, I spent money without needing to think too hard about it. And above all, I was chill. I didn't let what I didn't have, bother me too much.

And all that was before I got blissfully married and really started stepping up my game at life.

Possibly, to an outsider who was just watching me live my life, it looked like I had everything without needing to turn to drugs or alcohol in order to cope. Furthermore, it looked like all that was needed to achieve what I achieved, was to live my life the way I did. Sadly, I had to disabuse this person of that fantasy. He was not going to achieve the same things I did by living like me, simply because he wasn't me.

There's more than
one path to the
rainbow.

My achievements aren't spectacular by any means. An apartment, a job and a spouse. Spare cash in the bank. The means to take care of my immediate family. These things are achievable by the vast majority of people. All I've really done is earn as much money as I can while living a very modest lifestyle. And that's the hard part.

You see, not everyone can, or wants to, live life the way I do, as if I were still drawing an income of just under SGD 3,000 a month. It takes a specific kind of person to happily sacrifice pleasure for stability. Not everyone has the same experience and needs. Not everyone has the same personality. I know plenty of people who would struggle mightily with a simple existence.

Overseas vacations, wine and cheese, cab rides, expensive pets, gym and club memberships - I won't miss any of those things because they're not the kind of things a guy like me cares about. But again, not everyone is like me in this regard. And honestly, for the sake of Singapore's economy, I really hope not. (Part of the reason why I can live the way I do, is because other people have this habit of buying pricey shit they don't need. So keep on doing what you do, guys; you're awesome.)

Therefore, it's not a simple matter of glibly saying "live life this way". Not everyone will take to my chosen lifestyle the way I have, or reap the exact same rewards from doing so. Why should anyone travel the same path and have the same outcomes as me when they're fundamentally different from me? That makes no sense, does it?

In a nutshell...

The mistake most people make is to assume that everyone wants the same things that they do, or at everyone is built the same way. That's why you have well-intentioned but severely misguided people going around advising others to have kids or go to Church or become a vegetarian because those things have benefitted them... and they assume that these things will benefit other people in exactly the same way.

People can certainly achieve the same things I have, or more... but they're going to have to find their own pathway to it.

Stay unique,
T___T

Ten Professional Hazards Of Writing Code For A Living

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

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

1. Counting from zero

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

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

There are five apples, not four.

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

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

2. Being easily startled

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

Violently startled.

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

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

3. Being very literal

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

No capacity for nuance.

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

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

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

4. Single-mindedness

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

Laser focus... or just
tunnel vision.

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

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

5. Overusing techspeak

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

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

No, not that kind of string.

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

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

6. Expecting output

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

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

A lot of irrelevant information.

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

7. Cynical

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

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

Glass is always half-empty.

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

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

8. The How 

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

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

Examining how things work.

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

9. Lack of sympathy

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

Heart of stone.

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

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

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

10. Flowcharting

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

The good old
divide-and-conquer.

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

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

What a hazardous list!

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

How many apples do you see?
T___T

Five Software Development Takeaways From the COP Saga in 2021

In sunny Singapore, the Committee of Privileges (COP) saga took place last December, just a month ago. It all began when Raeesah Khan, an MP from the Worker's Party, was caught speaking a falsehood in Parliament which directly implicated the Singapore Police Force.

Time passed, and she repeated the lie in Parliament, and subsequently confessed when pressed on it. The fallout from this was that she had to resign from the Worker's Party, and the Committee of Privileges was formed to investigate the possible culpability of Worker's Party leadership in this debacle.

There has been a lot of coverage on YouTube concerning this investigation, with the hearings (the combined durations more than thirty hours in all) of different witnesses publicized. As a Singaporean, I have taken an interest and listened to almost all of the footage. As a software developer, these were the lessons I gleaned.

1. Diversity Hires

When Raeesah Khan first won her seat in 2020, there was this article from The Independent Singapore that made this big song and dance over the fact that she was the first female minority Opposition, and the youngest MP in Parliament. This turned out to age badly, considering what trouble Khan has gotten herself into since.

An MP deceitful enough to lie once in Parliament, and foolish enough to double down on that lie a month later? What really gets me was that there was so little to gain from this. Politicians lie and cheat in order to embezzle huge amounts of money. What were Khan's motivations? She wanted to make the police look bad. Furthermore, the incident she had described in Parliament had not been personally experienced, but something she had read off a WhatsApp chat group conversation. Passing off WhatsApp anecdotes as fact is the province of clueless Boomers, not an MP.

Make the police
look bad.

During her hearing, it was revealed that Khan was against resigning from the Worker's Party because she was worried about how this would impact the image of female minorities in politics. With all due respect, that ship appears to have left the harbor the moment she got caught in the lie. If it's any comfort, unlike those idiots at The Independent Singapore, I never saw Raeesah Khan as a female minority, much less considered her any representative of such. All I ever thought of her, even when she won her seat, was as this dangerous loose cannon with an axe to grind against the police.

This is a valuable lesson for hiring in tech. Stop focusing on age, gender and race - largely immutable traits - of your candidates and instead focus on what they have accomplished, what they are currently doing, and what they can further accomplish. Hiring people for the sake of fulfilling some nonsensical diversity quota can come back to bite you in the ass when they inevitably screw up because you cared more about the color of their skin or their genital plumbing than their actual ability.

2. Explicit Instructions

According to Pritam Singh's testimony, his instructions to Raeesah Khan were to "take ownership and responsibility" and that she would not be judged. Somehow, according to her, these were license to double down on that lie later in Parliament. I'm not sure how "take ownership and responsibility" translates to a choice for anyone to continue lying in Parliament. Maybe to a complete child. But this is not a child we are talking about. This is a democratically elected Member of Parliament.

Clear and unambiguous
instructions.

Could Pritam Singh have been more explicit about ensuring that Khan clarified her falsehood? Sure. Should he have to? Absolutely not. Remember, this is not a child we are talking about.

But this is the thing about operating in a professional environment. Sometimes, you feel that certain things go without saying. And this can go badly.

As a software developer, I find myself having to check the input that users give me via the system. Of course, I feel that anyone with even an ounce of common sense would be responsible about faulty data and do their due diligence before sending me a potential mess that I have to clean up later. Unfortunately, people tend to do what they think they can get away with, especially if their hands are full. Therefore, now my correspondence with users contain explicit (sometimes sternly so) instructions to ensure cleanliness of data before handing it off to me. Should I have to remind people to do their goddamn jobs? Fuck, no. But this is the reality I have to deal with.

3. The Price of Authority

Regardless of whether or not you believe that Pritam Singh was complicit in the lies that Raeesah Khan continued to tell in Parliament, there is one glaring, inescapable fact: he is the leader of the Worker's Party. The buck stops with him. As such, Khan's membership in the party is at least partially his fault. As for her candidacy in 2019, that is definitely his fault. The fact that such a flawed character ended up as a Member of Parliament, is down to his failure in terms of character judgement.

Real leaders
don't play
the blame game.

That is the price of authority. When something happens, you ultimately have to shoulder some of the blame, if not all of it.

In tech, I have encountered CTOs and team leads who love pointing fingers, not understanding how completely stupid this makes themselves look. They are in charge; everything is their fault. Even if they did not personally write faulty bug-ridden code, they are responsible for approving it. If bugs persist in the product, they have to shoulder the blame for not addressing the issue sooner.

They are in charge. The buck stops with them. Failure to accept responsibility is poor leadership. Very poor.

4. Due Process

The long and drawn out process of the COP has had mixed reactions. From supporters of the Worker's Party, mental fatigue and lamentation that this was a waste of time and taxpayers' money. From supporters of the People's Action Party, baying for blood. Both predictably so. But these are simple-minded villagers masquerading as political commentators, and their views are inconsequential.

Instead, consider this: why did the PAP make this public, and publicize these videos on YouTube? Bear in mind that Singapore is a democracy. As such, we are under certain obligations to due process, no matter how onerous and how tiresome the process may be. You cannot claim to be a democracy and yet eschew the portions that are unpalatable. That is simply not how things work.

Due process is important.

Singapore's Government needed to show the rest of the world just how seriously we take democracy. Singapore's image as a stable and conducive place to conduct business, was at stake.

Due process is another big factor in Agile Methodology. Code sprints are capped off with code reviews. System Integrated Testing. User Acceptance Testing. You cannot claim to be "Agile" and yet do away with integral components of said Methodology.

Would I get more work done without having to deal with Sprints? Are Retrospectives a gigantic pain in the ass? Undoubtedly. Yet, they are necessary.

5. Layperson Expectations

There are more than thirty hours of footage on YouTube. Some enterprising souls have created clickbait by making compilations of all the heated moments. Viewers gravitate towards these, so as to save themselves hours of listening to it all, and entertain themselves by pointing out how Edwin Tong stutters at some parts, or jeer at Pritam Singh, depending on which party they support. And hearing Pritam Singh utter "agree" and more often, "disagree" or "completely disagree".

However, if they took the trouble to actually listen to the entire proceedings, they would find it much less adversarial than the short compilations suggest. For the most part, Tong and Singh are pretty respectful and gentlemanly towards each other - cordial even. There are even parts where Singh elicits a chuckle from Tong, and Tong makes a corny joke or two.

But no - viewers just want the political theater from that little "PAP vs WP" narrative they have in their head. As mentioned before, these are pitchfork-wielding, simple-minded villagers at heart, and they're incapable of seeing anything else.

This isn't magic.

It is much the same in software development. Laypeople only see the end result. They do not see the trial and error, the painstaking process, and the mess that results when requirements are unclear or worse, ambiguous.

What we do is not magic. If something does not make sense outside of the system, it will still not make sense in a program. Programs run on logic, not fantasy. But because laypeople are blind to the process, they may have expectations that can be divorced from reality.

To conclude...

I'm not entirely sure how I managed to sit through all that footage, and actually make sense of it all. But like it or not, this is Singapore's Parliamentary process at work. Perhaps I managed to endure all that precisely because I was thinking like a software developer. And as such, this managed to retain my attention.

"Agree? Disagree?"
T___T

Ten Lessons From The Art Of War Applied To Software Development

Few written works are as universally well-known as The Art of War by Sun Tzu. This military treatise has been repeatedly translated, referenced, read and reread through the millennia that have followed since its creation.

The wisdom contained within its pages are transferable to many situations, not just war. It could even be said that all life is war, in some form or other. Just because one is not engaged in conflict currently, does not mean that one is not at war. In fact, we remain in a state of war precisely so that we do not need to fight. After all, si vis pacem, para bellum. If you want peace, prepare for war.

Today, I would like to attempt what many bloggers before me have done before. I will attempt to apply The Art of War to software development. For this, I will be using the version translated by Lionel Giles. (I can read the characters that Sun Tzu originally wrote, but his grammar may as well be an entirely new language. Therefore, why reinvent the wheel?)

I will be listing ten lessons from this text, and the original and translated phrases that deliver these lessons.

1. Duration in Software Development

From Chapter 2: WAGING WAR

故兵贵胜，不贵久

In war, then, let your great object be victory, not lengthy campaigns.

From Chapter 2: WAGING WAR

故兵聞拙速，未睹巧之久也；夫兵久而國利者，未之有也。

Thus, though we have heard of stupid haste in war, cleverness has never been seen associated with long delays. There is no instance of a country having benefited from prolonged warfare.

A software project costs more the longer it takes to arrive at completion. The cost is not merely financial; waning interest, attention span of participants and evolving situations are all costs. You want the software to still be relevant and useful by the time it is completed.

Waiting.

This is why we now have short sprints in Agile methodology as opposed to what used to be a longer Software Development Life Cycle. The process is shorter and more iterative. It keeps the minds of those involved, active where the project is concerned. Long delays disrupt momentum.

Software objectives need to be more immediate than long-term. Developers can see the payoff of their efforts and this provides better visibility as to how the software project is taking shape. This is vastly superior to a long and drawn-out Requirements Gathering phase. One could argue that it is better to do it once and do it right; however, the definition of "right" may change drastically after a long delay. It is better to ship an incomplete but useful product and make amendments later, than potentially be forever stuck in development hell.

2. The Principle of Good Enough

From Chapter 3: ATTACK BY STRATEGEM

知可以战与不可以战者胜

He will win who knows when to fight and when not to fight.

From Chapter 3: ATTACK BY STRATEGEM

不战而屈人之兵，善之善者也。

Supreme excellence consists in breaking the enemy's spirit without fighting.

Professionally, code requires a purpose. We should not code for the sake of coding.

Professionally, best practices require a purpose. We should not follow best practices simply for the sake of following them.

Sometimes you have to fight;
other times you have to chill.

Sometimes, the best way to be a software developer is not to think like a software developer. Not every cause needs to be pursued. Not every database table needs to be fully normalized. Not everything requires a high-tech, automated solution.

Know when to code, and when not to code. Know when enough, is enough.

3. The CTO, Team Lead or Project Manager

From Chapter 3: ATTACK BY STRATEGEM

夫将者，国之辅也。辅周则国必强，辅隙则国必弱。

Now the general is the bulwark of the State; if the bulwark is complete at all points; the State will be strong; if the bulwark is weak, the State will be weak.

This lesson is obvious. Software projects do not fail because of inferior technology, or inferior programmers. They fail due to poor leadership. That's not to say that inferior programmers cannot be blamed; but pushing the blame on inferior workmanship is, in itself, poor leadership.

Understand authority.

Thus, whomever is placed in charge must not only be competent, they must understand authority.

If you are in a position of authority, it's always your fault. That is the price of leadership. Anyone who fails to understand that, has no business being in his or her position.

4. Business goals over software goals

From Chapter 12: ATTACK BY FIRE

主不可以怒而兴师，将不可以愠而致战。合于利而动，不合于利而止。怒可以复喜，愠可以复悦，亡国不可以复存，死者不可以复生。故明君慎之，良将警之。此安国全军之道也。

No ruler should put troops into the field merely to gratify his own spleen; no general should fight a battle simply out of pique. If it is to your advantage, make a forward move; if not, stay where you are. Anger may in time change to gladness; vexation may be succeeded by content. But a kingdom that has once been destroyed can never come again into being; nor can the dead ever be brought back to life. Hence the enlightened ruler is heedful, and the good general full of caution. This is the way to keep a country at peace and an army intact.

Developers tend towards writing software. That is, after all, our bread and butter. However, sometimes we focus too much on writing good code, when our goal should be to meet business objectives. Time spent on unproductive pursuits is time that can never be retrieved.

Once broken...

It is good to obey best practices when coding. No developer should deliberately write bad code if the situation does not call for it. But we should never let our desire to write clean, beautiful well-organized code to override the need to add value. Remember that as software developers, our job isn't to create art. If ugly code will get to the point faster, sometimes, we have to code ugly. The goals of the business trump everything else.

Code is just code. Without the business, there is no code. Software developers are not central to the business development. Our goals cannot be prioritized over business goals. We need to get over ourselves in order to contribute effectively.

5. Shut up and code

From Chapter 4: TACTICAL DISPOSITIONS

古之所谓善战者，胜于易胜者也。故善战之胜也，无智名，无勇功

What the ancients called a clever fighter is one who not only wins, but excels at winning with ease. Hence his victories bring him neither reputation for wisdom nor credit for courage.

From Chapter 10: TERRAIN

故进不求名，退不避罪，惟人是保，而利合于主，国之宝也。

He who advances without seeking fame, Who retreats without escaping blame, He whose one aim is to protect his people and serve his lord, The man is a jewel of the Realm.

One of the greatest downfalls of the software developer is ego.

A developer who constantly tries to claim credit for work, who does not take responsibility for failure, is a detriment to the team. A developer who is obsessed with appearing competent should perhaps be more concerned with being competent.

Fly under the radar.

When you can make your job look easy, when you can make people think that any idiot could do your job, that is mark of a true master of his craft. Developers need to stop tooting their own horns. They need to stop talking about how complicated their jobs are and how only trained professionals can do it. Just shut up and code.

6. Programming elements

From Chapter 5: ENERGY

声不过五，五声之变，不可胜听也。色不过五，五色之变，不可胜观也。味不过五，五味之变，不可胜尝也。

There are not more than five musical notes, yet the combinations of these five give rise to more melodies than can ever be heard. There are not more than five primary colors (blue, yellow, red, white and black) yet in combination they produce more hues than can ever be seen. There are not more than five cardinal tastes (sour, acrid, salt, sweet, bitter), yet combinations of them yield more flavors than can ever be tasted.

What else could this remind software developers of, but programming itself?

There are only so many data types - integers, strings, floats and Booleans.

There are only so many data structures - linked lists, trees, stacks, heaps and queues.

Infinite melodies.

There are only so many constructs. If-else blocks and Case statements. Iterative loops such as For, While and Do-while. And in the case of Ruby, Do-until.

But there are countless ways to put them all together. Infinite ways to achieve the result you want. Some are brilliant, some are merely adequate, and some are terrible. But that all also depends on the context upon which a programmer builds his or her program.

That is the marvel of programming. The building blocks are so elementary, but their combinations are so varied.

7. Divide And Conquer

From Chapter 6: WEAK POINTS AND STRONG

我专为一，敌分为十，是以十攻其一也，则我众而敌寡﹔

We can form a single united body, while the enemy must split up into fractions. Hence there will be a whole pitted against separate parts of a whole, which means we will be many to the enemy's few.

This is a classic example of breaking down a large software problem into manageable chunks, and tackling each portion individually. When we solve a bit of the problem at a time, that is the Divide And Conquer approach.

Many to their few.

This breaking down of larger software projects is also part of the Agile methodology.

There is also a lead-in into the strategy of first grabbing the low-hanging fruit. Once the easiest bits of the puzzle are achieved, this has the effect of making the entire project look significantly smaller and consequently, more doable.

8. Flexibility

From Chapter 6: WEAK POINTS AND STRONG

故其战胜不复，而应形于无穷。夫兵形象水，水之形避高而趋下，兵之形，避实而击虚，水因地而制流，兵应敌而制胜。故兵无常势，水无常形，能因敌变化而取胜者，谓之神。

Do not repeat the tactics which have gained you one victory, but let your methods be regulated by the infinite variety of circumstances. Military tactics are like unto water; for water in it snatural course runs away from high places and hastens downwards. So in war, the way is to avoid what is strong and to strike at what is weak. Water shapes its course according to the nature of the ground over which it flows; the soldier works out his victory on relation to the foe whom he is facing. Therefore, just as water retains no constant shape, so in warfare there are no constant conditions. He who can modify his tactics in relation to his opponent and thereby succeed in winning, may be called a heaven-born captain.

Some developers have this limitation - they manage to solve one problem with a solution and thereafter, every time they encounter any problem, they try to apply the same solution to it. They build themselves this figurative hammer, and everything begins looking like a nail.

Be flexible like water.

Just as there are no constant conditions, there are no blanket solutions. Everything is context. The solution should reflect the context upon which the problem statement is derived. Developers should choose the right tools for the job, and tailor their approach according to the job.

Without that flexibility, we are not software developers. We are mere automatons, and doomed to failure.

9. Defensive programming

From Chapter 8: VARIATION IN TACTICS

故用兵之法，无恃其不来，恃吾有以待也﹔无恃其不攻，恃吾有所不可攻也。

The art of war teaches us to rely not on the likelihood of the enemy's not coming, but on our own readiness to receive him; not on the chance of him not attacking, but rather on the fact that we have made our position unassailable.

This should be the underlying principle of all cybersecurity. However, just in the context of software development, preparedness is the key. We cater for all the cases we can think of, and preemptively ward off as many undesirable scenarios as we can.

Prepare for the enemy.

For example, we write unit tests for code, to screen out any nasty surprises that might emerge. On a smaller scale, if we have to deal with numbers, we test for negative values. And if we have to perform division of any kind, we first ensure that the divisor is not zero. When parsing data for insertion into a database, we sanitize it. When retrieving data from a database, we also sanitize it before use. Just in case.

We absolutely do not code while hoping fervently that nothing goes wrong; in fact, we assume that anything that can go wrong, will go wrong. We assume that people will attempt to intercept data, that bots will send forged requests, that even well-meaning users will make potentially catastrophic mistakes.

10. User Acceptance Testing

From Chapter 13: THE USE OF SPIES

先知者，不可取于鬼神，不可象于事，不可验于度。

Now this foreknowledge cannot be elicited from spirits; it cannot be obtained inductively from experience, nor by any deductive calculation. Knowledge of the enemy's dispositions can only be obtained from other men.

The science of user interfaces can be deeply complex. No one knows for certain how any demographic of users is going to respond to a user interface design. This is highly subjective and therefore we can only know by gathering this information from careful study of users. The users will tell you what you need to know, by the way they navigate the system to accomplish different tasks.

Some information can't be
calculated.

How easy is it for them? How quickly do they navigate the system? How many errors do they make?

These are the questions that cannot be calculated beforehand - the information, once again, has to be derived from study. From observing actual users.

Conclusion

There are so many lessons even upon rereading The Art of War for what feels like the millionth time, that limiting this listicle to only ten items, feels simplistic. Yet these are the lessons that I felt resonated most as a software developer.

Also, this is all completely subjective. A different software developer may take away entirely different lessons. That, too, is the beauty of The Art of War.

Prepare for war,
T___T

Thoughts On The Ongoing Millennial-Boomer War (Part 2/2)

OK! We've seen the millenial point of view, agreed with some of it and ripped into the rest. Boomers are going under the microscope next.

What Boomers say about Millennials

The younger generations are soft and spoilt. They're irresponsible, whiny snowflakes. They have no idea how hard things were back in the day. They're idealistic and self-righteous, and think that they can change the world by undoing the past. But their arrogance, combined with naivete, is their undoing. The world is what it is. What makes them think they can change it? They have no consistency. They're so entitled and don't believe in the values of hard work and loyalty, changing jobs on a whim. Young people just don't know what they want in life.

Why Boomers are right

Some things are not era-specific. Some principles apply regardless of the times we are currently living in. And it's these principles that make Boomers valuable, if they have been consistently applying them to their lives. Millennials would do well not to dismiss Boomers out of hand just because their words and experiences come from a different era. Not only is that lazy, it is foolhardy.

The Boomers also have a point about this overdoing of Woke Culture that seems to be a hallmark of this generation. It's one thing to advocate for awareness of Climate Change, Minority Rights, Social Justice, and so on. But digging through someone's tweets from ten years ago, and holding them accountable for those? Going way back into ancient history to attack long-dead personalities? That is so banal. Shouldn't the leaders of the future be more concerned with, y'know, the future?

Plant a seed of change,
not a tree.

Change is a natural aspect of our reality. Change occurs regardless of anyone's attempts to stop it. It also occurs at its own speed regardless of attempts to speed it up. So trying to effect change for the sake of change itself, is unproductive. If the younger generation pushes for change and encounters pushback, maybe it's time to consider that this isn't the time for that particular change. The overemphasis on things like Affirmative Action and erasure of potentially offensive terms in tech is what I call "trying too hard", and it's counter-productive.

Get the seeds of change right, and change will happen. Millennials need to stop trying to produce an entire tree overnight. There's a process to this shit!

Why Boomers are wrong

No matter what you may think of Millennials, remember that they are now the dominant majority demographic where the workforce is concerned. They will, by default, be the ones charting the course for the future. Who else is gonna do it? You, Boomers? Face it; your time was over ten years back. Whatever mistakes Millennials may or may not make, they are the ones who are going to have to live with it. Statistically, you are going to be long gone by then. You have no skin in the game. So stop trying to exercise influence over a world which you won't have to be responsible for.

You probably think Millennials change their minds way too often, as compared to the days where you stuck to one course your entire lives and never deviated? It's frightening that this lack of flexibility is actually considered a virtue.

People change their minds more often now because they can. It's called having options. Let's be real - if you had that many options back in the day, would you be doing what you're doing now? Not having options is not the same as being steadfast. The internet has opened up a multitude of options. There are multiple paths to success, and as the conditions for success change, so too, must the course you are on.

Agility is a mindset that is encouraged in the workforce today. The Agile Methodology is a concept bred in software and now business - that one must constantly make adjustments to work plans based on ever-evolving conditions. If people with static mindsets were in charge, we would not be seeing the great leaps in progress that we're seeing today.

Are Millennials really lazy?

As for knowing the value of hard work, quit the bullshit myth that Milllennials are lazy. They are just as capable of working hard... except that unlike you, apparently, they want their hard work to mean something. Hard work for the sake of hard work is even dumber than change for the sake of change. In your day, hard work was the only value you brought to the table. But in this day and age, any idiot can be hardworking. So if you want to get ahead, you better have a hell lot more to offer than your sweat, blood and tears.

And finally...

"In my day..." doesn't help your case at all. You're trying to make a point as to why things should be done a certain way. Even if people were interested in a history lesson, a history lesson from your personal point of view is pretty fucking useless except for entertainment purposes.

Also, stop with the unsolicited advice. If your advice was so valuable, people would be paying you to talk. Are people paying you to talk? No? Well, take that as a sign from the universe.

The war continues!

Nothing I've said here is going to change anything. People are going to think what they think and do what they do, even if it is absolutely stupid. It's a very human thing.

Did I mention I'm taking no sides here? Millennials and Boomers both suck. Seriously. Honestly, what kind of idiot thinks that simply being born in a particular era makes them special?

The world continues to spin no matter how important you think your perspectives are. Millennials, one day you will be those Boomers you love to shit on. Boomers, one day you will be corpses and distant memories. Get over yourselves, guys.

Tale as old as time!
T___T

Reference Review: How To Kill The Scrum Monster

Often, it is not enough to simply experience something. To truly digest the experience, it is advisable to familiarize oneself with the theory behind that experience. The past decade of my career, saw me experience firsthand several interesting styles of Management, and work practices. And I didn't want the experience to be wasted by my ignorance of the underlying concepts.

During a rare investigation into tech practices - Agile practices, in particular - I found myself reading some material - one of them the evocatively-titled How to kill the Scrum Monster by Ilya Bibik.

This book is billed as a quick guide to the role of the Scrum Master and Agile Methodology. The author has spent a respectable amount of time as a Scrum Master, and attempts to condense his experience in an educational format, explaining what the Agile methodology is in tech, and the role of the Scrum Master in that context.

The Premise

Things start off with an overview of Agile methodologies, Scrum in particular. This segues into an examination of the role of the Scrum Master, and what it involves.

The Aesthetics

I'll be honest - I judged this book by its cover. There's just something intensely relatable about defining Scrum as some kind of monster that needs to be killed. The layout of its contents, however, is pretty academic in nature. And by that, I mean it reads like a lecture rather than a fantasy novel, with many things that would not look out of place in a textbook. That's by no means a bad thing, however.

The Experience

This is a mercifully fast read. It is intended to be easy to digest. While the author isn't exactly the most skilled in the English language, if you can look past that particular flaw, there is a fair amount of knowledge to be found within these pages.

The Interface

The graphs and charts are not all that hard to understand. In fact, they can be safely ignored. Chapters and sections are well-structured. It's been kept as simple as possible.

What I liked

The explanations behind the terminology used in Agile, and the underlying concepts, are pretty adequate, and potentially useful if you're reading this without any idea of what Agile is.

This book does not just cover the role of the Scrum Master. It branches into other hybrid roles such as Scrum Master/Developer and Scrum Master/Product Owner. It also examines the relation of the Scrum Master to other members of an Agile team.

There is a section devoted entirely to case studies, scenarios and proposed solutions. Not only does the author put forward scenarios that feel real, he even takes the trouble to explain the principles and politics behind the solutions proposed.

What I didn't

The copywriting, editing and general use of grammar are awful. In some places, words are spelled wrongly and sentences are awkwardly structured. It's pervasive and glaring enough that this is a real sticking point.

There's one particular spot that sticks out like a sore thumb. In the section where inter-team conflicts are discussed, the author describes one type of conflict as "pure evil". This is quite unprofessional; and jarring precisely because for the most part in the book, he has successfully avoided the use of such emotive superlatives and kept his language neutral. Talk about mood whiplash!

The book is not a particularly interesting read. This may be due to the author's lack of proficiency in the English language. He's certainly earnest enough, but one senses that he's no salesman.

Many of the charts seem superfluous. In some places they can be so simplistic that one suspects that they were placed there as filler.

Conclusion

Ilya Bibik's work isn't terrible. As an informative source, it has its uses. For academic purposes, it does serve as a quick guide. It's just hard to read if you're particular about the English language. For starters, one could certainly do worse.

However, if you're looking for a well-written book, you may want to look elsewhere.

My Rating

5.5 / 10

Stay Scrum-tious!
T___T

Reference Review: The Mythical Man-month: Essays on Software Engineering

Over the past few years, I've had the pleasure of finally reading the project management classic, The Mythical Man-Month: Essays on Software Engineering by Frederick P Brooks, Jr, also the man behind this infamous quote known as Brooks's Law.

"Adding manpower to a late software project makes it later."

In fact, this very quote is featured in one of the book's chapters, along with many other little gems. The particular version I read was The Anniversary Edition, which featured four new chapters, and new thoughts from the author.

Now, I've read this book several times, and each time it seems I unlock another piece of the great mystery of software development. I'm not shy to say that devouring it in one sitting is a virtual impossibility for me; value takes time to unpack. It took me years to write this review, and I'm not sure I'll ever truly complete it.

I first learned about The Mythical Man-Month when I read a source online that likened the software development process to childbirth. The person who made that assertion told me that he had obtained that nugget of wisdom from The Mythical Man-Month.

And here, I found it.

"When a task cannot be partitioned because of sequential constraints, the application of more effort has no effect on the schedule. The bearing of a child takes nine months, no matter how many women are assigned."

The Premise

The Mythical Man-Month is a collection of musings written back in 1995 or before, dealing with the nature of managing a software project. Brooks draws upon his experience in managing the hugely complex software system, OS/360.

He starts off with a description of what a Program is, and how it scales up into a Programming Product, a Programming System and finally a Programming Systems Product. That's elementary enough, and things get a lot deeper from there.

The Aesthetics

Not so many to speak of. There are some nice prints and photos of art exhibits preceding every chapter, though I'd venture to say those are merely fluff. The visuals are otherwise very much non-descript.

The Experience

Given that this was written way back then, the language used tends to feel a bit antiquated. Though the concepts aren't. Brooks has an elegant yet chummy way of writing that puts you at ease, or to sleep - pick one. He comes across as calm and logical, pretty much what any kind of Manager needs to be.

Brought me back to simpler times, where men wore ties and women wore skirts. It's a bit antiquated, yes, but the truths in there are ageless.

The Interface

While the book itself is a somewhat easy read, it's sometimes hard to decipher the accompanying graphs and charts. Which is a pity, because I suspect that understanding of those would have greatly deepened the insight imparted by Brooks's writing.

What I liked

In his essay, The Tar Pit, Brooks puts eloquently into words what I love about my industry, and why I've stayed in it so long: making stuff.

First is the sheer joy of making things. The child delights in his mudpie, so the adult enjoys building things, especially things of his own design.

Second is the pleasure of making things that are useful to other people. Deep within, we want others to use our work and to find it helpful.

Little essential truths that are only tangential to the topic. For example, in the chapter The Other Face, he discusses the importance of documentation, but also acknowledges, via the use of an anecdote, that while everybody understands the need for documentation, it's more important to know how to document. So instead of preaching its importance, he proceeds to explain how.

This quote, uttered in the context of Code Reuse. That's just zen, it is.

The best way to attack the essence of building software is not to build it at all.

Plan To Throw One Away is a fascinating chapter about trial and error. It's eerily reminiscent of my own efforts at writing mini-games at times.

Discussed in the chapter Hatching a Catastrophe, the author's words again strike a deep chord.

Conversely,when the manager knows his boss will accept status reports without panic or preemption, he comes to give honest appraisals.

Indeed, how many things are swept under the carpet simply because Management have a tendency to overreact? People need to know that their superiors are in control. When said superiors panic, it's not only the project that suffers; all future confidence in a leader is strained.

There's an outline in point form near the end of the book, encapsulating all relevant points made by Brooks, just in case the reader doesn't feel like wading through a sea of old-style English. That's pretty neat.

What I didn't

While Brooks's piece on a small surgical team being assembled to build software does sound very interesting, I'm not really sure how practical it is in this day and age. To be fair, it does read like a very early version of a cross-functional team in the Agile Manifesto.

Brooks has a valid point in Tower of Babel - communication is important. Problem is, he spends a really long time belaboring the point and I really struggled to keep up.

In the chapter The Other Face, Brooks speaks of the importance of documentation. I tend to agree, but I'm ambivalent about the statement.

In fact, flow charting is more preached than practiced. I have never seen an experienced programmer who routinely made detailed flowcharts before beginning to write programs.

Conclusion

This book is a joy to read and could very well be the Software Project Management equivalent of Sun Tzu's Art of War. As a reference on the human elements of software development, it's in a class of its own.

The man-month is a fallacious and dangerous myth, for it implies that men and months are interchangeable.

Sure, a lot of it comes across as common sense like the quote above. But it's common sense that is very well presented. Decades after it was first published, The Mythical Man-Month continues to be just as relevant, and that in itself is an anomaly in the fast-evolving world of software today. Part of this could be due to the fact that Brooks discusses human nature as much as he discusses software, and we all know that, unlike technology, human nature doesn't change.

My Rating

9 / 10

A book of mythical proportions,
T___T