"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.

Model railways.

Nested CSS declarations without using SASS or similar.

Fewer Javascript frameworks. We have enough.

Spending caps on AWS so I can mess around without worrying about going bankrupt.

Cross-browser compatibility.

Serverless will become increasingly prevalent.

Javascript will become even more prevalent than it already is.

I make no comment on whether I think the above are *good* evolutions, however.

To become reasonably proficient in AWS.

It's the one relevant area I feel like I'm being left behind in at the moment. Every other job listing I've seen has it as a requirement or a nice to have, so it'd be a good box to tick.

Ah, the awkward moment when you're told to join a conference call to "just listen in the background so you know what's going on"

...and then no-one else from your company turns up, so you're stuck trying to appease a client while having absolutely no idea what's going on...

I inherited some Java code from a guy that thought you could only return strings from a method.

So how did he ever pass anything other than a string, I hear you ask? He had a (hand crafted, using no libraries, and not escaping anything properly) toXml() and fromXml() method on each object.

Yeah...

Dah. Have to integrate with a legacy, crappy, SOAP service with malformed WSDL and bugger all documentation.

SOAP should just be damn well illegal these days.

Dear web developers: please use the "Accept-Language" header to determine what language to use, not some weird, whacky geolocation script. That header exists for a reason.

Yes Google - that includes you.

At a networking event. Tired. Not a people person, especially when tired.

Found a secluded empty booth, pretending to do some urgent work. Hoping no-one notices I'm not socialising.

How long can I keep this up is the question! :D

Damn. Forgot Europe uses different plugs to the UK, and on a work trip in France. 3 days without charging the laptop...

If it's an open source project and it (shock horror) actually gets a decent userbase, expect it to suck up *way* more time than you originally intended.

What is it with the rising trend of password fields allowing you to see your password, and (worse than that) often having it as unmasked by default?!

Who woke up one day and said "Damn, you know what would be a great idea? Unmasking the password field, so everyone can see it! Why didn't we think of that before?!"

Dahh.

!rant. Just trying to make people feel a bit better.

Ever thought "Ah crap, I have no idea what's going on with this code?" - then immediately second guessed your abilities?

You're not alone.

https://github.com/search/...

It's not just tiny projects in there either. Gnome is on the second page :-)

Call me boring but...

Working in a secure job with a great work/life balance, little or no travel, great people, really interesting challenges, earning a tidy salary, contributing to open source, all the while creating something worthwhile and interesting.

I have a few of those already, so can't complain.