Whenever I get a random call or e-mail from a recruiter, I tend to think about Van Halen and brown M&Ms. Here’s the Snopes page for those of you who aren’t familiar with the connection between the two.

TL;DR:

• Van Halen’s concert contract contains a clause that requires a bowl of M&Ms in the backstage area with the brown ones removed.
• Turns out there’s a reason for that clause (unlike some celebrities’ riders): it’s an easy way to detect if the promoters have read and followed the terms. When dealing with tonnes of expensive equipment, failing to follow just a single part of the contract can lead to life threatening situations.

I have my own brown M&Ms clauses that let me check if a recruiter is worth my time.

The first is pretty obvious. I haven’t uploaded my profile or resume at any job hunting site so that should mean that I’m not looking for work. Thus, I ignore any recruiter who simply assumes that I’m looking for a job.

The second one is somewhat trickier, but it’s still pretty easy to see. The hint is there on top of my CV: a link to my website. There’s a wealth of information there and it, along with my CV, give you enough info to see if I’m a good match to your position opening.

There’s also a couple of lines there (and a couple of clicks away) that will make me bluntly ignore you if you blatantly ignore them.

I don’t care about your high compensation package, your career path, or your laid back environment; if you can’t answer that single request, I have no use for your company and your company has no use for me.

My parents don’t get along with me but once in a while some topics come up where I can join in the discussion.

The topic in question was about an aunt worrying about one of my cousins, namely, the lack of direction in his life. He graduated college, but unfortunately failed the board exam. Which is kind of expected: from what I’ve heard, he spends his time just lazing around the house or hanging around with friends (most likely playing DotA). He’s also somewhat spoiled; he only got his OJT work because his mom pulled some strings in her company, and he couldn’t get a job on his own now that he’s graduated (not to mention that his mom even had to accompany him to PRC to see his board exam results ಠ_ಠ).

In short, he’s exactly the opposite of me.

(Well, aside from the lazing around the house part which I did for over a year. But then again, I used my savings then and didn’t take a cent from my folks.)

Anyway, even though I’m usually quiet about these discussions, I couldn’t help but give my (snarky) 2 cents:

“Why don’t they let him apply in McDonald’s or something?”

It was only later that I realized that my suggestion actually made sense.

First off, unlike working in call centers or the like, he has no excuse not to be able to review for his board exams after work hours. Sure, the work can be mind numbing, but it’s not as bad as what you’d get from fielding calls from irate customers day in day out.

Another benefit of taking menial labor first is that he would learn how to deal with people better. That’s what I got when I took the night shift as an internet cafe attendant back when I was in college. It didn’t pay much, but at least I got all the internet and gaming that I wouldn’t get had I settled with applying as a TA or something. But the best thing I got there was the experience of dealing with all kinds of people, whether it’s the nice guys who live in the nearby dorm who you could play StarCraft or CS with, or the obnoxious guy who looks at porn all the time and treats you rudely on the way out, or the desperate students who need to finish their presentations/papers and ask you for technical help.

It might be unfair to assume that my cousin is that naive that he doesn’t know how to deal with people, but from what I’ve been hearing, it’s not that unlikely. More experience, even thought it’s not related to his engineering degree, will really help him later in life.

And finally, if the family is up to it, they can use this job as a reason to cut off all financial support outside lodging and free meals. In other words, this can be a wake-up call, a swift kick in the ass to get him on his feet and start acting like a real citizen with a college degree.

As I said above, he’s the opposite of me. And this really annoys me. The main reason why I don’t get along with my folks anymore is that they didn’t spoil me. Now this would be nice had they informed me of better options to deal with our income level, like, say, encourage me to get a part-time job when I was in high school (doing MPs for college students, LOL) to complement my allowance and allow me to buy the things I want or do the things I want to do. But they didn’t — they just ingrained into my head that we were poor and I can’t do anything about it, thus limiting my horizons/experiences until I got into college.

