Did I just sign-up to Prime? Is this hell? Are we in hell.

Having grown up around the internet I consider myself fairly good at opting out of 'hidden' opt-ins during a checkout process. But this is the second time using Amazon recently where I just can't tell.

The first time I hit a 'bug'¹ where you genuinely couldn't opt-out of Prime. Choosing "no thanks" during the pre-checkout step had no effect. Cancelling through the modal at checkout didn't work either. I was caught in a Prime loop. I had to use someone else's account to complete the order since they had previously used and cancelled their Prime 'trial'².

This time I think I opted-out successfully but I have absolutely no idea. Going to my account and looking at the Prime settings leaves me none the wiser. All the text suggests I've already been forced into paying for Prime. I think the only way to tell is to wait until I see the charge or not I guess.

This is the 5th biggest company by market cap in the world, according to a Google of "biggest companies in the world". This is regarded as one of the best/most desirable tech jobs in the world. According to conventional wisdom the people who build the website aren't complete clowns. But... just look at this shit? Why is Amazon regarded as somewhere to emulate?

I have nothing intelligent to add here. No grand point to make. I just don't know how anyone feels positive about working in software anymore. I don't know how we get out of bed in the morning. It's all like this, dark patterns, value capture over value generation. Going into 2024 where does the motivation for any of this shit come from? It's all terrible, we're in hell, this has to be hell; the alternative is too bleak to consider.³

1. Super convenient for Amazon's bottom line I'm sure...
2. Not a trial, just a subscription with an initial discount, a trial would allow you to make a purchase decision at the end.
3. The irony of posting this on AWS is not lost on me.

Interviewing and failure

3rd May 2022

In today's therapy session pretending to be a blog post I want to try and process my recent interview failure.

This might be hard to believe but this was only the second ever time in almost 9 years I've failed to proceed to the offer stage for an interview. The first time was my first ever interview; when, as a bright-eyed young physical sciences graduate who could barely FizzBuzz, I was asked a bunch of questions about big-O notation and whiteboard algorithms. Something I'd never encountered and have never really had to think about since.

That first experience dented my confidence so much I jumped into the first job I was offered afterwards (at the very next interview). This turned out to be a reasonable turn of events. That job taught me SQL extremely thoroughly and was a fairly ideal first role. Plus, in retrospect, it was probably more interesting than doing Java XBRL processing.

4 roles and 9 years later I find myself dealing with the same shock and feeling of inadequacy. Impostor syndrome on steroids.

So what happened? I failed to guess what side of bed a random code reviewer was going to get out of bed on a random morning. Maybe. Maybe I pushed my luck by applying for a Python role when the last time I did Python was a tutorial 7 years ago? Maybe I'm not as good as I think I am? Maybe I actually am an impostor? Maybe if real people who get paid to code for a job think I'm crap they're right?

But then I do get paid to code for a job. And every job I've had has been extremely happy with my work. And I know I'm in the top 30% (being modest) at least of developers just by comparison with others. I still have one company wanting to hire me 2 and a bit years after seeing my code-test.

This isn't a "hiring is broken" or "interviewing is broken" post because the process was actually very well planned out. And the take home test was quite fun (and I'd rather have take home tests than whiteboard algorithms, the aformentioned big-O incompetence). And they had an initial screen call to show they were willing to invest in the process. And they gave feedback with the rejection!

However the arbitrary-seeming scoring or evaluation of take home tests has unsettled me. When you submit code for review in your day job you can at least discuss decisions and tradeoffs with your reviewer even if they dislike the code on principle. A take home test is always a best-guess process. You don't know if the single reviewer who will be reading your code values abstractions or simplicity. You don't know if you're designing for the future or showing your prototyping skills. You don't know if test coverage is a plus or marks you down as a worrier.

In this case I thought I was designing to support one future use-case (extended formula parsing and evaluation) when in retrospect it was likely they were looking for a different future extension (sorting and searching). The design made trade-offs for formula evaluation that would have made the latter use-case more inefficient and slightly harder to implement. But there were easy changes that could be made such as indexing data for searching or changing the underlying storage structure to make sorting efficient.

And so I find myself revisiting and justifying every choice. It's like when you wake up at 3am and think of the perfect comeback 2 weeks after an argument with someone you'll never see again. The response turning to ash in your mouth. If I could just point out that I'm aware of the tradeoffs I made in a conversation with an actual person they'd surely see my genius. I'd show them all. Mark my words, I'd show them all.

