Maroun Baydoun's blog feed

AI and the revenge of the non-techies

Tue, 29 Sep 2026 00:00:00 GMT

Software engineers have had a suspiciously good run.

For the better part of two decades, the profession offered a combination that was difficult to find elsewhere: high salaries, generous benefits and offices whose interior designers had apparently been briefed to build playgrounds for adults. You didn't necessarily need a degree, rarely needed a suit and, eventually, didn't even need to leave your bedroom. While teachers, nurses and other highly trained professionals continued doing their vital jobs for considerably less money, we were arguing about whether the free office lunch had enough vegan options.

We didn't exactly handle our good fortune with discretion. We took on absurd names: rockstars, ninjas and gurus. We built an entire culture around the idea that software was eating the world. Every industry was ripe for disruption, every profession was inefficient and every problem could be solved by putting it behind an app and a monthly subscription. There was always a little irony in hearing people with some of the most comfortable jobs in the economy explain why everybody else's was about to disappear.

Now software is supposedly coming for ours.

Everyone can code

Coding bootcamps promised to democratise software development.

For years, the proposition was difficult to resist. Take a few months off, learn a programming language, build an app and emerge into a new economic class with a company MacBook and a salary your previous profession might have required a decade to reach. Software engineering became a promised land that required neither years of university nor professional accreditation to enter. You just needed to learn to code.

It was probably unreasonable to expect them not to bring popcorn when it finally came for ours.

Except there was an awkward contradiction at the heart of the sales pitch. Software engineers were supposedly paid so well because they possessed scarce and specialised skills, while an entire industry was simultaneously advertising those skills as something almost anyone could acquire in twelve weeks. Coding was valuable enough to transform your life, but easy enough to learn before you had to stow away your winter wardrobe.

Amid the wave of tech optimism, the contradiction didn't matter. Tech was growing quickly enough to absorb an extraordinary number of people. The bootcamp era helped cement an idea that survives today: that software engineering is primarily the act of writing code. Learn enough syntax, memorise a few snippets, internalise some jargon and you're more than welcome in the secret society.

Alas, the market became less forgiving. Bootcamp graduates discovered that building a book-search application and being entrusted with a production system were not quite the same thing. The twelve-week programme ended, but for many the promised career never began. The gates to tech had been advertised as wide open; there was still, inconveniently, a gate, with keepers guarding it.

Nobody needs to code

If bootcamps promised that everyone could become a programmer, no-code offered something even more attractive: nobody needed to become one.

The databases became colourful boxes, business logic morphed into unidirectional arrows and websites could be assembled by dragging rectangles around a screen. The objective was no longer to teach the rest of the world the strange rituals of software development, but to remove the software developer from the process altogether.

There were valid reasons behind this promise. Engineers had become accidental gatekeepers to an increasingly digital economy. If you had an amazing idea for a product, somebody eventually had to translate it into code and ship it. If marketing wanted to experiment, engineering had to build it. If product wanted a feature, engineering had to estimate it. If designers wanted a button moved two pixels to the left, engineering had the audacity to ask why.

Democratising the means of production doesn’t necessarily mean democratising the returns.

Crafting software gave engineers leverage well beyond the mechanical keyboard. The skill was scarce, demand was high and companies increasingly depended on it. In Marxist terms, which is obviously where any sensible discussion about developers eventually ends up, software engineers had acquired control over a small but increasingly important means of production.

No-code tried to loosen that control, but failed to deliver the seismic change it promised. A bigger shake-up was cooking.

Seize the means of production

AI isn't being sold merely as the next evolution in software production. Increasingly, it is touted as a liberation from the people who know how to write it.

A three-month coding bootcamp is now twelve weeks too long. A deep understanding of programming is superfluous. Hiring a team of opinionated software engineers is a threat to the balance sheet.

The revolution is underway. It comes with a monthly subscription, per-seat pricing and token allocations. It has its thought leaders, warriors and propaganda department. No blood is being spilled on the streets, but the transformation is violent nonetheless.

The masses are shouting "Expropriate!" and software engineers are feeling threatened. Skills acquired over decades are turning into commodities anyone can claim. Their power within organisations is being dismantled. Their pride in the craft, their achievements and even their passion for it are increasingly recast as arrogance and resistance to progress. Public executions are, thankfully, not part of the manifesto, but the software engineer's character assassination is high on the list.

Schadenfreude as a service

A serious technological transformation is taking place. Denying its existence or impact would be about as useful as insisting the internet was a fad in 1998. But technology alone doesn't explain the peculiar enthusiasm surroundingthe upheaval in software development.

Every profession worries about progress, mechanisation and automation. From factory workers to horse-carriage drivers, the past few centuries are brimming with examples of technologies that disrupted entire industries and livelihoods. The angst around major milestones, such as the Industrial Revolution, also led to unrest, revolts and unprecedented social and political mutations.

No matter where you stand on the ideological spectrum, it's hard to deny that one of humanity's biggest struggles has been that between those who have and those who don't, those who exploit and those who are exploited, those who control the means of production and those who are but cogs in the machinery.

Unless you've achieved absolute enlightenment and completely detached yourself from material possessions, it's hard to argue that envy or jealousy aren't features of the human experience. From biblical tales to wars, we've always wanted more, especially when someone else has more.

Watching tech workers enjoy salaries and working conditions that seemed wildly disproportionate from the outside didn't go down well with everybody. Study for years, work in an essential profession and commute every morning, only to find yourself earning half as much as someone in their twenties writing code from their kitchen table. No need to harbour a deep hatred of programmers to wonder whether the labour market went haywire.

Then there are those who tried to join the party. They learned to code because an industry told them they could, only to be stopped at the door. And plenty never wanted to become programmers at all, but spent twenty years listening to tech explain how software would disrupt their jobs, their industries and occasionally their entire way of life.