This is what drove me to strive harder. Getting good grades and getting a decent job (even before graduating) with very little support from my parents was my way of telling them how wrong they were in raising me.

If my cousin doesn’t learn how to cut himself away from his family and learn to live on his own strength, he won’t get very far in his life. Working in a fast food joint is nothing compared to what I did in the past decade, but it’s a good start.

In the field of management, there are two principles about incompetence that every manager must know.

First is the Peter Principle.

The Peter Principle is the principle that “in a hierarchy every employee tends to rise to their level of incompetence”.

One good example in the IT industry is when good developers are promoted to management positions. It would be good if those developers have good management skills, but most of the time they’re not really suited for managing people.

This produces two unpleasant side-effects: first, the company gets an incompetent manager, and second, the company loses a good developer.

There are a bunch of ways to get around this problem. One good approach is to make it culturally acceptable inside the company to remain a developer, like having separate career ladders for developers and managers. Most of the time, the only reason why a developer wants to be promoted to a manager is because the latter pays more and gets better perks. With a career ladder for developers, those developers can instead choose to remain developers and still be able to get promoted to a position with better perks (e.g. senior developer).

Another way to get around the Peter Principle is to carefully manage how developers are promoted to management positions. This can involve screening (only those people that show potential in managing are considered) and dedicated training. At the worst case, they company should be able to own up for their failed judgment in case they promoted the wrong person to a management role.

–

The second principle is the Dunning–Kruger effect.

Kruger and Dunning proposed that, for a given skill, incompetent people will:

1. tend to overestimate their own level of skill;
2. fail to recognize genuine skill in others;
3. fail to recognize the extremity of their inadequacy;
4. recognize and acknowledge their own previous lack of skill, if they can be trained to substantially improve.

In other words, incompetent people tend to be incompetent enough that they don’t realize their incompetence.

While the Wikipedia article goes on to say that this effect is prevalent in North American subjects, it shouldn’t take much to see that this effect is also evident among Filipino workers (no thanks to our pwede na attitude).

–

Ironically (or coincidentally?), a good number of “managers” I’ve met aren’t aware of these principles.

It’s not that I don’t have the skills needed to be employed; it’s actually the opposite: even though I’m not actively looking for a job, people still come to me asking if I could work for them. My part time teaching and Rails “consultancy” gigs fall under this (i.e. I never “applied” for them formally), and I’m getting emails requesting for interviews from local companies once in a while.

The reason I’m not taking any full-time job offers is different:

It’s been over a year and a half since I left my previous full-time job and I still haven’t fully recovered from burnout. I’m not confident that I’d be able to do software development “grunt-work” at peak performance for more than a few weeks on end.

After a year’s hiatus, I guess it’s safe to say that I’ve suffered permanent damage from my burnout.

—

Looking back, the main turning point of my career was on January 2006.

I was supposed to be transferred to another project. Having endured a year and a half of working on a really difficult enterprise system that was going nowhere, I knew my best bet was to make my programs relatively bug free. This way, I could be moved to another project (since they don’t need me around anymore to fix my programs) and get a fresh start. One bad project should be offset by a good project, right?

As you might expect, my plan backfired. Not only was I pulled back from that new project, I was also assigned to maintain the programs of another developer in my module while he gets to be transferred to another project.

Best. Reward. Ever.

While the whole resource allocation FUBAR was eventually fixed (that developer was also pulled back), the whole incident was a turning point: that was the time that I was pushed beyond my limits.

I was never known to be a weak-willed individual. In college, I had the reputation of surviving (and thriving) in the face of adversity. I’m the guy who graduated with honors without joining a CS-related organization and without having more than 10 friends in the department.

This sense of pride and confidence eventually led to my downfall. I thought this “over the edge” thing was just going to be short and that I could just “hang on” and “bite the bullet” until it passes.

I didn’t know that I had to “hang on” for more than half a year.

—

In hindsight, after reading management and psychology articles on burnout, I’d say that the things I did back then to deal with the problem were the best things you could do in that situation.