Just let me work

12th August 2021

Just let me work

Why is it that every business larger than about 10 people falls back into the same waterfall model of operation? Why is it that development capability becomes a resource to turn on and off like a tap? Why can't I just do my goddamned job?

Here's a thought, if you make and build widgets in your state-of-the-art Widgetmaster 3000 factory maybe making widgets is pretty core to your goddamned business and everyone in the business should have quite a bit of insight into the care and feeding of widgets.

So if your core competency is software maybe you want people across your organisation to know the first goddamned thing about computers, such as what the difference is between an OS and a browser. Maybe rather than creating a silo for all the strange, stooped, socially awkward weirdos whose role is to take your perfect handcrafted requirements and turn them into exactly what you specified you should involve them in discussions about the direction of the business?

Sidebar here, you'd hope the widget scenario would pan out like that but actually what happens is it gets bought by some private equity parasites who load the business up with debt and scoop out its brains because we live in, if not the worst, then perhaps the top 20% worst implementations of a market economy. Just below the one where every food company switched to manufacturing for furries, so everyone died hungry, but happy, in their fursuit.

Maybe the people whose day to day work involves modelling complex domains and spotting commonalities and differences between abstract concepts are actually good at doing exactly that and have rather more context for spotting what ideas are workable and which ideas are inescapable morasses of complexity and bugs than you, the person who learned to compose an email just-so?

Just because your interview process now selects for developers who obsess over rebuilding the hash-map rather than shipping doesn't mean you can't do something else. Maybe you should stop constructing tests to select for the developers who want to use your company as the proving ground for their novel take on the binary tree?

Every goddamned business out there doing software does the same thing. "The Business" holds lots of high level meetings where people who make $1000s every hour decide what is going to be built. That's then handed off to some people who can make eye contact such as sales, product and marketing to refine and scope. Then additional high level meetings are held where the same people agree what should be achievable. Maybe that 3 month project to tell where bird photos are taken is actually a 5 day piece of work, but the follow on 2 month phase to tell what bird the photos are of dooms the whole project?

Either software is core to your business or you outsource it. If it is core, actually make it the core and let's stop this make-pretend implementation of Agile and actually build self-directed cross-functional teams who have enough oversight of the business to deliver value reliably and with minimal fuss.

Trusting Humpty Dumpty packages

17th June 2021

When someone tells you their name it's highly likely they're being honest with you. They might be using a nickname or a short version of their full name but they're probably not lying to you. I, for example, hate my name but I still tell people my real name, most of the time, unless I'm drunk and playing the fool.

Given I trust most people I meet to tell me their real name, shouldn't I also tell them my phone passcode if they need to make a call?

Probably not. In fact someone who is lying about their name is more than likely not someone you should trust with your phone login.

So why do businesses and compliance teams mandate that code may not use pre-release or alpha/beta versions of packages? Package versions are, after all, just names we attach to versions of a codebase. There's no guarantee that the named version is fit for purpose even if it is a stable version or even that the installed package matches the available code of that version.

Unless you have a commercial support contract with some entity you're probably going to be fine installing unstable versions of the software. With open source software the code is all there to read, what has changed between versions is fully available and the maintainer owes you nothing with their versioning scheme/approach. You're going to be fine because you're auditing the package code and testing it thoroughly before deploying, right. ... Right?

Agile is hell

5th June 2021

I needed to take my car to the garage, it had taken several goes to start in the morning and was making weird noises. I had played it safe and taken the bus to work instead. I managed to book it in during lunch and they were able to fit me in the next morning.

So the next day I clattered and spluttered across town to the garage, praying the engine wouldn't explode. Made it in one piece. Drop into the reception by the workshop. I always find those places intimidating, having no knowledge about cars or what work involves when you're not sitting in a cosy office all day. I explained the problem I'd been having, I obviously wasn't able to be any more specific than "it makes weird noises", due to the aforementioned lack of car knowledge.

"Sure, bring it in we'll have a look and get it back to you hopefully by the end of the day. Will you need a courtesy car and what number can we contact you on?". I stared blankly at the mechanic. I'm sure he's not an idiot. God knows I have no idea what he does, but he does seem to be missing the point.

"Uh", I started nervously, "that's not how I was planning to do this".

"Oh?". He seemed to be waiting for me to spell it out, obviously not taking the hint.

