Why Remote Work Just Works (for Me)

When I started working as a programmer, my days began with a ritual that felt entirely normal at the time: over an hour of inbound commuting into the city, and then another long outbound journey home. Time, energy, money — all drained in the process. It was the cost of doing business, or so I thought.

Then the pandemic hit, and everything changed. Practically overnight, that daily routine vanished. The entire company transitioned to remote work in just a few days. Luckily, we had already laid some of the groundwork — tools, systems, and workflows that supported remote access. All we had to do was scale up.

And it worked. Customers experienced very little disruption, and internally, we barely missed a beat.

Now, years later, we’re still working remotely. And — here’s the thing — it still works.

Not just for the company, but for me. Personally. Deeply. In ways I didn’t expect.

  

More Time, More Focus, Less Waste

The first and most obvious benefit? I got my time back. No more two-hour round trips, no more standing on packed trains or sitting in traffic. That reclaimed time went straight back into my life — and into my work.

I’m more productive now. I’m more focused. I’m in control of my time, my energy, my attention. Sure, life shows up — a doorbell, a neighbour, or an unexpected distraction — but the tradeoff is still massively in my favour. I’ve spent time building out a dedicated workspace at home, optimized for deep concentration and comfort. It’s not a makeshift setup at the kitchen table. It’s mine, and it’s built for what I do.

With that setup, and without the daily grind of commuting, I find I spend more time at my desk, more time on task, and the quality of that time is better. It's not just about more hours; it's about more effective hours. My brain arrives to work fresh instead of depleted.

 

The Return-to-Office Push: A Puzzle

Despite all of this, there’s a message echoing out there in the corporate world: return to the office. The tone ranges from gentle encouragement to stern mandates. But I keep asking myself — why?

Why bring people back into expensive office buildings? Why shoulder the cost of maintaining spaces built for humans — with their endless needs for coffee, heating, lighting, safety drills, and ergonomic chairs — when the alternative is already working?

If a company needs physical infrastructure, great. Build a tech hub. Keep your servers somewhere secure, your dev environments humming. Machines don’t need water coolers or office parties. But humans — we’ve figured out how to work remotely, and for many of us, it’s been a genuine upgrade.

The Uncomfortable Truths?

Maybe not everyone shares this experience. Maybe not every job translates well to remote work. Maybe some people don’t have a dedicated space at home, or they’re working at the kitchen counter while the family or flatmates buzz around. Maybe their productivity really has dropped.

And maybe, just maybe, some of the voices calling us back to the office are those for whom remote work didn’t feel good — or didn’t look productive from their side of the camera. Managers who are used to seeing bums on seats might feel unease when they can’t “see” work happening.

I get it. It’s hard to manage outcomes instead of hours. It’s hard to trust that people are working when you can’t walk by their desk. But is that really a reason to ignore all the gains?

  

What Does the Data Say?

I’d love to dive into studies on this — real data about productivity in remote vs. office environments. But I want more than just headline numbers. I want to know:

• What kind of work were people doing?

• Did they have a dedicated workspace at home?

• Were they experienced at remote work, or thrust into it overnight?

Because I believe my personal productivity boost comes not just from being home, but from investing in a space that lets me focus, and in habits that support remote productivity. Without that, maybe the experience would be different.

 

It’s Not One-Size-Fits-All

This isn’t a blanket statement that everyone should work remotely, or that every company should shut its offices. But it is a reminder that — for many of us — the shift to remote wasn’t a compromise. It was an evolution.

We cut out inefficiencies, reduced stress, and created more sustainable workdays. And that’s not nothing.

So, when I hear the call to return to the office, I pause. Not out of resistance, but out of honest curiosity: What are we returning for? Is it about culture? Control? Collaboration?

Because if it’s about productivity — well, for some of us, remote work already won that argument.

 

My Conclusion

Remote work isn’t perfect. But it’s real, and it’s working. At least for me — and I suspect for many others too.

Maybe it’s time to stop viewing remote work as a temporary measure or a compromise, and start treating it as what it has proven to be: a legitimate, powerful, and in many cases superior way to work.

Let’s be thoughtful. Let’s look at the data. Let’s listen to the wide variety of experiences out there.

But let’s not forget: commuting two hours a day wasn’t normal. It was just what we got used to.

 

My Worst Development Argument Ever

I have had a really excellently interesting sprint with the work I'm currently doing, like you know one of those sprints where you get a real technical tooth into the pie of problems.

That however is neither an interesting story, nor one I can actually tell.

Instead I will fling my mind back a score of years and we'll discuss THE WORST DEVELOPMENT ARGUMENT I HAVE EVER HAD!

The problem started with the platform I was then working on, it was a quite low-powered single core Celeron PC base, running a favour of Windows for Embedded systems (I think it was Windows 2000 Embedded), but it was basically used as a host for a C# application stack which itself was more or less a wrapper around a C hardware driver talking to the various light, button and money handling mechanisms in the machine.

This system of ours then simply would process launch, at the shell level, another child process which was the actual game content.  And there were lots of different games we could fire up.