Too bad they all failed.

Probably the best thing you can do to deal with burnout is to get a “lifeline”, a person or a group of people who can support you. By listening to your problems and giving sound advice, they could either prevent you from hitting rock bottom, or help you get back up from burnout.

I tried getting lifelines, but there’s this sad fact in the way: In my groups of friends, I’m always a lifeline. I’m the guy you approach when you’ve got problems, whether it’s computer problems, financial problems, or random life problems. Not the other way around.

And this made asking for help really awkward. One notable instance was when I tried approaching a friend that I was sure was good enough to be a lifeline, but then she mistook my “subtle cries for help” as “lame attempts at courting”. That didn’t end well.

So with lifelines out of the question, there’s the cliched advice: “find a way to release your frustrations”.

Nope, didn’t work. The scars on my knuckles prove that venting your anger violently to concrete walls doesn’t help much when you’re burned out.

Then there’s the “exercise will give your brain happy chemicals to help you get out of depression”. And so I hit the gym. Sadly, unlike normal people, those “happy chemicals” don’t work on my brain as advertised. But hey, at least I lost 15 pounds in 2006!

So I gambled with stuff that would have solved my burnout but I lost. Was there anything else I could’ve done at that time?

—

Well, there is one thing that I didn’t try back then:

File for resignation that day in January.

Looking back, I would never have considered doing something as drastic as resigning. But also, hindsight tells me that that move actually makes sense: all of the reasons why I hung on were for naught.

Pride?
The pride you’ll save is nothing compared to the passion that you’ll lose.

Personal redemption?
Thanks to your burnout, you won’t be able to redeem yourself. You won’t get that big project that would compensate for your failed first project. You won’t even get promoted.

Chance to save others from the same fate in the future?
You won’t get promoted. Ergo, you won’t have the opportunity to affect how the management does things.

That cute co-worker you’ve been fond of?
She’ll just shoot you down before you even get serious with her.

I’m not saying that the second half of my stay in my previous company was entirely useless. Even as a burned out employee, I still learned a fair amount of new skills and knowledge in those two years. Things like full-time teaching and interviewing, Linux administration for project deployment, integrating payment into a system, design patterns and refactoring, and so on.

But thinking about it, I probably would have learned all those skills better had I resigned in Jan 2006, took a 3 month break to recharge, and took a job at another company. The teaching and interviewing practice might come a bit later, but that’s a small price to pay when you take into account that I’ve already lost around 2 years of my life to burnout.

—

To sum things up, burnout is a race against time. Once you start having the symptoms, you only have a short amount of time to come up with a solution before you get a full blown case.

What you do in that span of time will decide whether you’d save your career or lose it.

My suggestion? Build strong relationships with lifelines before you set out working yourself to death. You might fall into the same trap as I did and not be able to find suitable lifelines in time.

IMO, getting lifelines from people on your own project is a bad idea. Since you share the same problems, you’re a lot more likely to drag each others down to depression than to drag each other out of it.

Also, consider resigning if the situation becomes unreasonable. I don’t usually give this advice as I’ve seen a lot of friends and colleagues resign prematurely. But given my experience with burnout and depression, I’d come to realize that resigning too late is even worse than resigning too early.

–

TL;DR

I don’t want to work full time for anyone anymore.

After my first job milked me for what I was worth, I:

• never got promoted
• ruined any chances of getting a love life
• got fired for insubordination
• was eventually forgotten by my friends and forced to make new ones
• lost my reason to live

If you can read this, it means I still have no raison d’etre: a robot zombie, highly skilled but dead inside.

Give me a good reason to live and we’ll talk.

The IT industry isn’t a manufacturing industry: it’s a service industry. Whether you’re a developer, a tester, or an ops/sysad, your purpose isn’t just to code, test, or run programs: your purpose is to make sure those programs work well enough to provide tangible benefits to the user.

But what if the software you’re providing poses some problems or negative effects on the users?

