"Can you give an example of a work-based conflict you were involved in, and how you went about resolving it?"

"Heh, ohhhh yes. Last job actually. Manager flipped out at me for the billionth time for no reason at all. I calmly handed my notice in, changed a bunch of encryption keys and disabled a bunch of users on the server before leaving and never looking back."

"Wow. Seriously?!"

"Absolutely. I'm very forward-looking."

Still no idea if the guy just decided to turn up to the interview to waste our time, or he really was stupid enough to think that was a positive.

Am I the only person who hates people using "intuitive" when giving feedback about interface design? It's *completely* meaningless. Heck, this isn't even my design that's being critiqued and the comments make my skin crawl.

"It works well, but it's not very intuitive"

"Can we make this section of the interface more intuitive somehow?"

"I don't think our customers are finding it very intuitive, they're having lots of issues"

If I had my way everyone using the word would be kicked out of the meeting and made to wear an "I'm a moron" t-shirt for the rest of the week, especially the smug arses that act as though they've just said something profound.

I'm not sure I have a "favourite" per-se, but Grace Hopper certainly features high up on the list. We might not still all be writing in machine code had she not existed, but such "higher level" languages would certainly have been many years behind where they are now.

The commonly touted "best" experiences are when you just get told "wow, this code is amazing!"

I hate those code reviews.

The best ones are the ones where I get my code completely ripped apart by 10 different people in 10 different ways. Some of them might be amazing. Some of them might be arseholes thinking slating other people's code is how you climb the career ladder. But they all generally teach me something, and they all cause me to stop and think "hmm, have they got a point, or is my original design better?" The discussion that comes from those reviews is also often very interesting; and (when done well) the whole process can become somewhat of a teambuilding exercise for everyone involved.

Dahhhh. Pay for a damn hosted CI server please, like Circle or Travis, so I don't have to maintain this crappy Jenkins instance. More "plugin" updates by default than a crappy wordpress site.

Talking of which. Circle CI has come on leaps and bounds since I last looked at it. So much nicer than Travis. Think this is going to be my de-facto CI solution for open source stuff from now on.

Has anyone else actually *used* mutation testing at all?

Heard a lot about it recently - it seems all the rage amongst the bloggers, but I'm generally always very sceptical of things touted as the "latest hotness" (my thoughts on blockchain for instance are well known.)

So I went ahead and whacked http://pitest.org/ into one of my more recent pet projects to see if it offered anything decent. Surprisingly, it did - in particular it caught a number of places where switching "<" for "<=" and similar had no affect on the pass / fail rate (indicating the tests should be better.) There were a *few* false positives, and some which were borderline useful, but as a whole I'd say it was a worthwhile addition.

Curious as to if anyone else has had the same experience?

Dahhhhhh. Retrofitting CSP to an established, legacy site with inline scripts and random CSS/js loaded from all over the place is damn stressful.

Why did I volunteer to sort this crap out... What a pleb.

Mac text substitution is coming to Chrome 77!

https://bugs.chromium.org/p/...

...and it's a TERRIBLE BLOODY IDEA. Any Chrome Mac users visiting any sites that display code will likely be shown the substituted crap, unless they've picked up on it and modified their site in time.

Seriously, take these cutsie "oohhhh, I want my ellipsis to display as a *proper* ellipsis character" mindsets and shove them where the sun don't shine. By all means provide the functionality as opt-in via a CSS declaration or whatever, but don't just assume your love of bloody "smart quotes" trumps everyone else's ability to see the *actual content* on the site.

Grumbly grumble old fart grumble.

Oh, my promotion happens whenever I'm on a call with a sales guy, who announces they have a (insert grandiose job title here) on the call in case the client has any technical questions.

Unfortunately it comes with no pay rise, and I'm immediately demoted again when the call ends ;)

Existing projects, fair enough, but why you'd start a new Java project these days and *not* use Lombok is beyond me. The amount of boilerplate cut down is staggering. Some people still seem to hate it though - the mere mention of the word sends them into tremors.

(also, in b4 the predictable smartarses come in with "why you'd use Java these days at all is beyond me" 😉)

No chairs.

It's amazing how quick and to the point people can be when they can't get comfy.

Ouch. Friend started at a smallish company (~20 employees), and instead of a new machine he got handed the CEO's 5 year old Dell so the CEO could buy a new machine.

He sees it as no big deal, but am I the only one that sees that as (to put it mildly) a bit of a red flag? It's not the machine itself that's so much of a problem, more the attitude behind the decision that stinks.

Oof. Stackoverflow coming under fire again.

Not sure what they expect though given their audience consists of millions of devs from across the world who use the site daily...

https://meta.stackoverflow.com/ques...

First world problems - approaching 50k rep on Stackoverflow (well, currently on 46k.) Would quite like to get to 50k. But my days of enjoying procrastinating on there are long gone.

Sadly, so are most of the good questions it seems.

Anyone else still answer random questions on there for fun? Or has everyone else pretty much given up with it too?

Does anyone else get irrationally annoyed when a team member says "Hi" via slack/messenger etc. and then nothing else until you say "Hi" back, and only then describes what they want?

Dahhhhhh. Stop wasting my time. Just ask what you want.