There is something satisfyingly symmetrical about watching the disruptors get disrupted. It would be reductive to call that jealousy. It would be equally naive to pretend there isn't a little bit of it in the room.

The call is coming from inside the house

From inside the office, to be precise.

The line dividing the revolutionaries and their "victims" might seem very clear at first. But painting the skirmish as non-techies versus techies is too reductive. Some "techies" have answered the call to arms.

Software companies have spent years creating their own non-technical class: people who came from engineering but gradually moved high enough that software became something they manage instead of make. CTOs, VPs of Engineering, directors and their directors can still be deeply knowledgeable about technology, but their relationship with it has fundamentally shifted. Their work revolves around strategy, budgets, headcount, roadmaps, hiring plans and organisational problems rather than commits, builds and deployments.

From their perspective, the distinction between software produced by twenty humans and software produced by five humans with AI can look mostly like a question of efficiency. Requirements enter one side of the organisation and software emerges on users' screens at the other. What happens in between is an implementation detail, and implementation details are precisely what this class of workers doesn't typically worry about.

There is also a comforting assumption hiding in that view: the machinery can change while the human overseeing it remains necessary. Replace programmers with agents, reduce the assembly-line headcount, increase output and report the efficiency gains upwards. The factory gets automated and management continues managing, for now.

This creates a curious coalition between two seemingly unrelated groups: the people who never learned to program and executives who haven't shipped production code in years. They might look at AI from opposite ends of the org chart and still reach roughly the same conclusion: at last, we don't need so many engineers!

They may both want to be careful about where that story ends.

If AI can understand a vaguely specified product requirement, break it into tasks, coordinate agents, evaluate their output and report on the result, the boundary between replaceable technical work and irreplaceable management work starts looking suspiciously arbitrary.

Revolutions, after all, are notoriously bad at respecting org charts.

The job was never the code

There is a more fundamental problem with the promised abolition of the programmer: it depends on the same misconception the bootcamp era helped create.

Bootcamps claimed that because coding could be learned quickly, anyone could become a software engineer. The loudest AI advocates now tell us that because code can be generated quickly, software engineers are no longer necessary. The conclusions point in opposite directions, but both reduce engineers to producers of code.

Code is certainly part of the job. It is also increasingly the cheap part.

The expensive parts tend to gather around it: figuring out what needs to be built when nobody agrees, understanding a system whose original authors left five years ago, choosing between solutions with hidden trade-offs, keeping old software alive while replacing it, investigating the production failure that cannot be reproduced locally, and eventually taking responsibility when software meets the untidy world outside the text editor and the deployment pipeline.

Machines will get better at those things too. Some will be automated entirely. The point isn't that engineering possesses some mystical human quality that machines can never reproduce. But making code dramatically cheaper to produce doesn't force the rest of software development to disappear with it.

Meet the new bourgeoisie

There is one final inconvenience with our revolution: nobody actually seized the means of production.

We rented them.

The models capable of democratising software require extraordinary amounts of compute, infrastructure, data and capital. The factories haven't been handed to the workers; a proprietary API has been placed in front of them, its access and price controlled by a board of executives in an opulent office.

The person who couldn't build software yesterday can now create things that once required an engineering team, which is genuinely remarkable. They can also lose that ability when the subscription expires, their account gets suspended or their provider's status page turns red.

Let them eat tokens

Software engineers may indeed be losing their position as gatekeepers of digital production. Millions more people may be able to make software without ever learning what a function is, and civilisation will somehow continue. Engineers themselves could become dramatically more productive, with smaller teams building things that once required entire companies.

Or perhaps one engineer will simply be expected to do the work of five while the savings travel elsewhere.

That's the part of the revolution we haven't figured out yet. We spend a lot of time asking whether AI can replace programmers and considerably less asking who captures the value when it does. Democratising the means of production doesn't necessarily mean democratising the returns.

For now, the software-engineering bourgeoisie can enjoy the historical irony. We spent twenty years telling everyone that technology was coming for their jobs. It was probably unreasonable to expect them not to bring popcorn when it finally came for ours.

The JavaScript midlife crisis

Tue, 22 Sep 2026 00:00:00 GMT

A while back, I made a half-observation, half-joke on LinkedIn.

The great JavaScript toolchain rewrite barged in. The older tools that helped cement the language's place in our stacks became uncool, if not suspicious. Their sluggish performance took the blame for slowing down millions of lines of code on their way to production. It's increasingly difficult to keep track of the cool kids on the block. Their names might not be catchy, but their promise is captivating: speed, and a lot of it.

It's a strange time to be a JavaScript developer. The language has never been more ubiquitous, yet it seems to be losing ground in its own backyard. The tools are faster, the setup easier, the abstractions thicker. We write, configure and wait less. We bundle, ship and hotfix more. What happens between our code and the end product becomes easier to ignore.

The benchmarks are all beaming green. The line charts are trending up, down, or sideways—whichever direction means fewer calls at 3 AM. So why am I here to ruin the party?

The language that wouldn't die

For a language (in)famously written in ten days, JavaScript managed to achieve the unthinkable. It escaped its birthplace, the browser, and started swallowing everything around it. The reaction was predictable: Who in their right mind would write their server and tools in JavaScript? It turned out, many many many would. JavaScript made it onto phones, gaming consoles, microcontrollers and your fridge. If it understands bits, it can run JavaScript.

Despite its popularity, JavaScript never had it easy. Not long after its inception, attempts to fix, or rather replace it altogether, were already in motion. Microsoft endowed Internet Explorer with VBScript and JScript, their own JavaScript flavour—not to be confused with J-Pop and JRPGs. In the 90s, everything sounded cooler if it started with J. Macromedia, and later Adobe, littered the internet with Flash intros and games powered by ActionScript. Google bet on Dart for the future of Chrome before relegating it to Flutter.

