(Fiction) How to NOT get people to reply to your email

(An open-ended mix of fiction and truth… Or writing you end up with when you’re short of sleep and hyperacidic)

Once upon a time, one Monday morning, Dev received an email. He and his fellow developers had given some requested estimates last week, and PM sent a follow-up email peppered with project management buzzwords.

“What the heck does she want exactly?”, buzzed Dev. Rereading the email for a second and third time didn’t help, even with squinting involved. “Oh, well. Maybe the others have a better idea.”

Later that day, Nutherdev approached Dev. “Hey, did you see PM’s email?”

“Yep,” replied Dev.

“Did you get what she was saying?”


“Me neither.”

“Hi, guys, ” Yeta chimed in. “What’s up?”

“Just talking about a cryptic email we couldn’t parse, ” Nutherdev said.

“You mean PM’s mail? Yeah, I saw that too. Didn’t bother. She lost me at ‘Hello’!”

At that moment, TL walked in. “Guys, PM just pinged me following up for a reply to her email. She needed it an hour ago.”

“Where exactly in the email did she say that?”, Dev asked.

“Apparently, it was implied by ‘URGENT’ in the email subject.” TL replied with a shrug.

“But she adds that to ALL of her email?” Dev replied with an expression perfectly captured by this: O_o

“Yeah, one time she even added that to her reply approving my vacation leave, ” chuckled Yeta.

Ah, vacation leave. TL wistfully heard the words echo in his head. He quickly pulled himself back to reality, and reiterated the need for the reply.

Kurosagi trolls

At work, we’ve got this server called Kurosagi in our local network which provides some collaborative tools e.g., WordPress blogs, Laconica microblog, Trac, a CMS, etc.  The most recent addition to Kurosagi is the imageboard where one can post photos and comments on those photos. Inevitably, word of it got out. Then one morning, a co-worker posted in the microblog that there was suddenly a lot of posts in the imageboard. I took a very quick look and found it peppered with trolls. I didn’t chance upon anything explicit or obscene; just a lot of useless/pointless posts that I reckon are a waste of space. It did get Renz pretty riled up though and he posted a stern warning on how the imageboard should be used. And Daniw, the current Kurosagi moderator, immediately took to cleaning up the mess.

Below’s a couple of sayings that echo my thoughts on the trolls:

  • You give an inch, and they’ll take a mile.
  • Hanlon’s Razor: Never attribute to malice that which can be adequately explained by stupidity.

It’s a sorry thing that Renz and the other decent imageboard users had to point out what should have been common sense i.e., since it’s in the office network, the posts ought to be kept appropriate for the office network. But then again, as I often remind myself, common sense isn’t altogether that common.

Common courtesy is not that common

I rarely have the need to print, but last week, I had to print a single-page document. After guestimating that the printing ought to be done, I got up from my seat and headed towards the nearest shared printer. But, alas, no printout since no paper was loaded onto the tray. I got several clean sheets, loaded it, and waited for my printout.  Once it started printing though, it spewed out several pages of the same functional specs.  I checked out the stash of prior printouts, and it turned out to be the same thing.  The pile of unclaimed printouts was more or less half-an-inch thick.  That was such a waste.

The other thing that bugs me is that whoever made the printouts didn’t even bother to replenish the paper tray.  I also hate it when someone uses up all of the paper towels in the pantry without bothering to throw the plastic container and without bothering to get fresh stock from the cupboard. Or when some guy tapped out the water dispenser without bothering to reload it with another water jug.  Or when someone uses the pantry sink and leaves traces of the instant noodles that he just had. Or, worse, when someone didn’t quite flush the toilet that you’re about to use.  These are petty annoyances, I know. But you’d think that cleaning up as you go or having a shared resource ready for the next user after you’re done using it is already common courtesy.  Bummer, like common sense, common courtesy is not that common.

The toxic mentor