Our menu and the hardware polling all would back off, it was actually only polling for button and light IO and every second polling for cash changes from money physically being entered; so that was slow to update, but otherwise it was fine and backed off.

Being a Win32 environment it was fairly easy to back off most all the threading and just launch the child process.

Our testing showed that we had a 92/8% CPU split, the system would take on average 8% CPU whilst in this active child mode; it had a few spikes and it had a few troughs, that included windows itself.  Otherwise it was pretty much that most all the CPU was available to the child process.

It was therefore with some scepticism that we had the development manager in the content area wonder over complaining that one of his guys was having issues getting smooth frame rates from the platform.  We accepted the install and ran the child process, indeed we immediately saw the issue.

A popular UK TV show game, with a target circling the board...

The target would stagger and slew around, this was immediately explained to us that the system was so busy the game was being forced to drop frames, the frame rate icon the game had programmed into it went up and down like a pair of kangaroo's in the mating season.  This was the whole argument, our game drops frames your system takes too much time on the CPU.

It has to be pointed out that our manual actually said we only make 75% of the system time available to the game, our demonstrating we were making over 90% available was well within tolerance, and this is the only game showing this kind of issue.  We were therefore skeptical about the claims being made; especially about the high quality and tested nature of their content executable.

After an amount of head scratching we decided to measure how often the "Present" function was being called in DirectX, a little hackery later and we had a measure... Was Present being called consistently and then the system not presenting, or was the game itself changing the length of time a frame took, staggering when it presented?

Yes, the game itself was almost immediately measured to be staggering how often it called Present.  So the question came up "When you move these items are you interpolating between the position and so smoothing where the target is?  Or are you moving them a fixed distance each frame?"

"The frames are a fixed length"... The developer and their manager said.  We had just measured and shown that the frames were changing length, we couldn't look at their code, so we'd had to hack about but we'd shown their code was calling the present with the same staggering it was not a fixed frame rate as they said it should be.

We video recorded (literally with a camera on a tripod) measured the frames on the camera and calculated the stutter.  Then measured with our test harness when present was being called and saw a direct match, when they called present the present happened.  Our conclusion, the only conclusion really, was the content executable needed to be calling present more consistently; or their DirectX present be set up to sync with the screen or something.

The argument then began, they insisted that their game was presenting at a fixed interval, it was fixed to 30 FPS; they refused to turn on VSync, their platform did not allow this setting to be part of the DirectX initialise... It really should have been.  But we had explained the staggering, the delay in present being called, neither were o do with the system all appeared to be in their code.

"But the system is taking 100% CPU"

Yes at this point three member of my department all pulled this face:

It has to be said the manager in charge of this developer is perhaps the worst development manager I've ever met, a man so inept he alienated and lost developers at a prolific rate, who spent £40,000 on migrating to Perforce rather than paying his team and just using git.  Who seemed to think he could pick up modern development techniques by osmosis.

The developer himself?  Well, lets see how he handled all this evidence from the camera footage....

That's right, he lost his shit.

Despite myself, a coworker and our manager all confirming our observations that the hitching and stuttering were coming from the child process itself seeming to go idle and so it calling present at differing intervals he clearly took this to be a personal attack.  He stood in our development lab and basically tore into our system; our whole team took a verbal berating at this juniors gob and his manager relished it (this was one of the earliest examples I saw of this manager relishing in his minions going to town on others instead of his reeling them in).

Rocked by their insistence and being in the unhappy situation of having to prove our innocence our manager asked for us to be able to review their code.  They refused.  There were some issues, because our company had just conjoined with the place this developer worked with, they still saw us as interlopers.

My colleague was known to be somewhat more volatile than myself, so our manager left me on this horrible issue, trying to figure out what was wrong.

Come the Friday, and a little exacerbated after two days, I started to decompile their executable.  It appeared to me that their main loop was miss-behaving, it seemed to be just calling Sleep with a fixed value on top of the work it had carried out each loop.  And sleep takes a variable amount of time.... It was not taking a check of how long their update took and then sleeping for the difference to meet the frame rate target and then it dawned on me.... Did you spot it too?

They were calling SLEEP.

The Win32 API documentation literally says sleep is not a fixed interval, it relinquishes your thread for the remainder of your time slice up to or more than the sleep time given, returning when the windows scheduler next wishes to make your thread active.

It still says similar today, the time slept is not guaranteed.

This client process main function seemed to be calling sleep with a fixed value each pass, it was hardcoded into the executable.  If you sleep for X+Unknown, you are going to see exactly this staggering.  Our demo child application has a busy wait, it never slept, it yielded by passing a sleep of zero (which make it give up its time slice but remain ready, and it would more or less always be rescheduled before the fixed frame rate next time point, plus we interpolated our animation example).

This child process was just proving more and more to not be to specification.

Their manager insisted it was to spec... Which was very frustrating, as he grandly declared "I have read the code, I know it is correct" and "when we run it, we do not see this issue".