"In order to optimize flow and avoid any build up of blocking dependencies on your garage, I was going to bring in the affected components one at a time. That way I can split the work with the garage across the road. I'll want an estimate on each component and a timeline for the total fix. That way I'll be able to plan when I can get my car back. That's just optimal surely?". He seemed to be looking at me like I was an alien. I was beginning to worry this garage had been the wrong choice, it had been very well reviewed on Google but sometimes these places buy positive reviews.

"Mate... It uh, doesn't really work like that". He's surely just taking the piss, how else would it work?

"I really think this is how we should do it. I'm willing to make it worth your time".

"Well ok, I guess for double my usual rate. But it's not the normal way of doing it". I see, he was trying to pull one over on me. But I don't want my repair to be stuck in his garage for weeks while he holds me over a barrel. At least he saw sense.

So I go out, first thing to check I guess is the car headrest, manage to jimmy it off with the tools I bought with me. I bring it in. "First up, can you give me an estimate of how long it will take to review this item and how long the overall fix will take?".

"Don't really know mate, uh, 30 minutes to check that and maybe a fortnight for the whole car?". A fortnight? That's a lot longer than I expected but there's no other way around it. Split over 2 garages that should make it a week; if I really need it fixed I can spread it over 3 garages for an even quicker fix. So I remove the car battery and pop over the road, go through the same rigmarole at the other garage but he, too, sees sense. This project's off to a great start.

So you're probably reading this wondering, what on earth is the author on about? Alternatively you've worked in any corporate software development environment (you write Java or C#) and you know exactly what this about.

I hope you'll forgive me for stretching an analogy way past breaking point, but I hoped to really get to the absurdity of modern "Agile" practice and this analogy really struck home for me. Modern Agile projects are a hellscape, where the meaning of Agile has been so warped that it stands counter to everything some folks wrote in their manifesto back in the day, a more innocent time.

When writing about Agile one always has to counter the people who chime in "oh but that's not Agile as the founders meant it". But if every time I said I was giving you a "gift" I actually punched you in the mouth you'd soon learn the revised meaning of "gift". And, dear developers, we're well and truly in need of reconstructive dental work.

Agile has destroyed all fulfillment in the career of software development.

Some old German bloke with a big beard once wrote about the alientation of labour. It would be rather delusional to claim software developers are uniquely victims of this; but corporations have long sought to convert their software development workforce into assembly line robots, with no-code tools the ultimate aim. Originally they did this by specifying the system to death in waterfall. Now Agile has replaced waterfall as the means by which to remove agency from software developers. New emperor, still nude.

So what, exactly, is the problem with Agile as currently constituted?

Simply put, by fragmenting the work of building a system into many discrete chunks and preventing any run-of-the-mill developer having an overview of the system, domain and project constraints the development workforce is reduced to the role of a stenographer (no disrespect to stenographers, they're highly skilled). Faithfully implementing whatever 'the business' decides is needed in whatever order, with daily counts standups to ensure no developer develops notions and goes off script.

The whole picture, the business-need to be solved or feature to be created, is first filtered through levels of people who don't really understand the technical constraints in place and what is reasonable in the existing system. It is split up into fragments so that each developer only has a part or parts of the elephant and then those parts are estimated in a vacuum. Then an estimate for the whole is constructed off those sub-estimates.

No developer has enough pieces of the puzzle to see that they're constructing a jigsaw of cost and deadline overruns while delivering something that doesn't meet whatever the original aim was.

So what's the solution?

Unsurprisingly enough the answer is in the Agile manifesto and it can be done, I've seen it happen.

Software development needs to be reimagined as a much more people-facing role. Developers need to work in tandem with end-users and internal non-developer coworkers and have a deep knowledge of the problem domain. There should be no internal meetings to discuss feature work or project scope without as many developer representatives as possible.

Businesses seem to have a mortal fear of a horde of shabby developers who can't make eye contact invading their inner sanctum. But without including developers in the entire process development as work will continue to suck and the output of (corporate) development projects will continue to be shoddy.

The most important thing a developer can do isn't code. It's act as an analyst of what's possible and how to deliver it. This is a call for more meetings. Not useless standups but meetings with end-users to hear feedback. With internal users/'stakeholders' of systems to understand the goals of a project. With both groups early and often to work through the any adjustments that must be made as requirements change and constraints are encountered.