18 posts tagged with "Opinion"

We've all heard it: "This meeting could have been an email." It's the refrain of busy people everywhere, a shorthand complaint about time wasted in unnecessary synchronous discussion.

But, if you are really trying to optimise your processes to ensure that there is minimal friction, there's a better version of that complaint. And it points to something more important than just saving calendar space.

"This meeting could have been code."

According to internet lore the quickest way to get an answer on a technical forum is to use a sockpuppet account to post the wrong answer to your own question. People rush to correct the mistake, when they would otherwise have ignored the original question.

I've been thinking about documented standards again, particularly why getting that first draft written is so difficult. We're paralysed by the need to write it perfectly. But like that sockpuppet posting the wrong answer, sometimes the quickest way to get a good standard is to put out an imperfect one.

Every engineer, no matter what the discipline, has had to deal with the endless pipeline of requests from stakeholders, customers, or colleagues. As we're often quite a long way to the right of the timeline and very close to the deadline, these requests are almost always urgent and important and often come accompanied with escalations that sound like a roll call of the leadership team.

I was having a conversation recently and Vercel came up. The organisation I am currently working with has been exploring it as it seems to offer a lot of benefits for developers who have been let down by the promises of cloud. I have to admit that I had not really looked at Vercel before, so I decided to take a look and while I was at it ended up building and deploying a simple web application that has been on the bottom of my to-do list for a while.

The Mad Men of advertising had a knack for selling ideas, lifestyles, and products with flair and persuasion. But what if they turned their talents to selling networks? How might they approach the task of convincing businesses to invest in robust networking solutions?

I've been thinking about why network documentation always feels incomplete. You know the feeling - you've got spreadsheets full of device details, beautiful network diagrams, and configuration backups. But when something breaks at 3am, you're still calling Dave from the pub because he's the only one who knows why VLAN 247 exists.

The problem isn't that we don't document things. It's that we're only capturing the bottom layer of what we actually need.

The topic of documentation always comes up in tech and it's one that has had a lot of attention in world of software development which has led to some excellent solutions. In the world of infrastructure, however, the solutions have not been as readily available or adopted.

A couple of days ago, I saw a meme targeted at network engineers that mentioned "the VLAN add disaster." I immediately understood what it meant. It feels like such a well-known thing now, enough to warrant a place in a meme, that it's become part of our professional zeitgeist over the last decade in networking.

The shift from traditional network perimeters to zero trust architectures represents one of the biggest changes in cybersecurity thinking over the past two decades. But there's a dangerous misconception floating around that zero trust means ditching network security controls for identity-based systems. This misunderstanding has led many organisations to roll out incomplete solutions that create new vulnerabilities while trying to fix legacy security problems.

The Arctic wind whipped across my face as I looked up at the entrance of what might be humanity's most important insurance policy. It has been a place that has fascinated me since I read a New Scientist article about it many years ago, and there I was, staring at the concrete wedge jutting from the mountainside, its façade glittering with an art installation that catches the summer Arctic sunlight.

How Economic Growth Reshaped the Gender Equality Conversation

The Great Misdirection​

Have we been sold a false bill of goods when it comes to gender equality in the workplace? When women fought to enter the workforce en masse in the latter half of the 20th century, the vision wasn't simply to double household working hours. Yet somewhere along the way, what was once revolutionary became a requirement—the 40-hour workweek per household transformed into 80 hours just to maintain the same standard of living our parents achieved.

There seems to be an obsession over on Reddit about the Mandela Effect which was named after a collective but strongly held false memory that the eponymous Nelson Mandela had died in prison in the '80s. It seems that our minds can play tricks on us and sometimes things which we clearly remember turn out to be a shared fantasy. I feel a little like this about those weird two weeks in about April 2021, in midst of the 'rona years, where everyone on LinkedIn got Aviatrix certification for free and then shared it with their contacts so that they too could benefit from a free certification in an emerging technology vendor's product. The reason I'm not sure if it's a Mandela Effect is that I don't really think I've heard of anyone since who has actually used that certification for anything other than to pad out their Credly.

A Matter of Western Digital Privilege​

In a recent conversation about IPv6 adoption at a Western technology company, I witnessed a familiar scene play out. Engineers and architects discussed IPv6 implementation as an optional future consideration rather than an immediate necessity. 'We don't really need it yet', was the prevailing sentiment. This perspective, common among Western organisations, reveals a profound blindspot born of privilege – one that unconsciously perpetuates digital inequality on a global scale.

Breaking the Technical Hierarchy Trap​

In tech, we often assume technical teams should be led by the most technically skilled people. This common thinking, while it seems sensible, might actually be stopping organisations from reaching their full potential. Promoting technical experts to management creates a range of problems that affect everything from innovation to career growth.

Lessons from Personal Tech and Enterprise IT​

Notifications and alerts are everywhere in our always-on, connected world. But as I've learned from personal experience and my work in enterprise IT, more alerts don't always mean better outcomes. In fact, too many alerts can be completely counterproductive.

Rethinking Infrastructure Support​

In IT operations, there's a metric that network teams know all too well: Mean Time to Innocence (MTTI). It's how long it takes for a network team to prove they're not responsible for an outage or performance issue. While that might sound funny, it highlights a serious problem in how we structure our infrastructure teams.

The Business Case Challenge

I've found that traditional justifications for SD-WAN adoption have often focused on cost savings versus MPLS or enhanced network features. However, these arguments frequently fall short under scrutiny. The fundamental challenges that limited VPN adoption in enterprise networks – including performance consistency, reliability, and operational complexity – remain relevant despite improvements in internet infrastructure.

Is it as great as Microsoft says or as bad as the customers say?​

When Microsoft unveiled Azure Virtual WAN, it was heralded as a revolutionary solution for simplifying complex networking scenarios in the cloud. The vision was compelling: a comprehensive service that would streamline branch connectivity to Azure, enable seamless hub-and-spoke architectures, provide automated routing with simplified security, and offer easy integration with SD-WAN appliances. For organisations grappling with the intricacies of cloud networking, this sounded like a panacea and I know plenty who fell for it. However, as many have discovered, the reality of implementing and managing Virtual WAN has proven far more challenging than initially anticipated.