It felt like a fundamental miss-understanding, none of the folks on the team I was within were being treated with any respect, nor acknowledging our collective experience and understanding.

I stewed on this all Friday, come the Monday things were getting fractious.  This game had to be out!  It came up in the master development round up that this game was held up by our system.  This started the direct antagonism.

Everything I did, everything other members of the team did, all showed this content application was just staggering and stuttering on it's own volition, by design, by intent it staggered.  It was not our system!

To prove this I therefore set about writing a harness, which would just give the client process the same DLL to load, but they were all stubbed out calls, and it would run WITHOUT our system.  The content could be tested locally and checked.  We got one of the same Celeron PC's, just a flat install of the OS and double clicked my harness.... Sure enough the game staggered about in the exact same way!

I presented a A4 page example and showed how the loop in our example application worked, explaining that Sleep is not a fixed time interval and a busy loop should be used with a yield not a time span anyway.  I recorded this with my harness and their game, I presented both recordings too.

The developer went apoplectic....

He literally shouted at me that Sleep was guaranteed to come back after that amount of time, and when he ran my DLL shim locally it ran really smoothly.

He was right, it did, but he had a much different dual core machine with 4GB of RAM and a graphics card.  Our platform was a single core Celeron 1GB of RAM and built-in Intel graphics shared vram, in short very different.

At this point the director who sat between my manager and this development manager ordered that I be allowed to look at their code.

The worse development argument I have ever had then hit a peak, as I walked over, flanked by my manager and their manager.  I lent over his shoulder and pointed to the sleep function and said that is not going to be a fixed period.

That was all I said, he never let me explain any further, he just went MENTAL!  He started shouting, screaming, and called me a few choice names.  He would not accept all the evidence that his loop was not a fixed length, that it was changing from frame to frame, he just could not figure out that:

{

    UpdateStuff();

    Render();

    Sleep(33);

}

Was not going to always take a fixed amount of time, first of all I pointed out that doing anything and then sleeping like this will be the time the work takes plus at least 33, and then there was no guarantee that the sleep would immediately come back.  The windows scheduler would decide when you can come back after at minimum that amount of time rounded to the nearest platform tick.

His manager immediately backed him up and agreed with him, they both talked down to me.  They insisted loudly and angrily that sleep was fixed and the functions they have took such a trivial amount of time they were not worth measuring.... 

Even my manager backed me up here, of course doing a function call, any function, will take some amount of time and they need to take that into account.

I had just had these two idiots literally shouting at me, whilst I had to stay so calm, it took an icy handful of minutes for them to accept the argument that 33+N is > 33 where N is none zero.  It was just fundamental and they were not having it.

Their code became:

{

    startTime = Now();

    UpdateStuff();

    Render();

    endTime = Now();

    Sleep(33 - (endTime - startTime));

}

Slightly better, but we still saw hitches and stutters, they were far far less frequent now.

This massive drop in frequency I immediately and without changing my argument pointed me to the sleep, as I said the sleep is not a fixed time, it was not going to sleep for X and come immediately back, that's not how Windows worked.

Their argument was that Sleep was fixed, that it was guaranteed to return after X.

They were very loud, very obnoxious and very adamant.

We returned to the developers desk:  "Show me why you think Sleep is fixed".

I expected him to bring up some code, some harness, some proof of his thinking.  Instead he opened Internet Explorer, went to MSDN and showed me the Sleep function documentation.

Sure enough it said "fixed interval".  He was so smug.  So infuriatingly smug.  His manager was ultra smug too.

I reached down, scrolled the mouse and pointed to the screen.... 

He was reading Sleep in the Windows Mobile SDK.  He's right on Windows Mobile sleep is a fixed interval.  However, we're not on Windows Mobile are we.

My manager looked at the screen, I looked at the screen, they looked at the screen.  And immediately the developer called me a horrible name, yup, just straight up called me a name.

I have to admit I didn't react well, fisty-cuffs didn't happen, though the way he erupted out of his seat raging I expected the guy to swing for me.

He could not take it, his manager still argued he was right, so invested in their mistake were they that they could not admit their miss-understanding.  The manager always claiming he only hired the best minds, this guy being quite arrogant and the whole lot of them generally being very dismissive of both myself and the department to which I belonged.

I walked away with my head up high.  My manager stood and pair programmed with both their manager and their developer for maybe twenty minutes and a new version of the content executable quietly appeared without any stutter; even when we ran obrut!

It was a horrible moment in my time with that employer, I remember how the guy never apologised, that development manager never apologised and the game went out without any further delay, but they never received any censure for the episode.

Our department also never shook this kind of effect either, for some reason because their manager had gone to bat for them from the off every following time a performance issue arose we had to prove everything to the Nth degree without ever seeing the other side doing the same.  Very rarely was it ever truly our issue.

I have never forgotten, I have never forgiven.

When you foul up, just admit it, owning it and learning from it is far more wholesome than being uptight and obtuse.

Your Best Work?

The best piece of work you've ever done?

This is one of those subjective questions you can pose people, and you always hope that there's better to come, so really what we're asking a software engineer is "What is the best piece of software or project you've done so far?"