Projects such as CoffeeScript added some syntactic sugar to the JavaScript cup. When we weren't trying to replace JavaScript, we were busy patching it from the outside. jQuery unified a web platform whose browsers were barely on speaking terms. Lodash filled glaring gaps in the language's arrays and objects. Moment.js made dates somebody else's problem.

JavaScript wasn't sitting still while everyone plotted its demise, either. Within its single thread, it was rather busy. Browser vendors, standards bodies and the community kept pushing the language forward. ECMAScript releases brought long awaited language features. TC39 kept the proposals coming, and browsers slowly learned to agree on what JavaScript was supposed to do. Over time, its standard library became less embarrassingly sparse.

Then came TypeScript, and JavaScript's head was finally on a silver platter. Or so it seemed. TypeScript succeeded where the others failed by accepting one inconvenient truth: JavaScript wasn't going anywhere.

You could improve it, hide it, compile to it or complain about it. You just couldn't get rid of it.

The superpower we're giving away

One language to rule them all is both a blessing and a curse. We spent decades talking about the curse. Somewhere along the way, we forgot about the blessing.

As JavaScript continued to spread, it started eating its own dog food. Node.js enabled a slew of tools to emerge and conquer the ecosystem. Linters, bundlers, formatters and test runners were speaking the same language as the code they linted, bundled, formatted and tested.

If, or rather when, something broke in that toolchain, the average JavaScript developer would be able to check the code. Maybe they'd understand the bug. If they'd had their eight hours of sleep, maybe they'd fix it. If they were feeling combative, maybe they'd submit a pull request. At the very least, they knew enough of the language to confidently blame the bug on the maintainers.

And that familiarity travelled surprisingly well. The same language followed developers from the browser to the server, and eventually almost everywhere in between. JavaScript accelerated the rise of full-stack engineers, or perhaps full-ecosystem engineers. Whether anyone can truly master both ends of the stack without achieving demigod status is a discussion for another day. But JavaScript made the transition considerably easier. Engineers could bring along their knowledge of the call stack, prototype-based inheritance and the unfortunate fact that typeof null === "object" to almost any project.

People built entire careers and businesses around this catch-all ecosystem. The fact that most of it was and continues to be open source and free certainly helps.

JavaScript won the browser wars, and several key battles elsewhere. Then Rust and friends showed up for the trophy and the commemorative photo.

In pursuit of milliseconds

Rust, Go and Zig are taking over increasingly large parts of the JavaScript toolchain. And there's an obvious reason for that.

They're fast. Really fast.

We're compiling JavaScript with Rust to produce JavaScript that runs inside an engine written mostly in C++.

Nobody wants to stare at a build process long enough to form an emotional attachment to the progress bar. But when the replacement for an already-fast tool advertises itself as ten times faster, I start wondering what we're supposed to do with all those precious milliseconds it just handed us back.

Take an extra sip of coffee?

More importantly, what did we trade for that speed?

Rewrite a bundler in Rust and you haven't only made it faster. You've also shrunk the pool of JavaScript developers who can maintain it. The new tool still looks like a duck and quacks like a duck, but it's a different beast altogether. Its internals retreat behind a black box that fewer people hold the keys to. The source may still be open, but the door to contributions is closing.

Maybe that's a perfectly reasonable trade-off. But it is a trade-off. And we don't seem particularly interested in that side of the benchmark.

Not everything that shines is gold

Sometimes it's rusty.

Software engineering has always suffered from a particularly acute case of shiny object syndrome. Languages have their moment. Frameworks become fashionable. A few successful projects establish a pattern, companies invest in it, conference talks follow, laptop stickers get handed out and suddenly a technical decision becomes the main selling point.

"Written in Rust" starts sounding less like an implementation detail and more like a feature.

Success breeds imitation. One tool gets rewritten and becomes dramatically faster. Another follows, and another. Peer pressure mounts. Soon enough, being written in JavaScript starts to look less like the obvious choice for JavaScript tooling and more like a losing bet.

We're laying increasingly faster tracks for a steam train that likes to take its time.

None of this means those compiled languages are the wrong tools for the job. Quite often, they are exactly the right ones. But there's a difference between the right tool for this job and the right tool for every job that looks vaguely similar to whatever the competition is doing.

Once the shiny new tool also happens to top the benchmarks, resisting it becomes considerably harder. Speed provides the technical argument. Trendiness takes care of the rest.

Destination unknown

Our pursuit of faster JavaScript has taken us to a rather peculiar place.

We're compiling JavaScript with Rust to produce JavaScript that runs inside an engine written mostly in C++.

Perhaps that's the natural evolution of mature ecosystems, and JavaScript doesn't need to swallow the entire stack to remain relevant. Languages can coexist and still thrive. The web was built on at least three of them, before many more joined in.

Taken individually, every step makes perfect sense. Taken together, they point somewhere more interesting. We're putting a substantial amount of engineering into optimising everything around JavaScript while JavaScript itself remains the destination. We're laying increasingly faster tracks for a steam train that likes to take its time.

The thing about speed is that it doesn't always guarantee a smooth journey when the train itself isn't designed to keep up. Sooner or later, faster tracks will make less and less of an impact. And someone, much smarter than me, will have to ask the difficult question: how far can we go before rebuilding the web from the ground up starts looking like the saner option?

The outstanding engineer who wanted to become a mediocre manager

Sun, 16 Aug 2026 00:00:00 GMT

Software engineers are built differently. The great ones at least. Throughout my career, I've had the pleasure and privilege of working with—or under—a handful of them. They're the ones who taught me what books couldn't. The ones who proved that breaking the rules is sometimes the only rule. The ones who somehow balanced a healthy dose of scepticism with an undeniably open mind.

As I reminisce about the great ones that helped shape the engineer I've become, an uncomfortable question keeps nagging me. What happens when the mighty fall? I was there and I remember the announcements, the celebrations, and the aftermath. Here's the tale of outstanding engineers that succumbed to the lure of management.

A demotion in disguise?

