Two weeks ago this literal statement from client:
I reckon <Your Product> is almost at the point where we can bypass <Competitor Product> altogether, just need <Feature X>

After various much back and forth email, drilling into <Feature X> and asking pointed questions:

At the end of the day because of <Reason Y> I'm going to need <Competitor Product>'s <Feature Z> anyway.

While I appreciate this was necessary, valuable and saved my organisation a great deal of time, it is supremely annoying that it is necessary at all.

95% of of product management seems to be about preventing dolts from being dolts.

"Most memorable bug you fixed?"

A recent instance happened in one of my Scratch projects, and the bug involved "Infinities."

I had an opportunity to teach kids programming, and it involved Scratch. So, to have something to show those kids at least, I decided to make a small game.
In that game, I had an object that takes some time before appearing after being cloned (i.e., instantiated.) The duration was calculated by dividing a constant with a variable:
[Wait for ((3) / (variable)) seconds]
The bug is that I forgot about the case where 'variable' can be 0, which is classic and insignificant.

Well, the thing is that I learned two things the hard way:
1: Scratch is very flexible about integers and floats (e.g., at one second, it looks like an integer, but one operation later, it's a float.)
2: Scratch does not provide any 'runtime errors' that can crash the project.

In other languages, similar "wait" methods take "milliseconds" in an integer, so it would have barfed out a "DivideByZeroException" or something. But Scratch was so robust against project-crashing behavior that it literally waited for f*<king "infinity seconds," effectively hanging that clone without warning or runtime errors. This masked my bug. It took way too long to debug that s#!+.

Don't blanket-mask any errors.

Some empty-headed helpdesk girl skipped into our office yesterday afternoon, despite the big scary warning signs glued to the door.

"Hey, when I log in on my phone, the menu is looking weird"

"Uh... look at my beard"

"What"

"Just look at this beard!"

"Uh.... OK"

"Does this look like a perfectly groomed beard"

"Uh... it's pretty nice I guess"

"You don't have to lie"

She looks puzzled: "OK... maybe it could use a little trimming. Uh... a lot of trimming". "I still like it though" she adds, trying hard to be polite.

"I understand you just started working here. But the beard... the beard should make it clear. See the office opposite to this one?"

"Yeah"

"Perfectly groomed ginger beards. It's all stylish shawls and smiles and spinach smoothies. Those people are known as frontend developers, they care about pixels and menus. Now look at my beard. It is dark and wild, it has some gray stress hairs, and if you take a deep breath it smells like dust and cognac mixed with the tears caused by failed deploys. Nothing personal, but I don't give a fuck what a menu looks like on your phone."

She looked around, and noticed the other 2 tired looking guys with unshaven hobo chins. To her credit, she pointed at the woman in the corner: "What about her, she doesn't seem to have a beard"

Yulia, 1.9m long muscled database admin from Ukraine, lets out a heavy sigh. "I do not know you well enough yet to show you where I grow my unkempt graying hairs... . Now get lost divchyna."

Helpdesk girl leaves the scene.

Joanna, machine learning dev, walks in: "I saw a confused blonde lost in the hallway, did you give her the beard speech?"

"Yeah" -- couldn't hold back a giggle -- "haha now she'll come to you"

Joanna: "No I already took care of it"

"How?"

"She started about some stupid menu, so I just told her to smell my cup". Joanna, functional alcoholic, is holding her 4pm Irish coffee. "I think this living up to our stereotype tactic is working, because the girl laughed and nodded like she understood, and ran off to the design department"

Me: "I do miss shaving though"

*Now that's what I call a Hacker*

MOTHER OF ALL AUTOMATIONS

This seems a long post. but you will definitely +1 the post after reading this.

xxx: OK, so, our build engineer has left for another company. The dude was literally living inside the terminal. You know, that type of a guy who loves Vim, creates diagrams in Dot and writes wiki-posts in Markdown... If something - anything - requires more than 90 seconds of his time, he writes a script to automate that.

xxx: So we're sitting here, looking through his, uhm, "legacy"

xxx: You're gonna love this

xxx: smack-my-bitch-up.sh - sends a text message "late at work" to his wife (apparently). Automatically picks reasons from an array of strings, randomly. Runs inside a cron-job. The job fires if there are active SSH-sessions on the server after 9pm with his login.

xxx: kumar-asshole.sh - scans the inbox for emails from "Kumar" (a DBA at our clients). Looks for keywords like "help", "trouble", "sorry" etc. If keywords are found - the script SSHes into the clients server and rolls back the staging database to the latest backup. Then sends a reply "no worries mate, be careful next time".

xxx: hangover.sh - another cron-job that is set to specific dates. Sends automated emails like "not feeling well/gonna work from home" etc. Adds a random "reason" from another predefined array of strings. Fires if there are no interactive sessions on the server at 8:45am.

xxx: (and the oscar goes to) fuckingcoffee.sh - this one waits exactly 17 seconds (!), then opens an SSH session to our coffee-machine (we had no frikin idea the coffee machine is on the network, runs linux and has SSHD up and running) and sends some weird gibberish to it. Looks binary. Turns out this thing starts brewing a mid-sized half-caf latte and waits another 24 (!) seconds before pouring it into a cup. The timing is exactly how long it takes to walk to the machine from the dudes desk.

xxx: holy sh*t I'm keeping those

Credit: http://bit.ly/1jcTuTT

The bash scripts weren't bogus, you can find his scripts on the this github URL:
https://github.com/narkoz/...

Manager: This code you wrote violates the single responsibility principle!!

Dev: How so?

Manager: You have one function that you call in *MULTIPLE* places. That’s too much responsibility for one function! Functions should only have one responsibility!! Creeping the scope of a function beyond that is a TERRIBLE way to write code!

Dev: But why spin up multiple functions that all perform the same thing?

Manager: Well if a function has a bug in it and you use that function multiple places then that bug exists everywhere you use that function. If a function only has one responsibility then if it has a bug that bug will only exist in the single place it is called! You really should think first before asking questions like that.

Dev: …

"A different error message! Finally some progress!"