As technology is always marching on and new ideas are always emerging you can often say you're going to make something better, which is great, but it makes it harder and harder to pick out the best pieces of work from your portfolio.... Do you judge it by the number of users or downloads or how much money it made the company or even how much you were paid to do the work?

Monetarily the most money I've ever made on a piece of software was for a website I wrote in about two weeks in ASP & javascript in about 2002, which netted me the grand sum of £4000 for 80 hours work, literally £50 an hour.  But it wasn't the best work I ever did; I mean (snear) it was javascript.

The most interesting work I've ever done is the work I'm doing right now, but I can't talk about that.

So this leads me back a step to my long tenure at my prior employer, the best work I think I did, was a project to port the existing system to a new hardware platform; this involved reverse engineering the hardware interface and writing a new interface for the hardware abstraction layer for that particular hardware, which worked seamlessly and the whole system was agnostic as to which hardware type it was booted up upon.

This was not how that particular system was engineered, so in about four weeks I not only made the hardware interface an abstract interface, but also developed a test bed for the new hardware and then sewed the two together; four weeks in that environment was an incredibly fast turn around.

And it was extremely enjoyable.

That section of work was one of the best pieces of work I ever did.

Years later the creator of that hardware came to work for the company, he saw his hardware but our software and asked a few pertinent questions, for he thought his hardware was secure and could not be made to work on another platform without his secret sauce.  Let us just say it was fun to NOT tell him quite how I'd done the reverse engineering; unfortunately this reverse engineering nous set me up for the next big reverse engineering jail break required by the company, and it was a totally different kettle of fish and worthy of it's own post later.

Noise Generators & The Conservatory (Work)

That moment you tell someone you're going to go do some programming work in the conservatory during a rain storm and their mind melts as they can't figure how the sound of rain helps with your concentrating and keeping the alpha brain waves flowing....

I use noise generators whilst I'm working all the time, such as this one:

https://mynoise.net/NoiseMachines/campingRainNoiseGenerator.php

And I really like this one:

https://mynoise.net/NoiseMachines/thunderNoiseGenerator.php

But my favourite is this:

https://mynoise.net/NoiseMachines/primevalEuropeanForestSoundscapeGenerator.php

They're works of genius.

And as the new lock-down looms I'm relying on them more and more for that little taste of the outdoors whilst stick in doors.

Ten+ Years of Phoenix : A history of a Project

The Phoenix Story.... To be clear I'm not talking about the book:

No, I'm talking about a project I worked on for just shy of 10 years, which started off as the idea to really sort out the product line we were working on, software that did end up on thousands of machines in its time; was ported to at least five different hardware platforms; but which ultimately needed replacing almost before it hit the market.

Phoenix was conceived, I think, by my then boss... We'll call him "Mr B".  And it stemmed from frustration with the previous released to the public project, which was written in a bit of a shambling mess of bad C and only one chap knew how to work with it when I joined... It might have been a little bit of C++ (I remember the chap reading the first edition of the STL book)... And then a failed attempt to make a new system in Java, a bit of C++ and some SQL.... but mainly java connected to a marathon database.

Marathon you might ask, was an open source variant of DbaseIV and had been used by one of the "senior" software engineers in her prior role.  If you google for marathon database today you'll be hard pressed to find a link to it.  There's a reason for this.... It sucks.

But before we go into the technical's here, "Senior" software engineer.... lets call her "Mrs N", really was a bit of a number, when I joined as only the fifth permanent staff (and ironically I joined as a technical documentor not a programmer) she made out she was very senior and really made out that she knew everything.... She effervesced this air of knowing and knowledge, she very much talked the talk... But did not walk the walk.  It wasn't until many years later that I learned she had only been there two weeks longer than me, a mere ten days and that she wasn't a "senior" anything, she was leveraging herself to the management regularly to make herself sound indispensable... She wasn't.... Not at all.

Back to the technical's, this marathon database was to hold ALL the information about the system state, literally it was a state machine without the words "state" or "machine" being used.  The software created a connection to the marathon driver (I can't remember if it was ODBC or ADO) but the up shot was the system ran incredibly sluggishly.  Booting windows and then the software took upwards of 5 minutes, it was a real bane and a pain to work with.

Everything, and I mean everything, went through a stored procedure; which Mrs N wrote, if she'd not written it, then you were not going to get that data and if the result of the stored procedure was not what you expected then you had to submit a new request, she never really went back and fixed bugs, things were either the way she wanted them or you had to ask for more things... so there was massive bloat and creep in this code base almost from the get go.

Bless him Mr B started to try and do code review, he had an idea of trying scrum, but it wasn't scrum, he didn't make everyone be quiet and talk one at a time, quickly then move on.. No.... And I've touched on that shambles before.

With Mrs N ruling the roost Mr B quietly (and sometimes not so quietly) retreated to his office and he would hire folks.  And at some point he hired a contractor, Mr J....