The software engineering industry – and the corporate world at large – want you to believe they are meritocracies. Engineers are encouraged to hone their technical skills. We're told to choose a stack, a letter-shaped expertise and a 10-based output multiplier. In return, good performance (and savvy politics) often lead to promotions that bring higher income, a shiny new title and a load of responsibilities. Associate Junior Engineer, Engineer 2.5.0-beta, IC-ex-machina... the naming schemes get creative, and engineers happily sign up for the game. It's all smooth sailing until the dangling of the manager promotion flips the script.

The title is certainly attractive, especially when sold as the natural progression. "It's the only cure for your career plateau." Suddenly, all the years spent laying the bricks of engineering excellence fall by the wayside. Gone are architecture diagrams, proofs of concept and obscure JavaScript quirks. And in come spreadsheets, pre-alignments, alignment meetings, post-alignments, alignment follow-ups and follow-up alignments.

Careers don't have to be ladders in the first place (especially if you're afraid of heights).

The temptation is easy to understand. Who wouldn't want a promotion? It's only human to desire more and think big. But how do you survive when the career high sends you into the stratosphere, without the proper suit and helmet? How do you cope when you land on an alien planet where you don't speak the language?

Will you manage to manage?

You'd be forgiven for assuming I'm looking down at managers. Let me assure you—and them—that it isn't the case. I have nothing but respect and admiration for those who choose that path, especially those aware of the challenges lying ahead and equipped to tackle them—or willing to learn. Even when they fail, watching them struggle garners nothing but empathy (and a little unspoken I-told-you-so moment, if I'm being honest).

Managing human beings must be one of the most demanding jobs out there. Despite their complexities, computers, compilers and databases don't complain. They crash, time out or stop responding and generally recover after a reboot, a patch or a debugging session. Humans, on the other hand, disengage, burn out or slack off, and no reset button or IT-approved tool can come to the rescue.

Juggling between compassion and decisiveness, flexibility and rules, is a gift that very few possess. And it turns out most of those are not among the great engineers. The set of skills a manager employs are a far cry from what the industry moulds engineers to become, or what they're best equipped to tackle.

You'd also be forgiven for assuming I'm making the case that engineers are inherently ill-suited to management. And you'd be wrong yet again. There's no denying that our culture portrays us as nerdy caricatures wanting nothing more than to stare at gigantic monitors all day long. But great engineering has never been just about technical prowess. Navigating office dynamics, communicating effectively are hallmarks of great engineers. Knowing one's way around people is as valuable as knowing one's way around a codebase. Building consensus is as important as building great software. But none of that automatically makes you a good manager.

In my experience, the best managers operate somewhere at the intersection of both worlds and make it seem effortless to jump between the two as needed.

Don't take my word for it. Just ask Peter!

Peter saw it coming. Well, Laurence J. Peter did. In 1969, together with Raymond Hull, he put a name to what many had already been witnessing. In fewer than 200 pages, The Peter Principle walks us through a series of workplace vignettes and observations that have, perhaps unsurprisingly, withstood the test of time.

The book's thesis goes well beyond what I'm covering in this post, but the most relevant point is the following:

People get promoted based on their performance in their current position, even when these skills are non-transferable to the new position.

The authors provide plenty of examples where employees performing exceptionally well faltered after their next promotion. This is what the book refers to as reaching one's incompetence level. In a hierarchy, a person would keep getting promoted until they hit that ceiling, after which further promotion becomes exceedingly difficult without necessarily resulting in them getting fired.

Look at the hierarchies you've been part of: your organisation, political party or sport club. You'll undoubtedly identify those who have reached their incompetence level. They'd most likely be floating around, being given outlandish titles and a bogus set of responsibilities. VP of consolidated integrations, or Chief integrator of consolidations are usually among the first telling signs.

And on occasions, that person can be your manager or their manager's manager.

And if you're sufficiently self-aware, it might be you.

Buy one problem, get one for free

It didn't happen overnight, but they eventually withered. The lively discussions died out. The engineering challenges dried up. Their vocabulary shifted to a new set of three-letter acronyms and rehearsed axioms. The sparkle in their eyes faded. The transformation was complete.

Slowly but surely, plans derailed. The once exceptional contributors were no longer in the driver's seat. The autonomy they once flaunted gave way to additional layers of control and rigidity. The promise of power stripped their freedom away.

When outstanding engineers turn into mediocre managers, everyone pays the price. The team loses a technical powerhouse who drove things forwards. And now its members have to contend with a leader only by name. Mediocrity breeds and magnifies dysfunction. Conflicts go unresolved. Feedback goes unanswered. Frustration grows. Morale dips.

And then comes the part nobody tells you about. One day, the engineer who was once one of "us" quietly becomes one of "them". And once you're part of that club, there's no finding your way back.

Or is there?

With your tail between your legs

Remaining an individual contributor is (falsely) considered a failure. Going back to that role after a promotion gone off the rails is (falsely) considered career suicide. When the management soul reaper comes knocking, you accept its invitation, only to realise you're not built for it, what do you do? Do you power through and learn on the job? Do you fake it till you somehow make it? Or do you bite the bullet and admit defeat?

Perhaps the best promotion is the one you turn down, or walk away from. Careers don't have to be ladders in the first place (especially if you're afraid of heights).

Mediocrity breeds and magnifies dysfunction. Conflicts go unresolved. Feedback goes unanswered. Frustration grows. Morale dips.

Carve your own role. Find your place under the sun. The options are as limitless as there are ways to centre a div in CSS. Don't let the fear of standing still take you on the wrong journey. A fulfilling engineering position is much more rewarding than an oversized manager title that never truly fits.

If you managed to get this far

An engineer becoming a manager is not a promotion but a lateral career shift. Treat it as such, and the picture becomes clearer. If you have what it takes to be a manager, then by all means go for it. If you're not quite there yet but are willing to invest the time to learn, give it a shot too.