No, I’m not talking about malware or crappy software. I’m actually talking about good software that makes processes and tasks much more efficient than they are.

They can cause problems because some people actually thrive on inefficiency.

These are the back room personnel that block any sort of automation process because they know they will be rendered redundant (i.e. fired) once it’s implemented.

These are the software vendors or internal IT departments that refuse to allow third party companies/consultants to fix or replace their buggy systems because the former earns a lot of profit on support call fees.

–

Sadly, I don’t have any quick advice on dealing with these people. I’m just here to point out again that Software Engineering isn’t about technologies and processes: it’s always about people.

Might as well make a quick post before continuing with work.

I first heard of the Beer Game in a presentation over at InfoQ. While not involving actual beer (boo!), the simple game provides an interesting glimpse at a certain management dilemma.

This game is played by teams of 4 players, each representing a part of a beer distribution supply chain: Factory, Distributor, Wholesaler, Retailer. The object of the game is to minimize the expenses involved in handing orders, namely the costs for stocking and the expenses caused by unfulfilled back orders.

The “kicker” here is that communication between the players are limited, some variations only allow players to order from each other and nothing else, while some variations of the game only allow the players to see the inventory of the next player in the supply chain.

The common result of this is the bullwhip effect: an oscillating period of over and under-stocking. For example:

• Retailer receives an order for 10 cases of beer. To anticipate for future orders, he orders 20 cases of beer from the Wholesaler.
• Having received an order for 20 cases of beer, the Wholesaler orders 40 cases of beer.
• With the same logic, the Distributor orders 80 cases.
• Finally, the Factory produces 160 cases.

Even ignoring the expiration of the product, one can easily see the waste produced by this scheme. There’s the warehouse stocking expenses. There’s also the expense in hiring employees to meet the sudden increase in demand, as well the expense in firing employees and shutting down equipment because of lack of demand.

And so we see the importance of visibility and transparency within a supply chain. When the suppliers upstream have the same information as the Retailer, it’s easier for them to decide how much to actually produce to reduce waste.

Note that this doesn’t just apply to manufacturing. Any situation with a work pipeline (e.g. software development’s Analyst-Developer-QA-Ops) benefits from increased visibility of resource utilization and work load.

There are hundreds of papers and articles on Agile written in the past decade. I don’t want to compete with them so I’ll just be brief with this post. I’ll just go through the core of the subject, namely the Agile Manifesto and the Principles behind the Agile Manifesto, and provide short commentaries on each point.

First off, let’s look at the Agile Manifesto:

We are uncovering better ways of developing
software by doing it and helping others do it.
Through this work we have come to value:

The “by doing it” part is important here because it means that the software development methods that they are advocating came “from the trenches” and have already proven themselves. Contrast this with theoretical or (government) regulated software development practices (e.g. Waterfall Method) which don’t really work well in the real world.

Individuals and interactions over processes and tools

Software is primarily created by knowledge workers; processes and tools may help improve productivity, but they are worthless if the individual developer is taken for granted.

Lack of interaction, as we have seen in Lean, is waste. In traditional software development, teams are divided into “silos”, each with a certain skill (e.g. analysts, programmers, QA, etc) and have limited communication channels. This often results in unaligned understanding of the system, as depicted by the somewhat infamous comic strip below.

Working software over comprehensive documentation

Again, this is similar to Lean’s concept of muda. Comprehensive documentation is often unnecessary, most often a side effect of separating your team into non-interacting silos. Sure, some clients require documentation as part of the deliverables, but in reality, they’re not that important. Besides, if you deliver them too early in the project, they’re likely to be obsolete by the end of the project due to the unseen requirements changes. (Not to mention they’re easy to fake. Take it from a guy who had to do this thing for years.)

In the end, what matters is that the customer gets the working software they want.

Customer collaboration over contract negotiation

The previous two points explains this point well. Learn to work with the user and expect a higher chance of successful projects (and repeat clients).

Responding to change over following a plan