Mr J in the short term was okay, he did his thing, he knew his stuff and he had good ideas, but he was hard to work with.  But he knew this new thing called C#.  And quietly in the bosses office, on his whiteboard was born "Phoenix".

The moment of Mr J presenting this to the boss he was moved onto this super secret mission to make the new new system in C#.

Which left a development vacuum.. Mr B needed someone to use in order to hide Mr J was not doing shitty java to marathon mouth to mouth.... I was thrown to the lion that was Mrs N.

Technical documents out the window, into that position they needed a programmer and I plugged away at that system helping the web developer do an integrated menu and control system, but we constantly battled Mrs N.

Mr J and Mr B however kicked off this C# and soon they had a state machine, an actual state machine by Mr B and an event passing system by Mr J... the special thing about this event passing system was that is worked cross-process, so you could stand up a C# application connect it to listen for a message... then stand up a completely separate C# application and it could send the message to the first... This allowed for a highly modular design with each part of the system mapped down to a state machine and a connection to the message bus.

It made perfect sense, it worked, it was better than using the slow assed database as the inter-process communication bus and importantly the events could be monitored, so you could introspect what was going on.

This was Phoenix... State Machine, Inter-processing Communication Messages, Highly modular.

I would assume at some point the plan was to make things like new features modular so a customer could buy a base configured machine and opt to allow it to do whatever other functions down the line, like add accepting credit cards or add printing a ticket, whatever.  Modularize it and add it on later, or critically remove it.

The problem?  Making this highly modular effectively meant everything was highly asynchronous, and there was no way to synchronise the ballet of messages going between applications, after a few versions even something as simple as booting the module executable's in the right order became a tiresome mess.

But, the initial versions went out to customers and they did buy them, and so the product lived on.... However, a highly async process stack, running on a single core Celeron processor... isn't particularly asynchronous, there's actually a huge amount of linear ordering going on all the time and massive amounts of process context switching.... So much so that in some configurations over half the 1GB of RAM was being hogged by just passing messages to systems which had yet to be woken by the windows scheduler and clear their backlog of events.

So it was after about six years a new piece of hardware hoved into view, it was a dual core box... Immediately the systems were out of order, things were going wrong, and it was a nightmare.

To be fair, the idea was sound, the implementation not so much and the language used, though flexible incurred (at that time) too high an overhead on the hardware.

Mr B struggled with this, and then he hired a new manager, a sub-manager to himself, to control testing.  Lets call him Mr P... Mr P initially had some good ideas, he used dot to create some process flow information, he tried to control contractor Mr J (who was not a permanent member of staff as he was the only person who knew anything about the message passing) and they were all wrangling to try and make this system work on newer and newer hardware, until one day it had to go onto a wholly other machine....

None of the hardware interaction stuff was abstracted, so it was written all over, but still not abstracted... you could boot the old hardware layer or the new... or even both and make it eat its own tail.

And then there were lay offs... a bunch of the folks working for Mr P went, a bunch of the testers went, and there was a big reshuffle.... I got to work right in front of Mr B... and started to try and bend his ear, to push him in new directions and not rely on Mr J so much... There's a story in that to tell.

However, things became really interesting at the turn of the final year of the whole team being on the project, a new piece of hardware was yet again acquired and the company wanted Phoenix to run on it.

I set about making that happen, and I just ignored Mr P, and Mr J and Mr B.... I made the new hardware version and fixed a huge swathe of problems with booting and data at the same time.  I couldn't disentangle from the death embrace of the message passing and multi-process context switching, but I made things better.*

* One of the things I did was find that the C# file exists check was about 10x slower than doing it as a call to "fstat", so I made a dll with just a call to fstat exposed, loaded that DLL into C# and that made the code massively faster at boot.  I then found all the C# "image.load" functions were really slow, but the equivalent from GDI+ were much quicker, add them to the DLL and voila C# went faster.

So when at the end of Q1 the team was basically told, we're letting you all go, we need one person to keep the project tided over, they picked me... I'd demonstrated a breadth of knowledge, fixed so many problems and hey one can't easily fall out with oneself.

Looking back I think the decision to keep me shocked a lot of people who thought themselves indispensable, but the proof was in the following few months.

Where the fault rate went down from the 20% range, to 18%, then 7% and finally to sub 1% range.  We were on more machines than ever, but we'd cleaned up the code base, the three testers we had went over the systems in a methodical manner.  I instigated a policy of cleaning up the code as I went, removing inter-process communications, reducing the number of vertical slices you had to hop over to get to the functionality you required and I also wrote tooling... Event viewers.... State machine inter-process visualizers, even a GUI designer.

All to turn the human element into a tooled touch of the code, control how it's used.

That didn't ever mean the testers and operations manager (Mr D) was dettered from playing with the system, far from it... But things were better.

The Phoenix project had a legacy though, the structure and controls... The message passing, the installation process, the IPC and the state machine were all a little wonky in their quirky little ways.

So it was in 2014 I restarted my own personal effort to write a new system, at home, alone, in C++.  That was Bluebird and it has a whole other story to tell.

When the Manager Went Fishing