In all other cases, spare yourself and the rest the unnecessary pain and chaos.

The Senior Engineer to Engineering Manager pipeline needs an urgent cleanup. Grab a brush. There's work to do.

Close encounters of the 90s kind

Sun, 17 Aug 2025 00:00:00 GMT

For a Lebanese child growing up in the 90s, my first contact with computers happened relatively early. At 6, my classmates and I were shown into a room full of bulky screens, keyboards and mice. Once a week, we sat in pairs on backless grey benches facing a nameless colouring software. Our tiny hands took turns moving the cursor to fill the outlined canvas with questionable colour combinations.

Alongside this hands-on exercise, the teacher would explain what made a computer tick: processor, memory and all. That glimpse into the machine's entrails thrilled me. It echoed my pathological pleasure in taking my toys apart and seeing what lives inside. I'd convince myself, and my mum, that I'd manage to put them back together. Needless to say, that was rarely the case. I lacked the dexterity (and patience) of experienced factory workers – or robots – assembling those toys in a land far, far away. I was programmed obsolescence personified.

But it wasn't all in vain. Though unspeakable amounts of plastic piled up in Lebanon's faltering waste system, I upcycled a lot of the electronics, in particular, the small motors found in remote-controlled cars. They unwillingly contributed to my super secret space programme. I was convinced that by wiring a motor to a battery pack and attaching spinning blades, I'd create something that flies. I soon upgraded my arsenal by introducing fireworks. Binding rockets sold for New Year's eve together, I finally launched something into space, also known as our upstairs neighbour's balcony. After many attempts, burnt fingers and alleged UFO sightings, I laid my ambitions to rest and moved on to my next classified endeavour.

On some lucky Saturdays, my father, a police officer, took me to work. The Lebanese government was digitalising, just in time for the looming Y2K. Dusty typewriters were on their way out replaced by state-of-the-art computers. So instead of sleeping in, I was ready by 7am, chasing the promise of using that mythical machine in my dad's office. Looking back at it now, I wonder how such a young child was even allowed into the headquarters of police administration. Oh well, the 90s.

At the same road intersection, my father would pick up a fresh copy of the day's newspaper from the usual street vendor. So fresh, in fact, that its pages were still warm. Stuck in Beirut's stifling traffic jams, he'd glance at the major headlines. Luckily, we were never stopped by the police. I'd reach for the science and technology section and pretend to understand its dense medieval Arabic jargon. News about actual space programmes and how we'd all be living on Mars by the year 2000 lit up my developing brain with excitement. Bumper to bumper on Earth, my mission to conquer the computer was still on the launchpad.

Once at the office, my dad would start his day, and I'd sit mesmerised by the computer, next to a policeman typing away. Handwritten notes flew from all sides, and landed in Microsoft Word before being regurgitated by a giant printer. His fingers danced across the mechanical keys as his eyes oscillated between the paper stack on his desk and the screen, never once glancing at his hands. At exactly 1pm, his shift ended and the computer became mine.

My father, ever the workaholic, never left on time, which gave me a couple of hours of uninterrupted me time with the computer. The ergonomic chair adjusted, I faced the bulging screen and let my imagination run wild. The Windows 3.1 operating system, set to Arabic, greeted me with a right-to-left UI, flipping the script from the French-only computers we had at school.

The main attraction was the handful of pre-installed games, namely Minesweeper and SkiFree. The first was too complicated for my budding synapses. Even at 36, I still blow up more often than I care to admit. The latter was more accessible, but equally terrifying. Being ambushed and eaten by the monster lurking on the slopes might be why I never learned to ski. Crushed by a mountain of losses, I'd turn to Paint for some embarrassing artistic mishaps. Occasionally, I even used that computer for school projects just for a chance to look down at my classmates stuck in the 80s.

I kept up that Saturday ritual for a couple of years, during which the computer was upgraded to the then-shiny Windows 95, and the glorious Solitaire kept me busy for hours on end. Meanwhile, the school's computer curriculum intensified. Long gone were the days of colouring, and in came Microsoft Office and Photoshop. A vague mention of something called "the Internet" was casually dropped every now and then.

My first brush with programming came during those classes, but I didn't realise it at the time. A software called Logo made its entrance. It was home to a poor little turtle that responded to commands by crawling and drawing shapes on the screen. In each class, the teacher would first show us the end result, an elaborate matrix of circles, triangles and squares. Then, writing a series of commands, we'd exploit the turtle's free labour to recreate the masterpiece. That mass-produced art suggested it was possible to "talk" to computers.

Then came Frontpage, Microsoft's stab at creating a WYSIWYG web editor. The plethora of marquee and blink elements I placed on those pages was certainly in poor taste, and the unintelligible HTML and JavaScript generated would have failed any W3C validation. Little did I know I was looking at markup and code a machine could understand.

Some of my friends and relatives had their own computers at home with a library of games living on flimsy floppy disks. Lebanese mothers used to treat computers almost like a piece of vintage furniture that needed to be protected at any cost. Eating anywhere in their vicinity was strictly forbidden. Once turned off, the computer had to be covered to shield it from sunlight, dust and whatever breaking news was airing on post-civil war Lebanese TV.

I finally got my hands on my first personal computer at 9. A friend of my father's running an engineering company was getting rid of some older models, and I happily rescued one from a certain death. It found a proud spot on our large, rarely used dining table. It came with a stack of applications and games. Apparently engineers love to play during work hours. Who knew?. The one I distinctly remember was Duke Nukem 3D, which I played for countless hours, despite not meeting its minimum age and possibly system requirements. The awareness around the dangers of violent video games and their effects on children hadn't reached our side of the Mediterranean yet.