If you can’t understand the simple concept that real-world software projects change a lot in the course of development, look for another field to work in (preferably a non-engineering one because this “problem” is common to all engineering fields). Thus it is imperative for software developers to embrace change rather than mitigate it via restrictive plans.

That is, while there is value in the items on
the right, we value the items on the left more.

Many people blinded by the agile buzzword tend to forget this part of the manifesto and just trash the right side without considering the context. Yes, the right side is still important; don’t forget that agile methodologies also consists of processes (e.g. Scrum) and tools (e.g. kanban), and even documentation (e.g. user stories). The point here is that you should just learn to value the left side more.

Now on to the Principles behind the Agile Manifesto:

We follow these principles:

Our highest priority is to satisfy the customer
through early and continuous delivery
of valuable software.

Welcome changing requirements, even late in
development. Agile processes harness change for
the customer’s competitive advantage.

Deliver working software frequently, from a
couple of weeks to a couple of months, with a
preference to the shorter timescale.

This part focuses on the importance of the customer, without which we software developers won’t have money to put food on our tables.

It’s easy to forget that we’re not merely creating software because the customer wants us to, but that we are making software in order for our customers to gain a competitive advantage. A system delivered half a year late, regardless of whether it had no bugs, might already be too late for our customer–their competitors may have already released a product that was able to capture the market in that time frame.

This is also the reason why continuous delivery of the product is important: this way, the customer can see if the project is going according to plan (and have the ability to steer it early) instead of the usual pray-that-the-system-is-what-we-want at the (single) delivery date. This also gives the user the opportunity to release a not-so-complete product with just enough features before the competitors can capture the market.

Business people and developers must work
together daily throughout the project.

Already explained in the “Individuals and interactions over…” above.

Build projects around motivated individuals.
Give them the environment and support they need,
and trust them to get the job done.

Also explained in the same manifesto line, but this principle also brings to light the futility of micromanaging developers.

The most efficient and effective method of
conveying information to and within a development
team is face-to-face conversation.

Face-to-face conversation is, simply put, far more efficient and effective than phone calls, teleconferences, boardroom meetings, e-mail, and documentation. Having the prototype/working software at hand also helps.

Working software is the primary measure of progress.

Working software, not documentation or filled up Gantt charts, measure the progress of the project. There’s no sense in saying “this module is 80% done” or something like that; that feature or module is either working or not working.

Agile processes promote sustainable development.
The sponsors, developers, and users should be able
to maintain a constant pace indefinitely.

Translation: the managers are there to make sure things move smoothly i.e. not hinder progress through bureaucracy or other stupid things. So are customers. And developers. Heck, everyone that has anything to do with an agile project must work to avoid possible roadblocks.

Continuous attention to technical excellence
and good design enhances agility.

This is why refactoring and other low-level agile practices are important: it’s hard to change software (i.e. be “agile” in the somewhat literal sense) when your design and code base sucks.

Simplicity–the art of maximizing the amount
of work not done–is essential.

Again, we’re back to muda.

A side note, though. Agile wasn’t based on Lean, though the former gets many lessons from latter. Which makes sense because Lean, in its most popular form TPS, works primarily for the manufacturing industry, and software development is not just a manufacturing industry (it’s also partly a service industry).

The best architectures, requirements, and designs
emerge from self-organizing teams.

Translation: they don’t come from following guide books given by governments or certification institutions.

Allow people to work together well and they will eventually find what best suits their project.

At regular intervals, the team reflects on how
to become more effective, then tunes and adjusts
its behavior accordingly.

And here at the end is our looping structure: the feedback, the retrospective, the follow-through. Without this principle, agile is a useless unrepeatable cargo-cult fad buzzword.

–

With this article, I can finally move on to other agile topics… (yay!)

Habit #17 Failing to express gratitude

Dale Carnegie liked to say that the two sweetest words in the English language were a person’s first and last name. He maintained that using them liberally in conversation was the surest way to connect with a person and disarm them. After all, who doesn’t like to hear their name on other people’s list?