"Hey boss, could you look over this reply to this support case before I send it? I just want to clarify a couple of things first."

"I haven't got the time to look over support case replies - you need to be proactive in deciding what's right, and then just sending them on."

"Ok, no worries."

5 minutes later...

"What the hell have you written on this support case? This isn't correct at all. Now they're going to be really confused. You've completely contradicted what I told them yesterday on the phone."

ffs SusanLane, no-one cares about your sunglasses

Part of a product I used to work on contained a one time password generator that randomly strung together a few words from a word list.

Nothing wrong with the security, but this word list hadn't been filtered, so we did have a "bug report" from a customer who had a one time password that contained a questionable phrase:

"fucking pork Muslim"

...Call me a terrible person, but I never did get around to fixing that...

!rant

In case anyone else finds this useful - Git 2.22 gets a --no-overlay flag, allowing you to switch directories between branches at will *without* having to clean up any newly created files in the process.

Long overdue IMHO.

There were probably odd bits and peices before this, but the first one I did with a friend must have been a "password cracker" to attempt to crack MD5 hashed passwords. Was simple as anything, but worked quite effectively.

Observation rather than a rant.

Some of the best, most experienced devs I've ever had the pleasure of meeting and working with have invariably all been the most humble and least opinionated. Mention (x language that might commonly draw disdain) and you don't hear boos and hisses and jokes being thrown around, you hear considered, succinct observations about how, if they were to work with this language, there'd be various coding styles and rules that they'd suggest working to in order to avoid some common pitfalls and frustrations.

Mention a language or framework that they know little about, or heck, they know quite a *lot* about but in which they wouldn't consider themselves an expert, and they're the first to suggest drafting in help. They're more than happy to listen to bring themselves up to speed, even if that "outside help" comes from someone considerably younger and less experienced than them.

This has particularly come to mind as of late as I've found myself working with both ends of the spectrum, but it's been my experience for many years now. Have many others had the same experience?

Oh, all sorts, but the one I always quote at her is the time she couldn't plug her laptop in because it had, I quote, "A funny plug on it that doesn't quite fit."

I took off the plastic socket protector... :-)

Heading to an AWS summit next week, just for the hell of it - curious as to what they're like. Anyone else ever been to one?

Am I the only one that prefers a clean laptop with no stickers?

(I do put all my stickers in a notebook however.)

I've been thinking about how to answer this for a while, but I'll approach it from a different angle. The time I (nearly) lost faith in my dev future wasn't because of a technology, bad programming language or an external influence. It was *me*.

The first job I had after the PhD, I was (in the first couple of weeks) tasked with updating various packages on a live Redhat server. "No problem", I thought, "I've done this before many a time on Debian, easy as pie!"

Long story short, I ended up practically bricking the server because I mistyped and uninstalled something I shouldn't have, didn't understand a piece of configuration, then tried to bodge it back and cocked things up further. Couldn't even log in via SSH, the hosting company had to be called, a serial connection set up, etc.

To say I was mortified, embarrassed and had my pride dented would be a massive understatement. I seriously thought I'd get fired on the spot, and that I should perhaps change careers to something where I couldn't cock things up as much.

...but you can't think like that, otherwise the world leaves you behind. So I picked myself up, apologised profusely, took some relevant training, double checked everything I was doing on that server in future and got back to work. After a few months of "proving myself", it was then seen as nothing more than a rather amusing story, and I became a senior dev there a couple of years later.

Take this how you will:

"The more experienced a respondent is, the more likely they are to say blockchain technology is an irresponsible use of resources."

Old farts refusing to budge from their ways, or old farts knowing better?

https://insights.stackoverflow.com/...

Damn you devpost. That Alexa skill I submitted definitely *does* use APL, and *does* qualify for the participation prize.

(The fact I can now churn out Alexa skills eligible for most of these prizes in a few minutes is besides the point, gimme gimme please.)

I'd never do anything "risky" in a prod environment if I considered it so at the time, but in retrospect there's *lots* of things considered risky now (both from a security and good practice viewpoint) that were standard practice not long ago:

- Not using any form of version control
- No tests (including no unit tests)
- Not considering XSS vulnerabilities
- Completely ignoring CSRF vulnerabilities
- Storing passwords as unsalted MD5 hashes (heck that was considered very *secure* in the days of plaintext password storage.)

...etc. I'm guilty of all of those previously. I daresay in the future there will be yet more things that may be standard practice now, but become taboos we look back on with similar disdain.

A certain, reasonably sized company had a large in house payment system to handle all their client purchases that was developed many, many years ago. All the devs that developed it had left, and as it "just worked" they hadn't seen fit to get anyone to update or maintain it since.

That was all fine until it suddenly (and completely) stopped working one sunny afternoon.

After paying a small fortune for one of the original devs to come back and look at it, turns out the payment API it was based on had been retired. Warnings of deprecation had been sent out 18 months prior, but they had just been ignored, as the secretary receiving them after the devs left had no idea what it meant.

It's something that comes with practice, but in general it's much better to overestimate than underestimate.

- Always take your time. Don't be rushed into plucking a number out of thin air.
- Break the task down into really small, atomic chunks.
- Each of those chunks will take at least twice as long as you think it does - nothing goes to plan 100% the first time!
- Make sure you add contingency at the end.