My only real exposure to video games, apart from playing at friends’ houses, came from the cheap NES knock-offs that flooded the Lebanese market in the early 90s. The seemingly 3D graphics of Duke Nukem looked like a million light-year leap compared to the flickering 2D sprites of Mario and Luigi. The game even had mirrors, which I mistook for windows, and I'd keep shooting at my own reflection thinking it was my evil clone. Not knowing about save files, I'd always die on the third level – often courtesy of a rocket launcher at close range through a "window" – and start from scratch.

I also got hooked on running the Defrag tool religiously. Questionable claims of speed gains aside, the hypnotic show of coloured hard drive blocks slotting into place was too strong to resist. But my addictions came to an abrupt end on the fateful day my computer died – or rather the day I killed it. In the spirit of optimisation, I made my way to the System32 folder and discovered a treasure trove of programmes with funny names and even funnier icons. And what did 10-year-me do? Delete them one... by... one. The hard drive space freed gave me a high, followed by a crash the next time I tried to start the computer; it wouldn't boot. Thank God I had no Duke Nukem save files on there.

And so I survived the next two years without my own PC. The once-a-week computer class at school tried to scratch the itch but failed. As the 90s were about to wrap, the excitement and apprehension around the coming millennium were tangible. In the pages of my Dad's daily newspaper much ink was being spilled on the looming Y2K crash and the promised colonisation of Mars.

And with that the first part comes to an end. Would you like to save your progress before loading the next level? This might take a while

Remembering jQuery

Sun, 04 Sep 2022 00:00:00 GMT

Mention jQuery to any web developer, and you’re sure to get a mix of laughter and disdain. Worst yet, many younger developers might only have a vague idea, if any, of what jQuery is. It is seen as a relic of the past, a time when front-end development was nothing more than a bunch of CSS and JavaScript thrown together to make a website look “cool”.

Front-end development has established itself as a separate discipline within the last decade. What was once an afterthought became an essential building block of the web. In the process. jQuery has been dethroned and its role often forgotten or ridiculed.

Let us all take a minute to remember jQuery, understand its impact and celebrate its legacy.

What did jQuery bring to the table?

Mending the incompatibilities

We take it for granted that things just work across different browsers, but back in the mid-2000s that wasn't always the case. With Internet Explorer reigning over the web, incompatible implementations were the reality of many web developers.

There were multiple ways to send an asynchronous network request. Event handling had its quirks on some browsers. Getting a DOM element's bounds was handled differently as well.

jQuery provided a unified API that checked for and mended those inconsistencies.

Selecting DOM elements

Before the introduction of the Selector API in 2013, selecting DOM elements by anything other than class, ID or tag name wasn't an easy task.

jQuery shipped with its powerful CSS selector engine, later branded as Sizzle. It made it possible to select almost any DOM element using a familiar CSS syntax. It even went on to inspire the standard Selector API.

Out-of-box utilities

jQuery lowered the barrier to entry for many aspects of JavaScript programming and DOM manipulations.

It shipped with a vast array of perks, such as:

Animation API
Hiding and showing elements
Event Delegation
Chaining of DOM operations

There's a plugin for that

Last and certainly not least, a complex ecosystem of third-party plugins formed around jQuery. From carousels to form error validation and parallax effects, all the cool kids were using a jQuery plugin for that.

Some of those plugins can be considered a precursor to modern web components or components in other JavaScript libraries/frameworks that encapsulate UI and functionality.

Too big to fail?

For many developers, jQuery was synonymous with JavaScript. In fact, many had their first contact with the language using the library. Numerous JavaScript questions on Stack Overflow have answers assuming jQuery is being used.

jQuery was doing too many things at once. It was a hybrid, half-library half-framework, that kept on growing. It powered a large percentage of websites worldwide. Not only that, but it also contributed to the success of many other projects. WordPress, Bootstrap and Backbone.js are just a few examples.

The decline

The decline of jQuery correlates with that of Internet Explorer. The popularity of Firefox and Chrome meant browsers had to adhere closer to web standards. Long gone were the days when browsers would differentiate themselves by shipping proprietary features. Now they had to compete in other areas: performance, stability, security and privacy.

The proliferation of Webkit-based and later Chromium-based browsers gave a large portion of internet users a minimum set of capabilities that web developers could take for granted. While renegades like Safari still exist, the Web has moved on.

With incompatibilities less of an issue, web development moved on to greener pastures. DOM manipulation was no longer enough to create the kind of experiences that the Web wanted to deliver. Projects such as Angular.js, Ember.js and React were showing the world that fully-fledged web application are a reality.

jQuery felt suddenly outdated. While not all that shines is gold and the craze around single-page applications seems to be subsiding, there’s no denying that jQuery couldn’t keep up. Despite attempts at modernising, the writing was on the wall.

The legacy

jQuery is not dead, however. It still powers many websites. As of September 2022, w3techs.com reports that 77.4% of websites worldwide use jQuery. That’s an impressive number, especially compared to a popular library such as React standing at 3% for the same period.

jQuery has had a considerable impact on the Web. Not only did it democratise front-end development, but also inspired numerous projects and successors. Influenced by jQuery and wanting to correct some of its antipatterns, a vast array of libraries and frameworks have emerged and helped shape the landscape of web development.

The best thing that jQuery has given us? It stopped being needed.

We are Agile, but...

Sat, 24 Jul 2021 00:00:00 GMT

Many companies and teams have lost sight of what being agile is all about. It has become a taboo not to mention "Agile" in job postings, onboarding and team lingo. Work, on the other hand, has remained as rigid as ever. Preaching one thing and doing the opposite has created the perfect environment for keeping employees confused, questioning and underperforming.

The following is a list of anecdotes that illustrate this situation.

We discuss the process 10 hours a week

Being agile extends to the process and keeps refining it based on the team’s needs. In reality, the process is used as a panacea for the team’s dysfunctioning. Everyone is encouraged to blame it on the process (or its loose application) when things go wrong. When teams underperform, it can only mean they haven’t been “Agile” enough.

Our daily standup HAS to take place at 9 am