I’m not sure Dale was right. To me, the sweetest words in the language are “Thank You.” They’re not only disarming and pleasant to the ear, but they help us avoid so many problems. Like apologizing, thanking is a magical super-gesture of interpersonal relations. It’s what you say when you have nothing nice to say—and it will never annoy the person hearing it.

-from “The Twenty Habits That Hold You Back from the Top” from the book “What Got You Here Won’t Get You There”

That book still lies unfinished on my desk because of this section alone. Out of all the business and human relations books I’ve read in the past year, none has been so naive, so misguided, so “let’s feed the fantasies of middle managers everywhere!” than that book, and this section highlights it so well.

–

To me, there are two main types of “Thank You”s.

The first type is the basic thank you. As you may expect, it’s just a simple expression of gratitude for relatively simple things.

I personally don’t mind about how “real” a basic thank you is; both a heartfelt thank you and a mechanical “Thank you for visiting our store!” can have those “magical” effects on interpersonal relationships. In other words, I don’t have a problem with people giving away basic thank yous. I personally follow that quote often attributed to Forrest Gump: “Always say thank you even if you don’t mean it.”

(If anything, there’s a serious lack of it in society today. Back in my stint as a cybercafe attendant, customers rarely said thank you to me or the owner of the shop.)

My problem lies in the other type of thank you.

–

The other type of thank you is the “Thank you for saving my ass” thank you.

On the surface, there’s no problem with this type of thank you. If somebody saved your ass, saying thank you is the least you could do to that person.

There’s also no problem about people failing to say thank you to people who saved their asses. Sure, we’ve all heard stories about stuck-up managers who don’t say thank you to their subordinates even after the latter goes through hell and back for the former, but in reality, most managers in decent companies know how to express their gratitude for such actions. It’s part of basic management training; you don’t need a silly New York Times bestseller to tell you about that.

My problem with this type of thank you is that people often fail to address the underlying reasons why that person had to save the day. People are just content with simply thanking the person (with or without accompanying rewards) and ignoring the big picture.

I’m sure this problem is pretty common in all industries, but I think this is more prevalent in software development than in others. With the high demand for new software systems and the overall immaturity of the field, software projects often degenerate into inefficient code-and-fix death marches where heroism and firefighting (both frequent recipients of the second type of thank you) are the cornerstones of “progress”.

The sad part about software development is that people think this is normal. And even worse, many think that all of this inefficient heroism and firefighting is something to be proud of. Peopleware has a section where a manager bragged about burning out his team, and a recent blog article making its rounds around devs also provides some insights to this phenomenon. Even in my former workplace, we tend to brag (mostly tongue in cheek, though) about getting BINGOs (5 days straight OT) and JACKPOTs (7 days straight OT).

In short, I am not saying that expressing gratitude is wrong, but excessive “thank you”s for people going beyond what they are hired to do should be considered a symptom of a larger problem.

As a manager, it is your job to find that problem and fix it instead of relying on people to cover up for you.

Forget the “Golden Rule”.

Everyone has different motivations in the workplace. Some are there for the money. Some are there for the titles and recognition. Some are there for the sense of achievement that comes with closing a deal or finishing a project. Some are there for the learning experience to prepare them for their next job.

It is a common mistake when dealing with co-workers to think that what motivates them is the same as what motivates us. You can’t bait fish with cake, nor can you entice people with worms.

So the next time you need to ask something from your subordinates, or the next time you need to convince your boss to do something, put things in that person’s perspective instead of your own. If you can’t, make an effort to find out more about those persons in order to make it putting yourselves in their shoes easier.

The Empire State Building was built in only 410 days, on schedule and 18% under-budget even without computers to handle the schedule.

PERT, like the Waterfall Model, was never meant to be used in real life.

Just two of the lessons you’ll learn about management in Mary Poppendieck’s presentation The Tyranny of “The Plan” recently hosted on InfoQ.

I’m just lucky I’m not in a traditional project while watching the presentation. Hehehe…