A long time ago in a work group far away there was a bunch of problems coming up in a code base whilst the manager (who had written the very code we were debugging) was up to his knees in a Scottish stream on a salmon fishing holiday....

So yeah, the code didn't work, it was a statemachine implemented in a bunch of "if" statements a smattering of switch statements and flags which were not properly mutually exclusive... so it was a statemachine in name only really.

This particular piece of code was responsible for paying money out of a machine, and as such came under scrutiny when customers started to notice that it was either paying out more than expected or the players of the machine noticed it was paying far less than expected.  A double whammy.

This problem was looked at first by a chap in the team who didn't really get along with anyone else, and he asserted he had solved the problem... I wasn't his manager, but we accepted his word on the matter and issued a release.  This turned out to be the start of a series of problems, for with the focus on this problem the test department took it upon themselves to actually test this fault to within an inch of it's life, and of course they found the problem persisted.

The wheels then came off this development train.

For the technically senior person in the department didn't get on with the chap who had looked at this problem first, they did not get on at all... not one jot.

And I ended up sitting between these two as both a debugging sounding board but physical altercation deterrent, which it's a great place to stand between coworkers who really just needed to grow up.

The debugging progressed from the mess of code into a rewrite of one function, and this started with a large discussion around a 10 foot white board (I love working on a whiteboard).

We came up with the expected behaviour, worked out the inputs we knew and then how to get that expected output to physically happen, and did so.

It worked, it would have taken that one day.... The test department were happy with their results.

The problem?  All releases had to go through review and the binaries built and packaged by one specific person... The Manager... who was still scaring salmon with a pointed stick.

We had to get on the phone to him, do you know how patchy mobile reception is in the highlands?... No... Well, "VERY" is the best way to put it.  We managed to speak to him twice, but then had to get his permission at every step, "Do the work" it's done, "build the binary" it's built, "package the update" it's compressed, "create the release notary" it's written... 

All these calls back and forth to stitch together what should have been my simply putting the package on a flash stick and handing it to the test department (because they tested everything off of our network to be as real to our operating environment as possible).

It was a nightmare... An utter break down in co-worker communications between the other two chaps, the manager not releasing the reins of control*... The slow turn around of a build and messy nature of the codebase we had to edit... not to mention that the problem was subtle and caused by a miss-understanding between the true behaviour of a physical device compared to the expected virtual representation of it within the system's view.

There, that's what happens when the manager went fishing.

* In the hope of accruing himself come modicum of job security by appearing to be a key man.

That Work Life Split Under Covid

With the lockdown and working from home I'm finally doing something I always thought I wanted to do, work from home.  I'd always had the niggling thought I could be more efficient and it would be really good to be able to work from home.  Oh my... Oh Me Oh My How wrong was I?!

The first elephant in the room, work-life-balance, I work in my home office, my home office where I write this blog and make silly videos and play and read... And... so when I've been in it 8+ hours a day, I don't want to look at it any more... I don't sit at my office desk craving to be home chomping on some private project, because I'm already at that home desk and the lines have been blurred.

Second, the family... Specifically (sorry love) the wife... She's no concept of being in the zone, as a programmer, when you're in the zone and been doing something niggly all day and everything is finally falling into place, no matter the time, you stick at it to get done... No, my wife can't comprehend this, she doesn't understand everytime she shouts "Come on now"... It's another 20 minutes because you just mentally ravaged my trail of thought... Put headphones on?... Yeah you don't know how loud my Mrs is.

Third, hours... I touched on it a little above, but there's no quantitative way to express what you're up to.  I feel, quite strongly, that if you're not producing something (like code) and being seen to, you're looking absent from the work place... You're at home, not right there doing your thing.  Recall, I'm quite used to sitting typing for hours on end with folks wondering quite why my keyboard is so loud.  I get a lot of feedback from that presence in the moment in the office.  Without that feedback, I'm feeling more than a little fraudulent, especially as when software engineering tends to do, things go awry and you're then asking for more time... I've literally had 2 weeks on a project, then a week off (yes, I had a week off at home) and then I returned and asked for another 2 weeks... and I'm pretty much about to ask for yet another... based on the original 2 week estimate I over egged this pudding... But I have been working frenetically, except I feel on the other side... they might not see it that way.

Fourth, being somewhere else, this might sound obvious, but I'd never appreciated it, rolling out of bed stretching, getting a coffee and walking a few steps into my chair always felt like bliss, when I did it of a weekend and got on with some project it always felt so right and clean.  Now, it's sullied, it's forced upon me, it's the norm... and to be honest, it's doing my head in.  I miss the commute, the hour to decompress either way.... I miss that moment where I get to just be in my own head, in my own space in the car on the tram or just walking.

Whether that last part of the pre-virus world ever returns, I could not say.

Plastering Machine Required