Few things are more rigid than ceremonies that have to happen at specific times or intervals. Forcing everyone to spill out their updates at the same time every day has no advantages. Self-organising teams know how and when to communicate their progress.

We spend weeks crafting our 6-month roadmap

Long roadmaps are the antithesis of agility. Anybody who claims they know the future is either lying, delusional or a combination of both. Being agile is about learning from the past and focusing on the present. For all intents and purposes, the future might never happen. Products get cancelled, markets change and consumers move on. Time spent on roadmaps is time the team hasn’t used to deliver value.

Our estimations are on point. That’s what management says

Agile teams are endowed with the magical ability of accurately estimating their work. They intuitively eliminate all uncertainty and spit out cookie-cutter solutions. This in turns keeps management happy as they see numbers and charts flashed in presentations. Meanwhile, developer sanity and user needs are crying in the corner.

We take feedback seriously… when it doesn't interfere with our roadmap

The six-month ~~manifesto~~ roadmap is infallible. The great minds that crafted it know better. User feedback is left to rot in a spreadsheet away from the team’s reach. After all, the developers are tasked with the important work: Moving tickets to “Done”. Users can wait; the priority is for the burndown chart to hit 0.

We like to experiment… with our retrospective format

Keeping up with the never-ending discussions about the process, the team is sold the illusion they are free to self-organise. They are encouraged to try different formats for their ceremonies, in line with what blog post the CTO has recently read. Experimentation with the product and development is frowned upon and discarded. The mythical next quarter is apparently the best time for that.

We react to change… in our checkbox and radio button components

Developers are asked to write code day in, day out. They don’t need to speak up, understand the product or interact with the user. They are intentionally kept in a state of blissful ignorance. Many are led to believe it is in their best interest not to be interrupted all day long. In the meantime, a bunch of know-betters are delivering their godly revelations to the team.

We believe in continuous delivery… when our CI/CD pipeline is not down

Budget-conscious managers are very picky. They can't stop preaching the importance of reducing costs. They cut down external services and, sometimes, replace them with subpar internal tools. At the same time, they don’t hesitate to hire tens of new developers to “move faster”. The typical victims are tools considered non-critical. Why invest in a CI/CD pipeline when developers can do that manually? Automation only makes sense when setting up Slack reminders for the daily standup meeting.

We move fast... to keep our Jira board up to date

Soon enough, the "Agile" mindset turns into an obsessive disorder. The artefacts and ceremonies become the holy grail that must be protected and revered at any cost. God forbid the backlog doesn’t reflect the current status of development. God forbid a user story finds itself in the wrong column. God forbid someone questions the utility of that.

We don't deploy on Fridays... or any weekday for that matter

How to give developers the impression you care about their wellbeing? Forbid deployments on Fridays. What’s better than enjoying the weekend undisturbed by emergencies? In reality, it is a testament to how little faith managers have in the release strategies and pipelines. Pushing value to the user should happen all the time. The team’s mission is to make that a reality.

Scrum is not for humans

Sun, 16 Aug 2020 00:00:00 GMT

Not a single workday goes by without hearing people praising the virtues of Agile. For many, Agile became synonymous with Scrum. In this article, I argue that Scrum is very hostile to developers. More generally, I will explain why Scrum is not designed for humans.

I'm not planning on explaining what Scrum is. There are numerous resources that could do that better. The Scrum guide is a good place to start. In a nutshell, Scrum is a framework for product development with its sets of roles, artefacts and ceremonies. No, I’m not talking about a cult or a secret society. I’m talking about something that has become at the core of many people's work life.

Scrum is anti-developer

In his book Developer Hegemony, Erik Dietrich makes a very interesting observation. He notes that developers are a hot commodity nowadays. Companies are willing to shell high salaries and incentive packages to recruit the best talent. However, once those developers join a company, they are faced with impediments that stop them from reaching their true potential. Mountains of bureaucracy, layers of management and interfering with their daily work are just a few examples of that. Dietrich imagines a future where developers flip the table and take back control. We are not talking communist revolution and seizing the means of production. We are talking about being in charge of their destiny and actually delivering their full potential.

Scrum is yet another red tape thrown at developers. Instead of allowing developers to self-organise, someone high in their lofty tower decides how the team should be working. Funny enough, the Agile bug seems to only infect developers. The remaining parts of the organisation are unfazed. The same people forcing Scrum down developer’s throats would not be even there if the organisation were truly agile.

I dislike Scrum because it makes a few wrong assumptions. First, that developers are lazy and need to be micromanaged to deliver. While many developers can be underperforming, putting them under the spotlight will only make the problem worse. Second, that the process of software creation is indistinguishable from any industrial manufacturing process. Claiming that uncertainty and unpredictability are not inherent parts of software engineering is as good as relying on the planets' positions to determine one’s destiny.

It is true that not all developers are exemplary employees, but more often than not they want to give their best and be proud about the products they deliver. When things go wrong in the development team, people are quick to jump to the conclusion that developers have to be micromanaged to extract every ounce of productivity from them. However, the problem is often somewhere else in the chain.

A game of poker

Scrum advocates estimation as a way of managing the team's workload. At first glance, that seems to be a very developer-friendly measure. Who wouldn't want to achieve a constant pace of delivery that keeps the users happy and saves the development team from burndown? In practice, estimations end up being yet another pressure mechanism.

Humans work in different ways, at different speeds and at different times. The myth of a constant pace of delivery does not reflect the reality of working in software development. Developers have good days and bad days. They exist outside the realm of their roles at work. They get sick, go on holidays, lose motivation etc.

Uncertainty and unpredictability are hallmarks of software creation. That by itself is enough to invalidate the need for estimations. Pushing them on a team is a game of dishonesty and lack of trust. Everybody involved knows that those numbers carry little value. The time wasted making predictions and false promises should be used to bring real value to users instead.

