Category: work-ethic

Posted on

Work buffer

I worked from home yesterday. There were some domestic issues that I had to attend to, so work was kind enough to get me set up for remote access.

It was weird, slightly novel, yet very familiar in a strange past-life kind of way. This used to be my life – running my own multimedia practice out of a home office.

How things have changed. In a previous gig, my hours of industry were buffered by around 20 minutes spent in transit each way. Now, it’s a solid hour each way. Time that I’ve grown to be quite fond of.

So it felt rather disorienting yesterday when I didn’t get my usual “spin-up” period in the morning and “wind-down” period in the evening. Everything was a big blur. Exhausting to say the least.

You know what they say about not missing something until it’s gone.

Posted on

Explain it to someone

Last friday, we had a retro, marking the end of another sprint at work.

One of the points I contributed to the board under the “keep doing” column was to explain what you’re working on to someone.

It’s something that I’ve observed especially in the fortnight that has just passed. A colleague would pull me aside to get some help with a nasty bug, an algorithm or just to get a pair of fresh eyes on a chunk of code.

Colleague would start drawing out the context for the specimen in question, then proceed to explain the problem and the almost-working solutions attempted so far. More often than not, colleague would have an epiphany – “Hey, I could have just achieved it by swapping that doodad with a widget and putting it through an infinite loop!”.

I get my 7 seconds of adulation and gratitude as the bringer-of-all-answers. “You’re welcome, glad I could help”, I respond, too embarrassed to admit I lost him 2 minutes into context.

Love my job.

Somehow, the brain seems to piece things together differently when one tries to explain and vocalize the problem. Solutions simply emerge out of the woodwork, that wouldn’t otherwise come up if one were to merely playing it out mentally, or scribbling on paper.

So the next time you hit a doozie, grab someone and try to explain the problem to him/her. That person doesn’t necessarily need to be across the domain of your problem. In fact, sometimes it’s even beneficial for someone to not be clued in because it forces you to explain harder.

All the person needs to do is pretend to listen, ask open-ended questions like “why didn’t that work?”, nod affirmingly at random intervals, and be okay with accepting unearned gratitude and credit.

Posted on

Vocalizing compliments

Here’s something that I’ve been learning and experimenting with since I started working in and amongst a team of software developers. While the principle isn’t limited to software development teams, it comes up quite obviously because of the measurable nature of the work that we do.

Take every opportunity to celebrate and compliment good work.

Opportunities to diss incompetance are a dime a dozen. Instances where good work peeks it’s little head out and waves timidly are few and far between. Times when one genuinely identifies and appreciates good work are even rarer. (Pretentious shoe polishers need not apply)

The compliment needn’t be overcomplicated or elaborate. Just make a statement about what you appreciate. Some examples:

“Dude, that component you put works really well.”
“Jimmy, really love the docs you wrote on that library.”
“Hey Bill, you gotta see what Steve just did. It’s freakin’ cool.”

With software, no one wins for being vague and kind: a defect is a defect, and git commit messages never lie. But a seized opportunity to praise good work is a beautiful thing.

Posted on

You owe me an icecream

We’ve been running TDD at work over the last 5 weeks or so since we started on this new e-commerce platform that we’re building for the business.

Five weeks in, our unit and functional tests have started to take more than 5 minutes to run, and this is after tweaks by yours truly, such as running the MySQL MEMORY tables instead of INNODB tables. 405 tests, just over 1800 assertions and consuming upward of 1.2GB of memory (bad PHP… bad bad PHP…).

Because there’s a team of 5 of us actively working on the same codebase, performing a complete git pull potentially breaks our local build/test cycles for various reasons. Given 5 people in the team (including oneself), one has high 4 in 5 probability of nailing the wrong person. If it turns out that the accuser was at fault, what ensues is a 100% chance of public humiliation.

So to soften the blow, I came up with a concept of owing an icecream. For example, when a colleague wrongly accuses you of breaking the build only to find that cause was him leaving something out, you’d say “now you owe me an icecream”.

So far it’s worked very well to express a combination of  “it’s not that big a deal, we all make mistakes” and “hey, you dumba**, don’t blame me for your incompetence” in a ratio that the receiver can tweak to taste.

“Icecream” invokes fun, carefree and light-heartedness. “Owe” bears the seriousness of the matter, and reeks of mortgage and interest rates. So the phrase becomes conversational equivalent of gunning down someone with a NERF gun or pillow-whacking someone over the head.