So, the move is over... So many little jobs have been completed, from wiring, changing switches and today plastering a wall from which the pink finish had crumbled (no idea why the prior owner left it to get in such a state, it only took an hour to strip, brush, seal with PVA and replaster...

Which brings me onto the topic of today's post... An invention... Which mixes plaster...

Yes, this would be a huge money maker, but there must be a reason it doesn't exist on the domestic market.... Now I'm pretty sure there will be a huge hundred grands worth of professional mixing machine somewhere, but I'm talking about the small job, a single wall or room in a home.

What might this need?... Well, it needs some sensors for the mix, thickness/turbidity, water, weight, temperature even?  You pour the dry powder in some hopper, it's tested, you set the mix type (finishing or main coat etc) the water is maybe filled straight from a tap to the machine... and the computer does the rest, mixing and preparing...

When its ready, you can open a spigot to layout out the perfect mix onto your plastering hawk.

All this for say £80... I'd buy one, bet most of it could be made from plastic too, just a single mixing motor, one inlet valve... The sensors would be the key I feel, the better and more accurate the sensor the easier the mix.

The final item would maybe be a high pressure jet attachment which you close into the mixing tub at the end of your task, and which belts out the residue plaster, this time you direct the spigot to a dedicated sluice bucket which you dispose of properly.

I dunno, maybe it's a fantasy, maybe it's a money maker, whichever way, you heard about it here, first and when some other frustrated (more electronically able geek) has the same plastering problem as me (i.e. not being able to actually mix very well) then this may exist, and I want a cut of the profits... 20% sounds fair?

Great Rack Mount Mistakes #6

A long time coming, here's another story from my days long past, this one takes me to my very first serious role in an IT department, I was however just the dogs body.  The company ran many old PC's (which I actually was around to see mostly be updated to nice Compaq Pentium III's) and they had a couple of high spec Silicon Graphics workstations in the design department.

The main manufacturing control and purchasing system, as well as payroll and a bunch of other services ran on a dual 386 based mini computer, which had a custom cut of ScoUnix and a bunch of bespoke C programs comprising the actual system stack, this was accessed by a whole host or Gandalf multiplexers combining the serial connections down from a hundred or so Wyse brand terminals (I wish I'd have nabbed one of those before I left).

Anyway, it was time for this back end stack to be updated, and so a pair of Compaq Proliant servers were brought in, these were dual Pentium III class with a dedicated storage unit and a large; and importantly heavy; UPS unit.

The problem?  The IT manager I worked for (Hi Dave) didn't get on at all well with the manager at the co-location this unit was to be installed in.  Therefore in a dual effort to maintain any vestige of control and avoid the guy he didn't like, my boss ordered all the equipment to be delivered to our office... In central Nottinghamshire.... Yet its final destination once configured was to be outside Peterlee in the North East, near Newcastle.

So after around a day of setting up the equipment and (as far as I recall) three days solid compiling time - yes it took that long - the system was ready to go.

However, no-one had kept the boxes, yes it was all out of the box spread on a floor and then hand hauled over to a fire-exit and precariously piled into the back of a Hyundai estate.

Yes, that's how tens of thousands upon thousands of pounds worth of top notch equipment (for 1998) made it's precarious way 120 miles, bouncing and jostling all the way.

At the time I never questioned this, I was a lowly minion, I would of course council against such a move ever again, the installation of the physical equipment should have been done at the remote site, and they definitely should have kept the boxes and packaging in full!

My Moroccan Work Week

Many moons ago, when my then boss knew I was the dogs danglies, I used to get sent to work at offices all over the world, and today I want to tell you the story of one of those journeys to and from the "office".

I live and work out of Nottingham, and this one time I had to go work out of Casablanca for a week.  Now, for those of you not aware of this, I do not mean I went to work in a black and white film... Casablanca is a real place, a city in fact, in the North African country of Morocco, exotic... Maybe, if you like that thing.

Anyway, I was in my early twenties and sent on this trip, I spoke broken GCSE French, and was handed a few thousand French Francs (yes it's that long ago, France still had a proper currency, with a history and everything).

The journey began at an indecently early hour, a driver to take myself and a pair of cow-orkers to Heathrow, no big deal, though the driver had a tin of sweets which he was really really over proud of; he was also sceptical I wasn't the son of the two other passengers, as I was so young.

Arriving Heathrow no big deal... The flight fine and dandy... I saw sail boats in the Straits of Gibraltar...

When we landed and were in arrivals we had our bags back, and there was a driver for me, or for my then company... Not the co-workers whom were a different company - merger in progress as it were - so we all went to get in this one Merc... Now, I immediately went to the wrong side of the car, going to the British passenger side, which was the Moroccan drivers side; this baffled the driver.

But getting into the car we immediately found there were no seatbelts... the clip was engaged, but there was no strap.  Asking the driver he said, "no-one uses seat belts here, so we cut them and put the pegs in to stop the car beeping as we drive".

He then proceeded to drive like a loon, on pitch black desert roads from King Mohammed V airport into the heart of Casablanca.  By the time we arrived at the hotel we were ready for a bit of food, maybe a drink, the bar looked at my french francs like I was mad... "Charge it to my room"... silence.

This was meant to be a dry country remember, but the bar was there serving alcohol... Anyway, bed early, a morning start... My suit had just about survived being packed into a back-pack, but someone had taken the batteries out of the side pocket, which had my alarm clock... Sorting out a wake-up call was a bit of a nightmare, but I got there in the end.

Fun fact, order English Breakfast tea, they bring it to you with hot milk... URGH.  I sent it back first time around... I am such a noob.

The fun began mid-week, when I had an afternoon early ending, and got to spend sometime at the hotel, the Hyatt near the Port.  I went for a walk about, and was soon approached by a pair of Moroccan lads who invited me to "come to the bazaar, great café, show you hasheesh"... I declined their kind offer, seeing it as a mix of either illegal, or simply an attempt at kidnap.  he surprised me however by pulling his wallet from his pocket and showing me he'd spent time in Manchester...

The hard week of work ended, and I found myself back at the airport...

But there was no plane... Royal Air Moroc had no plane... There was myself, the two co-workers back from their site, and then one German chap, waiting for a whole 737... Royal Air Moroc however hadn't planned for this.

An hour late they "borrowed" a plane from Air Egypt, and the four of us boarded, this empty plane.

I have no idea why, but the staff insisted that the three of us sit together on one row... a little cramped, whilst the German chap was sat up front waving back at us all alone for the duration.  They really didn't want us to move seats.

The pilot (or it may have been the co-pilot) came back after take off and introduced himself to us, ah the days before they locked the flight deck.  I remember he had a white cotton scarf around his neck, my memory tells me this was on a wire so it stood up like biggles... But I may just be mentally elaborating...

The meal came around about this time... The offer was "Chicken or Goat", seriously... I had the goat, it was nice.

They then wanted to sell us drinks, and I panicked... Trying to ask for a "1664".. In French... instead of just asking for "un bier"... This brain fart haunts me to this day, but I was young, I was an idiot, I wanted to speak French, to a very pretty Moroccan Air hostess... Or maybe she was Egyptian....

I remember that the air hostesses didn't cover their air, a mark perhaps of days gone by?  I don't know, maybe someone can tell me.

The trip was rounded off when I got back to the chauffeur car, to come back from London to Nottingham, and he looked at me and said... "You're not on my list to come back with me".

My co-workers didn't say "lets take him", or anything as I had done in Morocco with the car sent under my company name, oh no, they just got in the car, with me standing there looking (I'm sure) a little green he added "but I'll take you as well".

We set off back to Nottingham.

Other images of Casablanca I remember are of going through the bazaar and a chat in a white tiles store asking me "You want my daughter, she cook, she clean, very clean girl".  She was 12, he didn't mean sexually either, he wanted her to be my house keeper and my take her to the UK.  I politely declined.

I was also accosted from the street, whilst I walked in the Hotel Perimeter garden, a voice from a man carrying a battered looking AK47 and a dead cockerel shouted to me... "Are you American?"  With a distinct twang on the last word.

"No I'm English" I replied...

"English?"  He beamed with his one remaining tooth "I support Manchester United".  I wondered if he was the granddad of the lad who'd accosted me mid-week, I really did.

Good times, quite sad that I sit in an office all the time now.

Development : Managers Trust your Developers

I have been so busy, I'm deep in the middle of a new system development with work, but as a personal side line I'm also completely re-engineering a different system, you know when you've worked on something or in a field as long as I have it becomes second nature to want to do things your own way... So I've been doing just that.

I picked a coding standard & style, I've stuck to it, I've pulled in SDL and Boost, it's all C++ and it's around 100x faster than the original system and amazingly more simple to access.

The problem, the boss doesn't want it, he doesn't trust it.  More importantly he doesn't trust me.

My previous boss has seen the system he's gobsmacked, his opinion was that it was exactly what was needed four or five years ago, and to have done it alone with no support in parallel with my real daily work just blew him away.

So what was my current bosses argument?  Well, it's one I can't counter, his point is that the current system I want to replace has been out on the market with real customers for years, nearly twelve years in fact, and I ported it to cover five different platforms.  He's right, it is, it has been, and it will be again, but that doesn't make the system any good.  All it lets a manager in his position do is quantify the risk versus reward, and I can not argue or knock him for that.

However, what I can knock is when you have an employee, like myself, who lives and breaths this technology, who writes books and blogs on the topic, and they've worked for you for 14 years... They're investment in the product is vastly more than the product risk for taking up the new system, especially when the new system would only go to trusted customers for trials, it would not immediately go out to the full estate of customers.  You reduce that risk you've presented drastically, there is less risk, but the reward for introducing that new system is vast, acceptance of it is equally as likely as giving customers the original old system in a new skin.

They are 100% compatible by the way, content for one works on content for the other, they work in the same sequence and order, they are the same except the underlying code is vastly better in one and a squelchy pile of over cooked spaghetti in the other...

So, to managers out there, the world over, yes evaluate your risks, but your developers are a huge component of that risk, if you have a good one, trust them when they do 40+ days of leg work on something, they're not doing it just for their own sake, they're doing it because of a driving need.