Here’s someone NOT to emulate, along with some stuff he does gives him that discredit.

The toxic mentor…

1.  Expects his mentee to render overtime.

A 10+ workday should NOT be considered as the norm.  Overtimes should only be considered as a last resort, or as something to get into when you’re feeling productive or enjoying what you’re working on.  And as uncle bob martin (no actual relation) tweeted, the tenet of professionalism is to work 40 hours for your employer, and spend 20 hours on improving yourself and increasing your own value.  Now, you can’t do that if you’re slaving away and putting in all those 60 hours at work.

Excessive overtime also tends to burn people out, or it can make people slack off.  One can already do so much (especially if uninterrupted) during the normal 8 hours of work.  What you should do is push yourself to be more focused and productive in those 8 hours.

2.  Thinks UAT without overtime is impossible.

That’s learned helplessness in action. Don’t try to poison young minds.  And if you think it’s impossible, then you wouldn’t try to attain an OT-less UAT. Management ought to provide an incentive for teams to not be on OT’s or ON’s during UAT. Maybe that would push the teams to improve the quality of their work during CUT and System Test phases where the problems are less costly to fix.

3.  Undermines his mentee’s estimates.

It would be best for the one who’d actually work on the task to provide the estimates. Don’t jump the gun and tell your mentee that the task can be done in just 4 hours when you haven’t even picked up on the requirements of the task. That will just pressure your mentee to do the work within the time you stipulated at the risk of quality.


4.  Causes delay and does not bother to apologize.

Don’t be too proud to say you’re sorry when you’ve inconvenienced your mentee. Just because you’re the mentor and she’s the mentee doesn’t mean she’s not entitled to the same respect and courtesy.

5.  Keeps making promises he can’t keep.

Stick to your word. Keep on breaking it and your mentee will learn to distrust you or, worse, respect you less.

Too young to be jaded

Yesterday, I approached one of the testers in another project regarding a problem I encountered when I tried to use their system.  I asked him if I had done something wrong or if he had encountered the same problem before.  It turns out that part of the screen hadn’t been tested yet.  Later on, he told me that he was able to replicate it when he tried the screen with Firefox.

He sounded worried that the system was supposed to “look good” in IE, yet even in IE there were still so many quirks.  And they didn’t seem to have a plan for testing it across different environments.  He said, it’s already the System Test phase yet it still felt like CUT.  Giving comfort hasn’t been one of my strong suits… I told him that the higher-ups in his team probably has something up their sleeves to handle these risks.  He blatantly told me that it doesn’t seem like they did.

I’ve no inside scoop on what goes on in the poor guy’s project.  I just know that they’ve been going on consecutive overtimes for quite some time now.  It’s unhealthy in more ways than one.  It’s also sad that he doesn’t seem to be confident about how the higher-ups are handling things.

I left the office that Saturday afternoon feeling a bit bad.  Those going on OTs are still just kids (well, I guess so am I but i’m just a slightly older kid) and it’s sad if they become jaded or build up some learned helplessness this early.

Wishing for more time

I came to work last Saturday feeling sick… I was breaking into a cold sweat and I had this annoying headache probably because I was out quite late the previous night. My body also felt sore due due to the tennis session with workmates from the day before.  I could have gone to work feeling better if (a) I didn’t want to indulge myself with an imax movie with friends, and (b) I didn’t want to try out something new and engage in some physical activities.

Last night, before I went to bed, I did a breakdown of my workday:

  • At least 9hrs at work – mandatory 8 hours + 1 hour lunch
  • At least 2hrs to prep and go to work – includes buying breakfast to eat at my seat in the office
  • At least 1 hr for dinner
  • At least .5 hr to commute home
  • At least .5 hr to clean up
  • At least 7 hrs for sleep
  • Leaving only at most (but definitely always less) 4 hours for any other stuff including errands and household chores

I wish I had more time for learning, my geekish fixes and exercise.

Wrong bug classification