Developers are not stupid. When they can't change the system, they start to game it. They will use estimations to advance their own agenda. They will overestimate and deliver less. They will underestimate to make sure something they feel passionate about is picked up for development.

What do you stand for?

The Scrum guide defines the daily stand-up as a short meeting for the development team to discuss their progress and impediments. In theory, I see some value in that. However, it makes the misinformed assumption that a team needs a specific ceremony to talk. In practice, teammates should and do exchange ideas all the time.

What happens more often than not is the liberal reinterpretation of the daily stand-up. Managers and product owners attend and turn this ceremony into a status update meeting. Developers are ~~forced~~ encouraged to share the teeny tiny details of their work with people who probably have little knowledge of and no interest in what is being said.

Worse still, many companies use the daily stand-up as a sneaky way to get everyone in the office by a certain hour. This hinders any prospects for flexible working hours or remote work. Attending the daily stand-up becomes the number one reason why people show up at work, not the work itself.

Build it and they'll come

Scrum is a great masquerade for agility. True agility requires no ceremonies and no artefacts. True agility is a cross-organisation mindset that doesn’t apply to the development team only.

By adopting Scrum and following its guide, either to the letter or not, people believe they will magically become agile. The belief is that a time-delimited sprint ensures the ability to change course. That having retrospective meetings will enable the team to iron out issues in their process. That estimating and measuring the team’s velocity will make people more productive. In reality, none of that is true.

Scrum has become a perfect example of cargo cult agile. Everyone is waiting for the benefits to come raining down. In reality, the sky is blue with no clouds in sight, even though the team has been doing its rain dance for weeks.

Scrum often hides the fact that true impediments are not in the development team itself, but further up in the hierarchy. The “follow the Scrum guide” commandment is a great mirror and smoke show for denying true change elsewhere in the organisation. The narrative is often flipped to suggest that the team problems stem from not applying Scrum strictly enough, for being too lenient in estimations and too ineffective in their retrospective. They are encouraged to dive deeper into Scrum while the rest of the organisation remains unchanged.

Going clear

Some teams can and will use Scrum. A prepackaged workflow could work under certain circumstances, but it achieves nothing in terms of agility. Agility is the antithesis of process and ceremonies. Agility is giving a development team trust to self-organise. Agility transcends all layers of an organisation. In fact, a truly agile organisation does away with most of its layers.

Be careful anytime you buy into a methodology with inflated claims, rigid rules and unintuitive workflows. An ecosystem backed by certifications and “coaches” will create a feedback loop that perpetuates its shortcomings and hinders true progress.

Any team can and should decide its own workflow. Processes are discovered, adopted and improved along the way. If you are a developer, make sure you are part of that conversation. By deferring those decisions to the “wise” men and women of the organisation, you give up the agency to determine your own fate. Any process in place should be there to serve you and not the other way around.

Don't start with React

Sat, 25 Jan 2020 00:00:00 GMT

If you are getting started in web development, it is tempting to learn the most used technologies early on. More and more junior developers are investing in React through self learning or coding boot camps.

The problem?

While React is a great choice for building many types of applications, it is important to understand that there are alternatives. More crucially, React exists to solve a set of problems that developers face. Understand those problems first, and learn React next.

A little bit of history

People doing web development from the mid-90s till the mid-2000s experienced the dominance of Internet Explorer, incompatibilities between browser engines, slow advancements in the web and a lack of good practices to organise code.

Creating anything using JavaScript meant worrying about problems such as:

Having the DOM reflect the application's state.
Organising the code and splitting it into different files.
Adding and removing event listener.

Several solutions to these problems were introduced. jQuery made it easier to manipulate the DOM. RequireJs gave developers a way to break down applications into multiple files and load them in the browser. Tools such as Gulp, Grunt and later Webpack improved the build experience even further. Frameworks such as BackboneJs, Ember and later AngularJs offered a way to structure applications and organise the code.

Enter React

At first glance, React looks like a step backwards. React focuses on the View layer instead of embracing the full MVC architecture. Unlike its predecessors and some of its peers, React offers no out-of-the-box solutions for common needs such as routing, state management or styling. The distinction gives React the status of a library and not a framework.

What problems is React solving?

Having the UI reflect the app state

React’s goal is eliminating manual manipulation of the DOM. Instead of querying a certain node to update its attributes or children, you would describe the end result you want and React will take care of the rest.

To achieve that, React dumps the common paradigm of separating HTML and JavaScript. Your JavaScript code is no longer there to manipulate the UI created by HTML. Your JavaScript IS THE UI. (React still permits direct DOM manipulation using refs)

DOM updates are expensive

React makes updates to the DOM less expensive by comparing what the browser is rendering with what your UI is describing. This should improve the user experience in the browser.

Event management is messy

React simplifies event management by adding a single event listener to the root of the document. This should reduce memory leaks introduced by complex event listeners in an application.

Code is unorganised

React offers a way to organise code by breaking it down into components. This encourages the application to be broken down into simple units, respecting the single responsibility principle.

The best of both worlds

Understanding how the DOM works, its limitations and bottlenecks is an essential skill to create client-side web applications. Learning libraries and frameworks early on masks those complexities. It deprives you of understanding what is going on in the browser.

Those libraries and frameworks are just syntactic sugar around what the browser can natively do. It all boils down to what the JavaScript engine is doing and how the DOM is updated. This knowledge is essential to catch bugs and avoid performance issues.

Learn how to create an application using nothing more than HTML, JavaScript and CSS. Feel the pain of managing state, events and DOM updates manually. Understand the common pitfalls, the performance bottlenecks and memory leaks. Transition to an MVC framework. Understand that your front-end code can be organised and architected. Pick an old framework and give it a test drive. Backbone.JS is a great introduction to application frameworks. Finally, learn React.

Conclusion

Don’t limit yourself to a certain library or framework. Eventually, the next big thing will come and sweep them off. Focus instead on what changes slowly. React will disappear, but the browser will not.