I saw a very small creepy crawly insect inside the house last evening. My roommate caught me as I was squishing the poor guy. “Dog louse,” I told her.  I figured it looked just like the dog louse (must’ve been from the neighbor’s dog) that we found in our unit a few days back.  Upon inspection, she told me it wasn’t a dog louse.  Turns out, I squished it for nothing as it was actually harmless.

This then reminded me of something I saw from work earlier.  Turns out a certain project prepared some standard test cases for their web application. Oddly enough, they provided bug priority (Critical, High, …) and bug level classifications (Functional, Usability, User Interface,…) for each of the test cases.  They might have just been suggestions but those classifications were intended for bug reports — not for test cases.  That’s like estimating the size of shadows you’d cast given your size. Or judging a cookie based on the cookie cutter. Or

Anyway, this is what I was actually reminded of… One of the items included a test case in locking — something like an error ought to be raised if you try to modify a record locked by another user.  And the suggested classification for that item:  Usability.

I’m no expert but I reckon usability is something that enhances or facilitates the usage of the thing in use.  Locking, on the other hand, is not simply about raising an informative / helpful alert to inform users that someone else is modifying the same record.  It’s essential to the functionality of an update since it helps ensure that the latest record is being updated granted that there are possibly many users that could be updating the same thing.

Of course, the actual bug classification should still depend on the actual bug found.  And for all I know, it could indeed turn out to be a usability bug.  I just hope it won’t be a case of mistagging a functional bug as a usability bug, or vice versa; or another case of squishing a poor little non-dog-louse bug for nothing.

Recommendations I’m iffy about

A couple of months ago, there was a series of testing walkthroughs that were conducted for a certain project in our company. One of its outputs is a 9-page document that they’re intending to upload as is into our office wiki.  The document is supposed to be a list of recommended best practices intended for testers to read.  I wish someone had the time to go over it and clean it up first though.  The content isn’t arranged well with repeated items and inconsistent usage of wordings in the first/second/third persons, active/passive voices, tenses, etc.  Some of the bullet points I’m iffy about:

  • Considering shared/common functionalities across our module or even in the whole project that could save effort in testing is also important. – Too vague. No clear tip or action item.
  • Knowing what are the General Behaviours in the system – Too vague. And this is more of a ‘must’ rather than just a suggestion.
  • I have also learned about the possibility of testing the function by parts and had to consider how I was going to accomplish testing the function in that way without redundant testing. – More of a feedback rather than a suggested best practice.
  • Plan carefully which programs of the function needs to be prioritized. Consider impact if there is no “flow” in the priority. – I don’t get it.
  • Know existence of similar functions. This will help potential saving of effort. – Too general.
  • This helps avoid or minimize the risk of overtesting or bloated effort in testing. – This shouldn’t have its own bullet point.
  • Planning is very important, be conscious on the effort spent, and as much as possible think of ways on how to reduce the estimates w/o risking quality. – While I agree that planning is important, this also reminds me of the following classic mistake:

    shortchanged quality assurance – cut corners by eliminating design and code reviews, eliminating test planning and performing only perfunctory testing. result: product still too buggy to release. Shortcutting 1 day of QA activity early in the project is likely to cost you from 3 to 10 days of activity downstream (Jones 1994).

  • SQL. Continuously improve your SQL and your SQL writing skills. – I wish this would also say how.
  • Prepare background data beforehand. Ensure that initial data are available beforehand. – Can’t be ensured.  Chances are you’ll still need to create more or other data as you go.
  • For screens/grids using the same source code, no need to repeat test cases after confirming with the developer that they are the same. – No.
  • No need to repeat test cases for different browsers – Depends. Just take our in-house bug tracking system when used with Google Chrome, for example.
  • Knowing when to stop testing a particular program (i.e. avoid Over-testing) – Doesn’t answer or even suggest how.

I’m stopping at page 3.  Need to get some sleep now.