Dodgy Coder

There is a silent heist happening in the billable hours of every major software agency. We’ve entered a Golden Hour - a brief, high-stakes arbitrage window where the cost of production has cratered, but the price tag remains frozen in 2022.

History is littered with these windows. They are defined by Knowledge Asymmetry: the gap between what a client thinks it takes to build a product and the time it actually takes, using a magical new tech.

We are living through the Agentic AI version of this playbook. In the time it takes a client to finish a discovery meeting on Teams, an agent has already drafted, tested, and hallucinated its way through the first 40% of the codebase. The agency is billing for the month; the machine finished before the coffee got cold.

Here are the most iconic historical parallels to the Great AI Arbitrage:

In the 1450s, a hand-copied Bible took a scribe about a year to complete. The price reflected 12 months of high-level professional labor.

The Tech: Johannes Gutenberg’s movable type press.

The Arbitrage: Early printers were notorious for trying to make their books look exactly like hand-copied manuscripts. They used the same ligatures, the same layouts, and sometimes even had artists hand-illuminate the first letters of a printed page. They charged scribe prices for a product that was essentially mass-produced. 

In the early 1800s, if a part of your rifle broke, a master gunsmith had to hand-forge a unique replacement. You paid for that master craftsmanship.

The Tech: The transition to interchangeable parts (mass production); machines began stamping out identical components.

The Arbitrage: Government contractors and factory owners keep billing for "fitting and filing" (the manual labor of a master gunsmith) long after the parts were being stamped out by low-skill laborers using jigs. 

Here is the deeper breakdown of what happened:

Before CNC, a master machinist was a craftsman with specific knowledge. They didn't just turn handles on the lathe; they had "the feel" for how metal reacted to heat and speed. This was deep, learned knowledge - it couldn't be easily written down or taught to someone else, and it gave those machinists immense leverage over shop owners.

• The Tech: G-code and microprocessors made that deep knowledge redundant. The new machine could replay its tool-paths perfectly every time, regardless of whether the operator understood the physics of the cut.

• The Arbitrage: Shop owners realized they could buy one $80,000 CNC lathe (the price of about 12 manual lathes in 1981) and hire a "button-pusher" CNC operator at 40% of the Master Machinist's wage to run it.

• The AI Parallel: Today, an agency can use Claude Code to replace a team of senior developer SMEs on a complex legacy project with one AI "prompt-pusher" keeping a zombie legacy project on life support.

This is where the real money was made. In the 1980s, the market rate for precision machining was anchored to the labor of the machinist.

• The Old Reality: If a complex aerospace part took 10 hours to hand-mill, the client was quoted for 10 hours of a senior machinist's time.

• The CNC Reality: The machine could churn out that same valve in 45 minutes. Shop owners would literally hide the humming CNC machines out the back, and keep the master machinist hovering out the front for the clients to meet.

• The Play: Shops didn't tell the clients. They continued to bill for the 10 hours.

• The Result: Profit margins jumped from a standard 20% to a staggering 500% on certain parts, just by exploiting the client's ignorance of the new CNC speed increases.

Historian David Noble argued that CNC machines weren't better when they first came out - manual machinists were often faster for one-off parts. However, management pushed CNC primarily because it removed the knowledge monopoly from the workers.

• With CNC, the knowledge moved from the shop floor to the office floor.

• It allowed management to dictate the pace of work without the machinist ever needing to be consulted.

• The Pivot: If you were just "making parts", you were a commodity. If you were providing "Aerospace-Grade Quality Assurance and Material Traceability" you could still charge a premium. You stopped selling the shaping of metal and started selling the certainty of the result.
  
  
• Master Machinists became Manufacturing Engineers. They traded their manual "feel" for process optimization. A shop might have 5 CNC machines, but they still needed someone who understood the physics of metallurgy to ensure those machines didn't destroy $50,000 worth of carbide tools in a single afternoon.
  
  
• The AI Parallel: In 2027, writing code will be a commodity. The thing clients will pay for in the future is functional and architectural assurance... did you build the right thing, and build the thing right?

"Talk is cheap. Show me the code."
- Linus Torvalds, 2000

"Code is cheap. Show me the users."
- Me, 2026

In 2023, if you had a bullshit idea (like a social media app for cats), you still had to find $50,000 or 6 months of your own life to build a prototype. 

That cost acted as a bullshit filter.

In 2026, that filter is gone. Code has become cheap, and the bullshit has become infinite. If you can’t find a single user before you hit 'Generate' you haven't built a tool; you've just automated the process of adding to the internet's infinite landfill.

We’ve been here before. In 2000, millions of bullshit apps came out of Microsoft Access and VB6. For the first time, a department manager could drag-and-drop a few components, click a wizard, and 'build' a billing system. It felt like magic, but it mostly resulted in a million fragile .MDB files on desktops and a nightmare to maintain. Today, we aren't dragging buttons; we're vibe-coding entire repos. The tech changed, but the delusion remains: just because you can build it doesn't mean you should.

With tools like Claude Code or DeepSeek-V4, a non-technical founder can go from napkin sketch to a hosted, functional web app in a single afternoon. Due to this, we're in a supply-side explosion of Zombie Apps - AI generated apps with no users - beautiful, functional, and completely hollow. Because the cost to maintain a web app with a negligible userbase is less than a cup of coffee per month, they can stay online forever, creating a graveyard of functional software that no one ever logs into.

We'll end up with a long tail of these apps that never get used. Think of it as the YouTube-ification of software. 90% of all uploaded videos on YouTube never break 1000 views, and 25% get exactly zero views. A vibe coded SaaS is the same... a perfectly rendered concert performed in an empty stadium. 

Building an app may be almost free, but getting someone to care about it has never been more expensive. The truth is that with a SaaS, the code has never been the most important part, it's always been "product/market fit", and the ability to grow an active community of users who need your product. There is still a massive market for a focused SaaS that solves a real problem, but in 2026 shipping it isn't the victory - growing a real user base is.

Follow @dodgy_coder on X

At CES 2026, Oshkosh Corporation took the stage not just as a vehicle manufacturer, but as a data powerhouse. Their flagship innovation for the "Neighborhood of the Future" is an AI-Powered Contamination Detection system integrated into their refuse and recycling fleets.

The stated goal is noble of course - "Landfill Diversion" - by using advanced cameras and on-the-edge AI processing, these trucks scan every piece of waste as it falls into the hopper. The system identifies contaminants (like a plastic bag in the paper bin or a greasy pizza box) and uses onboard GPS to map that issue back to your home address. The city then sends you a friendly, automated SMS educating you on your recycling sins. It’s efficient, it’s green, and it’s powered by the same tech used in autonomous combat vehicles.

As every developer knows, hardware is just a shell for the software running on it. While the truck currently only looks for plastic bags, theoretically a software update could turn it into a collector of household product consumption data.

Imagine a local cash-strapped city council realizing that their recycling program is a cost center, but their waste data collection program is a cash goldmine. With one firmware push, the AI models are updated to recognize not just cardboard or plastic but specific brand logos, product SKUs, and consumption volumes. Your bin is no longer just a waste dump; it’s a physical record of your household's consumption patterns ... sitting on a public curb with zero legal expectation of privacy.

Once the AI is brand and product aware, it becomes a tool for monetization via these potential goldmines of garbage:

• Retail Data: Why spend millions on broadcast ads when you can buy a report from the local council showing exactly which households are throwing out competitor brand's packaging? A cereal company could target "Kellogg's households" with high-precision mailouts, product samples, or localized digital ads.

• Health Profiling: By detecting medicine bottles and food packaging, AI can build a neighborhood health profile. It'd be highly valuable to insurance actuaries and pharmaceutical giants, who would love to know the "wellness score" of a specific zip code.

• Health Insurance: The AI detects an above-average volume of beer cans at your address. Does your health insurance premium go up next year?

• The Green Tax: Left-leaning councils could move beyond flat waste fees to "Environmental Impact Taxes" based on the volume of non-sustainable brands or products detected in your garbage. Did you buy a pack of ribeye beef steaks this week, you carnivorous bastard? Then you'll need to pay $10 towards reversing the deforestation of the Amazon.

• Fast Food Giants: Mapping market share hotspots by suburb... "We only have a 20% market share in this zip code; let’s put a new billboard up."

AI powered garbage truck technology means that the contents of your bin are eventually going to be opened up to the local council. 

The next time you hear a garbage truck cruising by at 6:00 AM, don't get annoyed by the noise; think about the sensors scanning your bad habits, one pizza box at a time... ;-)

References
The 2025 Deepnest Report: What Waste Data Revealed About Recyclability
Turning Trash into Transparency: Nawa's AI-Driven Vision for Global Recycling
Robotic Collection and AI-Powered Contamination Detection Spotlighted at CES 2026
Dallas to install AI cameras on garbage trucks

Follow @dodgy_coder on X

AI Agents hooked up directly to the customer over SMS text messaging are a disaster waiting to happen. 

A chatbot bug had real world consequences for a United Airlines customer last week - their booking got cancelled by mistake.

The chatbot presented two options:

A) Yes, cancel & get a refund
B) No, not ready to cancel

Pretty simple you'd think, but when the customer replied B, it completely lost the context of the command and went ahead with A, the opposite option.

So the lesson here is don't trust a chatbot to know what its doing at all, and for anything important, just use the company's app or website directly. If its a complex issue, call them up and talk to an actual employee... it will probably save your time in the end.


The simple text based interface was used for many years before windows & mouse interfaces became dominant during the 1990s. Unfortunately some AI agents aren't capable of getting a basic text interface like this correct yet.

References:
https://www.reddit.com/r/unitedairlines/comments/1qrrvfd/am_i_stupid_for_did_i_just_get_screwed_by_the_ai/
https://www.slalom.com/au/en/customer-stories/united-airlines-gen-ai
https://www.cio.com/article/3969476/united-airlines-ai-strategy-the-airline-that-makes-decisions-fastest-wins.html

Follow @dodgy_coder on X

The iPhone Triple Zero Meltdown is a textbook example of a safety regression, where a software patch meant to fix a critical vulnerability ends up creating a larger disaster.

The incident sent shockwaves through the Australian telecommunications industry and resulted in tens of thousands of people not being able to call Triple Zero / 000 (the Aussie equivalent of US 911 or UK 999).

Following an Optus network outage in late 2025, Aussie regulators discovered that older 4G phones had a lethal flaw: if their primary network (e.g. Telstra) went down, the phones couldn't always "camp on" to a backup alternative network (like Optus) to dial emergency services.

To address the problem, Apple proactively released an emergency patch (iOS 16.7.13) specifically to fix the emergency service failover logic on older devices (like the iPhone 8/8+ and iPhone X). That iOS update was released on Australia Day - Monday, January 26th, 2026.

On January 28th, 2026, the Telstra customers who had installed the iOS 16.7.13 patch woke up to find their iPhones had no connectivity.

• The Bug: The update contained a flawed Carrier Settings profile that effectively mangled the handshake between the iPhone and Telstra’s towers.

• The Irony: The software designed to ensure emergency calls always worked ended up preventing the phone from connecting to the network at all. Users couldn't call / text, or use data - and most importantly - couldn't reach the emergency number, 000.
  
  

Apple and Telstra pushed out a hastily prepared "Carrier Settings Update" within 24 hours of the issue happening.

• The Fix: Users were told to connect to Wi-Fi and navigate to Settings > General > About. A prompt would appear asking them to "Update to Telstra 54.1".

• The Reality: For many regional Australians without a home Wi-Fi network, their only lifeline (their phone) was dead, and they had no way to download the fix that would bring it back to life. So they had to drive to the nearest public library or McDonald’s to get the patch, and restore their phone.

• https://www.abc.net.au/news/2026-01-28/telstra-warns-older-iphones-may-be-unable-to-connect-to-network/106280356
• https://www.reddit.com/r/australia/comments/1qp23gf/any_older_iphone_users_8_x_etc_do_not_install_the/
• https://www.telstra.com.au/exchange/iphone-calling-issue--what-you-need-to-know

Why it happens

Airline booking systems (aka Global Distribution Systems / GDS) cannot split a single booking across "buckets" (fare classes). If there are two seats left at $250 and you need four, the system doesn't give you two at $250 and two at $400 (which would be common sense). It bumps the entire group into the higher bucket, which is $400 per ticket.

The UI rarely explains this. It just silently adjusts the price for everyone, hoping you'll just put it down to tickets selling out quickly right now, or some other cause like dynamic pricing.

The root cause

Its caused by a 50-year-old legacy backend design. Airlines use buckets, denoted by single letters (Y, B, M, K, L, etc.). The GDS treat a booking as an atomic unit, so if you search for a party of four, the system only tries to find four seats within the same fare bucket.

Example - when a booking engine sends a "Sell Request" to the backend, it sends a single message:

SELL 4 SEATS IN CLASS Q

The legacy backend that receives the request is pretty basic - it doesn't have the ability to apply the logic, "I only have 2 left in Q, so I'll give you those and put the remaining 2 in M." It instead just looks at the remaining seats in Class Q.

If Available < Requested, it returns:

ERROR CLASS UNAVAILABLE

The booking middleware is programmed to catch that error and retry the request for the next bucket letter, until it finds a bucket which has the required number of total seats available, which means the request succeeds.

How to minimise your group fare

Given this limitation, how can you ensure you always pay the minimum possible? Its a pretty simple method - the one-by-one search technique. Search for one passenger first. Keep incrementing the number of passengers you search for, until the price per ticket bumps up. Then you know how many seats remain in the cheapest bucket. So exhaust that cheapest bucket before going ahead with the the rest of your booking. 

Why don't Airlines fix it?

So why haven't they fixed this core issue - that's in fact a "group booking tax"? The answer is likely technical debt on a global scale combined with the lack of a financial incentive. To change it, you’d have to synchronize updates across tens of thousands of travel agencies, hundreds of airlines, and third-party aggregators. 

Rather than fixing the root issue, the industry just builds layers of shiny new wrapper APIs on top of the same legacy core. Another name for this is pig's lipstick code.

Follow @dodgy_coder on X

We’ve all been there... it’s 2pm on a Friday and you’ve just found a bug that defies logic. You don't have time for a robust architectural solution. You have time for a few lines of code that will do the job.

You then tell yourself the biggest lie in software development: I’ll refactor this later. In reality, that temporary hack often ends up becoming the foundation of the entire system. 

If you feel guilty about the random spaghetti code currently holding your production environment together, take heart. Some of the most iconic features in tech history weren't the result of visionary genius or months of planning. They were accidents, hardware limitations, and temporary placeholders that refused to die.

From a core function of the Windows O/S, to the games that defined a generation, the software industry is built on a pile of good enough Friday afternoon hacks that accidentally changed the world.

Here's three famous examples of random hacks that became permanent legends.

1. The Windows Format Dialog's 30 Year Legacy

If you’ve used Windows at any point in the last thirty years, you’ve seen it: the utilitarian, grey format drive dialog box. It’s got a few dropdowns, a quick format checkbox, and a rigid refusal to format any drive larger than 32GB as FAT32.

You might assume a committee of Microsoft architects spent months weighing the trade-offs of cluster sizes and file system overhead to arrive at that 32GB limit.

How it went down: It was one guy, a rainy Thursday morning, and a massive case of this'll do for now.

In 1994, developer Dave Plummer was busy porting the user interface from Windows NT to Windows 95. He reached the Format tool and realized the existing UI wasn't going to cut it. So, he pulled out a piece of paper, noted down the features he thought a user might need (filesystem, cluster size, label), and whipped up a basic vertical stack of options.

He didn't like the look of it. It was meant to be a rough draft, a placeholder that someone else would prettify. To top it off, he had to decide on a maximum volume limit for the FAT32 format. He arbitrarily picked 32GB as the cap, thinking that would be plenty for the hardware of the mid-90s and that someone would eventually write a better tool to replace his placeholder.

The result: Microsoft never replaced it. Dave's Format dialog survived through Windows 98, XP, Vista, 7, 10, and its still there in Windows 11.

Because of that one quick fix, a generation of IT professionals grew up thinking 32GB was a fundamental limitation of the FAT32 architecture. In reality, it was just the limit of Dave's patience that morning. It is perhaps the longest term temporary UI in the history of computing.

2. Space Invaders: The Difficulty Curve Born from Lag

In modern game design, we talk about pacing and difficulty curves like they are sacred sciences. Designers spend hundreds of hours tweaking variables to ensure a game gets progressively harder as the player gets better.

But in 1978, Tomohiro Nishikado, the creator of the classic video game Space Invaders, didn’t have a difficulty setting variable. He had a much bigger problem: the CPU of the 8-bit Intel 8080 was struggling to keep up.

How it went down: The custom game hardware Nishikado built was, by today’s standards, incredibly underpowered. When the game started, the screen displayed 55 alien invaders and the processor was completely maxxed out. It could barely handle rendering all the sprites let alone moving them across the screen. As a result, the aliens moved in a sluggish, rhythmic crawl, left to right, down, right to left, etc.

But as the player started blasting the invaders, something unintended happened. With every alien removed from the screen, the CPU had one less thing to render. The lighter the load, the faster the processor could loop through the code.

The fewer enemies there were, the faster the remaining ones moved.

The result: Instead of trying to fix the timing (which would have been an engineering nightmare on that hardware), Nishikado realized the bug made the game incredibly tense. The frantic thump-thump-thump of the final few invaders zipping across the screen felt like a deliberate design choice to pressure the player.

He left it in.

In doing so, he accidentally invented the Difficulty Curve. It wasn't a line of code that made the game harder; it was the hardware finally being able to breathe. Next time your app slows down under heavy load, don't call it a performance bottleneck... call it Emergent Gameplay.

3. Street Fighter II: The Bug That Built eSports

If you’ve ever played a fighting game and pulled off a three-hit combo, you owe a debt of gratitude to a piece of code that was technically failing at its job.

In the early 90s, the concept of canceling one animation into another didn't exist. Fighting games were polite; you punched, the animation finished, and then you were allowed to punch again. But during the development of Capcom's Street Fighter II, lead designer Noritaka Funamizu noticed something strange while testing.

How it went down: Funamizu was checking the timing of the special moves (e.g. the Hadouken). To make these complex inputs easier for players to pull off, the developers had added a key input buffer... a small window of time where the game would accept a new input - even if the previous animation hadn't quite finished yet.

He discovered that if he timed hitting buttons perfectly, he could land a normal punch and then cancel the rest of that animation by triggering a special move. This allowed him to hit the opponent twice before they even had a chance to recover.

The result: Funamizu thought the timing was so incredibly difficult to get right that no one would ever be able to reproduce it reliably. He figured it was a hidden quirk that wasn't worth the effort to fix or re-code.

He was wrong.

Players discovered it almost immediately. What Funamizu dismissed as a timing bug became the Combo System. It transformed fighting games from slow, back-and-forth matches into high-speed, technical displays of skill. Today, canceling is a core mechanic in almost every fighting game on the market, all because a Capcom designer found a quirky bug and let it stay in.

In Defense of the Hack

So, what’s the lesson here - should we all start writing half baked quick fixes and hope for a miracle? Not exactly.

But there is a profound truth in these stories: Perfect is the enemy of shipped. The Windows format tool wasn't a masterpiece of UI design, but it solved a problem on a rainy Thursday. Space Invaders lagged because the code didn't take into account the hardware, but it created the sort of tense atmosphere that a clean engine never could. These devs weren't aiming for historical legacy; they were just trying to get the job done with the tools and time at hand.

The next time you’re coding a workaround, don't just see it as a hack. You might be looking at a future industry standard. Or at the least, the duct tape that keeps your company going for another 12 months. So, go forth and ship it - you can always refactor it... later.

Further Reading & Sources

Scenario
A team finds themselves constantly being delayed due to lengthy internal requisition processes and bureaucracy.

Problem
Projects are delayed due to internal bureaucracy. Important pieces of hardware and software are waiting on another part of the organisation to requisition them and set them up.

How it works
Instead of requesting the resources at the point they are needed, the team requests them at the start of their project, or at the end of their previous project. In effect, the team maintains a pool of resources, ready to be used by their next project.

A cost is shifted forward to well before it is actually needed, but the advantage is in the agility of project delivery. There could also be some costs to being on standby (e.g. monthly license fees or server electricity costs).

Scenario
A valuable customer is hit by a major intractable bug or a serious system limitation with your software.

Problem
Your company needs 6-8 weeks to resolve it, but the customer is demanding immediate action or else they'll walk away.

The plan
Get your company an initial 2-4 weeks of time with rounds of meetings and follow up meetings. At the same time, hire a business analyst (or project manager) who may potentially be out of their depth technically, but who can present well at a meeting. 

The new hire is given responsibility for representing the company's position to the customer, and asking for additional development time. At a final crunch meeting, put the new hire in the firing line to answer to the customer's main concern, e.g. exactly what is the technical plan going forward and exactly when and how will the issue be resolved?

This article summarizes the important factors involved when deciding between the two leading cross platform mobile development frameworks of Google's Flutter and Facebook's React Native.

• ✅ It can design complex UIs which are standardized across Android & iOS resulting in less platform dependent bugs.
• ✅ Easier to learn for existing mobile developers. 
• ✅ Dart is a fully object oriented language, so is great for large enterprise size codebases.
• ✅ Good debugging ability and hot reload.
• ✅ A self contained easy to use IDE (Android Studio).
• ✅ Quick ramp up time.

• ❌ Dart is a new language to learn, and isn't used anywhere else except for Flutter.
• ❌ Skills availability in the market is not as good as React Native, although it is growing.
• ❌ All of the UI must be in Flutter - you can't mix native UI components with Flutter.

• 💡 Existing mobile development team.
• 💡 Graphical or UI heavy apps.
• 💡 Greenfield projects.
• 💡 Minimum viable products / startups.

• ✅ Large number of resources and libraries available.
• ✅ OTA (Over The Air) updates; updates to the app outside of the app stores. 
• ✅ Knowledge of React can be applied to web development. 
• ✅ Easier to learn for web developers.
• ✅ Very good skills availability in the market.
• ✅ Can be integrated with existing native UI components.

• ❌ Command line JS-based toolchain.
• ❌ Javascript / Typescript is not as suitable for very large codebases as is Dart.

• 💡 Existing web development team.
• 💡 Migration of an existing app, with the ability to keep some native UI as is.

Follow @dodgy_coder on X

The below is taken from an interview conducted at the Computer History Museum in 2004 by Grady Booch. He interviewed early Apple developers Bill Atkinson and Andy Hertzfeld about the development of the original Apple Mac, and in particular MacPaint software.

On the art of developing software

Grady Booch: So what makes software beautiful for you? Do you care about the beauty of software?

Bill Atkinson: Oh yes, it’s an art form, like any other art form, and it’s not just practical, as in, does it do the job? Is it clean inside, does it look--? I would spend time rewriting whole sections of code to make them more cleanly organized, more clear. 

I’m a firm believer that the best way to prevent bugs is to make it so that you can read through the code and understand exactly what it’s doing, that there’s nothing tricky in it, that it’s all very straightforward. And maybe that was a little bit counter to what I ran into when I first came to Apple. 

There were a lot of people who prided themselves in how this little piece does something that I can’t for the life of me figure out what it is, but it’s magic that it does it. I would do things like deliberately assign something into a variable, and instead of putting ten operations concatenated onto one line, I’d use intermediate variables so I could understand the purpose of each of these. And I liked it. 

I found that if I spent time going over the code, cleaning it up, making it sometimes tighter – I did a lot of measurement and tried to make the performance good – but also making it so that it was straightforward so another person could follow in my footsteps, then I would feel proud of it.

Grady Booch: Don Knuth was telling me that he felt that MacPaint was perhaps one of the most beautiful programs he has ever seen, just in terms of its readability. 

On the MacPaint development process

Bill Atkinson: I had a different method of software developing than Randy Wiggington who was developing MacWrite. We had two different philosophies. Mine was you don’t get to add any new features until what you’ve got is working reliably, solidly; and his was, let’s add all the new features and then let’s debug them. I just think that that’s a bad way to do it because finding bugs is a very unlikely proposition. If you search really hard you might find half the bugs that are there, and the others are going to bite you and you just don’t know when. So I had a little more conservative approach to design.

Grady Booch: What you describe is very similar to what the Agile community speaks of these days; always have something executable through incremental development. And it’s very cool.

Andy Hertzfeld: Yes, yes, that’s really how the Mac was developed.

Grady Booch: You were the first Agiles. So by my count, or others, MacPaint was about 5,804 lines of Pascal and so on; 2,738 lines of assembly language.

Bill Atkinson: Plus all of the QuickDraw I’d built on top, because without QuickDraw you couldn’t do all that stuff.

Grady Booch: And pretty much everything had built upon QuickDraw.

Andy Hertzfeld: Yes.

Bill Atkinson: There were 70,000 lines of assembly language [in QuickDraw]. 

More reading
Computer History Museum: Oral History of Andy Hertzfeld and Bill Atkinson
Revolution in The Valley: The Insanely Great Story of How the Mac Was Made, by Andy Hertzfeld
Folklore: Anecdotes about the development of Apple's original Macintosh
BYTE Magazine (1984): An Interview: The Macintosh Design Team

Follow @dodgy_coder on X

Starting out
When you're starting out your career as a software developer, you'll typically get a first role as either a backend or frontend dev, and after a couple of years, gain some experience on the other side to become a full stack developer.

Company specific lock in
Since every organisation has its own tech stack, a full stack developer in Company A will have a different set of skills than one in Company B. Those additional skills you learn are still useful to boost your knowledge - it can include: specific cloud services, CI/CD, containerization, DevOps processes, a domain specific library or framework, and the company's SDLC process. 

At this point many developers stay committed to their company's tech stack and remain working as a full stack developer for several more years. My advice - don't just coast as a full stack developer,  branch out!

Branching out
Don't limit yourself to web apps.. branch out as soon as you get the chance, by getting some experience with any of these (if possible as part of your day job)...

• Native mobile app development (Swift or Kotlin)
• Cross platform mobile app development (Flutter or React Native)
• Desktop app development
• A newer backend programming language (Golang, Rust or Elixir)
• AI & ML
• UI/UX design using a tool like Figma

• IoT (Arduino or Raspberry Pi)
• Game development (Unity or Unreal)
• Blockchain development 

Become a generalist
Your aim is to become a generalist - someone who has deep knowledge in two or more areas and maintains a broad knowledge across many platforms, languages and frameworks.

After becoming a generalist, you'll be able to switch up your job roles, stretching your capabilities a bit each time you move. You'll find that you can apply for a larger variety of roles, increasing the possibility to land your dream job. 

Adapt to new roles
Your varied knowledge will make it easier to apply your skills in new and unfamiliar areas, building up after some years to become a senior developer. Once there, its possible to remain at the senior level for an extended period - as long as you still enjoy it and are still learning, why not.

Career progression
Eventually you might try for a tech team lead or software architect role. Software architects often started out as generalist developers who gained enough varied experience to be able to apply their software design skills into any domain. Tech leads can have a similar background, but they maintain more of a hands on development focus as part of their role, getting involved especially with creating proof of concepts. 

More reading
Generalist vs Specialist - the difference
Bill Gates on the book "Range: Why Generalists Triumph in a Specialized World", by David Epstein 
"The Polymath: Unlocking the Power of Human Versatility", by Waqas Ahmed
"Polymath: Master Multiple Disciplines", by Peter Hollins
What It Means to Be a Software Architect — and Why It Matters
Following the Software Architecture Career Path

Follow @dodgy_coder on X

Within the .NET ecosystem, two ORMs dominate, the lightweight Dapper (open source) and the fully featured Entity Framework (EF) by Microsoft. 

Depending on your project's size and requirements, either of these should work well for you, but there are definitely some known cases where each is a better fit. That's what we're discussing in this post.

When to use Dapper?

• Small to medium size projects. It has low overhead in terms of setup and configuration.
• The database tables are in place already and you're calling existing stored procedures. This is known as a data first approach.
• You prefer to hand code the SQL for speed, optimization or fine tuning.

When to use Entity Framework?

• Its a large and/or enterprise type project.
• The database hasn't been created yet and you'd like to use a code first approach. The framework will create the database for you after you code the data models.
• You want the ORM to handle transactions for you in the background.
• You need to use the power of C# LINQ (Language Integrated Query), whereby SQL joins and other queries are generated for you based on your C# code.

Other important factors

• Is your project likely to change frameworks, or need to be adapted to other databases? If yes I'd favour Dapper, because there's just less to migrate and configure. Dapper tries to not get in the way. There are no  additional abstractions and class models that happens with EF.
• Are you using .NET Core? Its probably a controversial opinion but I feel that .NET Core as a framework is still quite unstable compared to the original .NET Framework. So when a new version comes out, there's normally breaking changes within EF Core. For that reason I'd also favour Dapper over EF for .NET Core projects.

What's not a factor?

• Speed and performance. There's no longer any significant performance difference between Dapper and EF. Issues with performance are more likely to be something else that's not being done correctly at the SQL level, such as a lack of indexing, or an incorrect query.
• The origin of the framework. The first release EF for .NET which came out in the 2000s had terrible performance. Since that time, all the performance issues have been fixed.

A classic black swan event has just happened to the LUNA cryptocurrency.

A black swan event is characterised by a spectacular run up in price, followed by the price falling off a cliff to near zero.

It famously happened to a hedge fund named LTCM (Long Term Capital Management) back in 1998. The resulting loss temporarily destabilised Wall Street, requiring a bail out to be organised by the US Federal Reserve.

For LUNA, as with LTCM, a group of the smartest people in the room had banded together based on the unstoppable winning formula of:

(new technology + maths + programmers + marketing + chutzpah) = profit

Then claimed they'd solved a previously hard and intractable problem, and that everyone who doesn't believe them can just STFU, or in the case of Do Kwon (the founder of LUNA), "enjoy being poor". Oh the karma.

The risk with crytocurrency in particular is that if there's a bug in the algorithm or protocol, the result can be both an immediate financial loss, and a catastrophic loss of confidence in the currency. The bug can go unnoticed for months or years, before someone finds it and then patiently sets things up to exploit it for maximum profit.

Nootropics are a popular new type of dietary supplement that claim to enhance brain function in a number of ways including better memory, sharper thinking, alertness, improved verbal ability, more clarity and the elimination of 'brain fog'.

Follow @dodgy_coder on Twitter

Electric kickscooters are really popular right now. Their sweet spot in terms of usefulness is probably for people living in urban and inner city areas, or in areas which have good bicycle paths. I live in an inner city suburb of Perth, Western Australia, and work near the Swan river - my reason for buying one was to have some fun while commuting to work. My commute on the scooter is about 14km (9 miles) and takes me 40 minutes.

Four weeks ago I bought the InMotion S1 scooter for AUD$1299 (~ USD$970). In my review here I compare the manufacturers promotional material and claimed specifications to my real life experience of the scooter.

Scooter model history
The S1 is InMotion's latest model scooter, launching in Australia in September 2021. It has been adapted from the InMotion L9 model, which was crowdfunded on IndieGogo successfully back in May 2020. The S1 seems to be targeted at markets outside of the US, such as Canada, Australia and Singapore. The L9 and S1 look very similar, they share the same controls and share the same smartphone application.

Smartphone app
First thing to do is to pair the smartphone app with the scooter. This was easy and I didn't run up against any problems. I used the iPhone app, and there's an Android app available too. There was only one tricky thing I found with the app - changing the distance units from the default (miles) to kilometres. To do this, you need to first change it under the vehicle settings - this will ensure the speedo on the scooter reads out in km/hr instead of miles/hr. But in the app itself, it still displays the battery's remaining range in miles. To get this into km too you need to press on the "ME" link at the bottom, then settings, then "metric/imperial" units.

Speed limiter
The speed of the S1 is by default limited to 25 km/h (15 miles/h), but its easy to go into the app and turn this limit off (under vehicle settings). Doing this lets your scooter achieve the max speed of 30 km/h (18 miles/h). Unlike other scooters, this is purely a software setting and doesn't require any wires to be disconnected or anything to remove the speed limiter.

Braking
The S1 has an automatic electric brake on the back wheel, which kicks in automatically if you are going downhill and picking up speed rapidly, or have exceeded 30 km/h. The maximum speed I've achieved on the scooter is around 30.9 km/h while going downhill. The automatic brake is kind of jerky and not really smooth - it feels weird the first time you experience it. There's a toggle setting in the app related to the automatic brake, so I tried turning it both on and off but couldn't feel any difference. There is only one manual brake lever - for your left hand - this is hooked up to the front wheel drum brake. Drum brakes are actually preferable to disk brakes on a scooter because it means no parts are exposed, and so there are less mechanical parts to maintain.

Control panel & display
One of the best things about this scooter is the easy to use control panel and the large display in the middle of the handlebars. There's only one button, and it can perform the functions of power on/off, headlights on/off and to toggle through the three riding modes (Eco, Drive, Sport). Long press is power on/off. Single click is headlights on/off and double click is to toggle the riding mode. Compared to other scooters (like the VSETT range), these controls are intuitive and easy to remember. The throttle is thumb based - you push downward with the thumb of your right hand. Compared to the VSETT scooter throttle which uses your forefinger in a trigger action, I find it to be more natural and better suited to long commutes.

Bling LED lighting and auto turn signals
The scooter has a strip of roadfacing LED lights down each side of the deck, these stay blue while riding and automatically flash red when you are turning to the left or right. This is a great idea, because when riding a scooter its not recommended to take one hand off the handlebars to indicate your turn manually (as per a bicycle) due to instability. The only downside to the auto turn lights is that they don't activate until you either tilt the scooter or turn the handlebars in the direction you are going, so in other words anyone behind you only sees the indication when you are actually turning. Other lights on the scooter are the dual headlights and rear light / brake light. The headlights are positioned at handlebar height, making them extremely visible at night to oncoming traffic. With the LED lights, the scooter really turns heads at nighttime.

Riding modes - Eco, Drive, Sport
The Eco mode is a beginner mode - you won't go faster than 12 km/h (7.5 miles/h) and the acceleration is really soft. The Drive mode is supposed to be a standard commute mode, which limits your top speed to about 20 km/h (12.5 miles/h) and also limits the acceleration responsiveness to about 80% of maximum. Sport mode means no limits, on a full charge you'll get up to the top speed of 30km/h (18 miles/h) with the fastest possible acceleration. I keep it on Sport mode all the time - once you get used to the speed and the handling of the scooter I think most riders will do the same. These modes of course will impact on the range you'll get out of your battery charge, Eco will use the least amount of battery and Sport will use the most.

Range
In the promotional material the claimed range on a full charge is 95 km (59 miles). But in the manual it lets you know that this was achieved on level ground, in Eco riding mode, with a 65 kg weight rider and zero wind. So in other words, nowhere near real world conditions. In real world riding - in Sport mode the entire time, hills, wind, myself being 80kg, I found that the range ended up being 55-60 km (34-37 miles). But this is still a really good range - it easily handles my 28km round trip daily commute, and leaves some spare for other short journeys nearby to work or home.

Score card

Good points
+ Large display, intuitive controls, comfortable throttle
+ The app tells you the estimated distance left on the battery charge
+ Cool underdeck LED lights, auto-turn signals, dual headlights
+ Large non-slip silicon deck
+ Big real world range
+ Front and back suspension

Bad points
- Its too big to take onto public transport like a bus or train
- Height of the handlebars is not adjustable and is high compared to other scooters
- A couple of poor quality fixtures like the bell and the charging port dust covers
- Jerky automatic electric brake kicks in when going downhill

Conclusion
A great long range commuter scooter with decent performance, cool LED lighting, a solid feel, easy to use controls and a large display. If you don't need to take it on public transport, then this scooter will be perfect for your medium to long distance commute, given its large 55km (34 miles) real world range.

Where to buy?
As of writing, this model scooter is sold out around most of Australia. Due to high demand and shipping delays I recommend contacting the shop where you intend to buy first to confirm when stock will arrive before paying anything upfront for a scooter.

Follow @dodgy_coder on Twitter

The Mono project was founded in 2001 as a free open source implementation of Microsoft's .NET framework on Linux. But Mono had struggled since its inception to find its reason for being. According to Mono's founder, Miguel De Icaza, the hardcore free open source community never fully got behind Mono. The FOSS community feared that Microsoft would eventually cause problems for Mono, due to Microsoft being the creator of .NET. 

Outside of the Linux world however were other more pragmatic people from the MacOSX world who had no problem with Mono. One of these people was Joachim Ante, from Unity. Around 2005 the Unity game engine was just starting out and had a performance problem - their original scripting language of Python was far too slow - they needed something that was an order of magnitude faster. So Unity decided to replace the Python scripting with Mono/C# and immediately got all the performance they needed. This was the early days when the Unity Game Engine ran on MacOSX only. Mono filled the need of being a free open source JIT compiler with the modern language of C#.

Fast forward to 2008 when the iPhone App Store launched; Unity quickly set their sights on being able to compile games for the iPhone. Unity wanted to use Mono, but the additional requirement was that it had to be statically compiled for iOS, because Apple had banned the use of JIT (Just In Time) compilers in iOS Apps.

Unity comes back to us and says “Hey, we have this product on iOS, we need .NET to be statically compiled. Can you do that?” We were like, “Oh, that’s kind of impossible. Well, let’s think about it.”

One of our guys, Zoltán Varga - they went and made a static compiler for .NET, and it was amazing. We gave it to Unity. At this point, Unity is probably four or five employees.
    
They were working at somebody’s garage. And they shipped their product for iOS, built games for iOS using this thing, this 3D tech. They were the kings of this space.
    
- Miguel De Icaza (Xamarin)

Within a year of the iPhone App Store launch, Unity went from 4-5 employees to 80 employees. The iPhone and the App Store had launched Unity's massive growth, and along with this the Mono project had finally found its reason for being - mobile apps. The Mono developers realised there was interest in using .NET for mobile apps - so using the same tech given to Unity, they built their own product - MonoTouch, which allowed developers build native iOS apps using C#. Soon afterward, Mono turned its attention to Android and created Mono for Android.

Mobile app development was new and there were many developers who wanted to get into mobile apps but didn't really want to have to learn Objective-C and Java. So Mono now had a C# based cross platform app development platform with truly native performance. This was the killer combination that ensured Mono would take off in popularity.

The developers behind Mono founded the Xamarin company in 2011, MonoTouch became Xamarin.iOS and Mono for Android became Xamarin.Android. Xamarin was acquired by Microsoft in February 2016 and became a subsidiary of Microsoft, fully focused on the development of Xamarin's open source projects.

Inspiration for this article:

The History of GNOME, Mono, and Xamarin
https://changelog.com/podcast/275

• Many payment options - I chose the Shopify Payments option. It accepts Apple Pay and Google Pay when on a mobile browser for example. You can tell that Shopify have extensive experience with taking payments - everything is really polished.
• Test mode works well for putting through test credit card orders and seeing the customer experience end to end. Can also password protect the site while its under development.
• The free themes are good and can be customised for most online shops. I used the free "Minimal" theme and then customised the layout of the home page, added several pages and added a blog.
• Great optimisations and layouts which work well on mobile. More than 60% of the traffic for the site comes from a smartphone browser as opposed to a traditional desktop browser.
• Really useful "Timeline" admin feature on the customer and order admin pages - see all the interactions that have happened with a customer in a simple timeline display, with a timestamp shown on each interaction.
• Excellent "Conversion Summary" admin feature - see the site behaviour of your customer from when they first visited your site to when they bought something.
• Comprehensive "Fraud Analysis" admin feature - for orders paid by Credit Card - recommendation of whether the transaction is likely fraudulent or not: probability shown as low, medium, or high.
• Ability for customers to sign up with either their mobile phone number or email address. Shopify automatically sends communications to the customer using either mobile SMS or by email.
• Easy to add social media accounts, which then automatically appear on the site footer.
• Products are easy to configure and easy to change in terms of page title and content.
• Ability to edit raw HTML in most places.
• Easy to setup a custom domain, with TLS/SSL included (which just works).
• There are SEO optimisations and settings available at a page level. You can change the page title, meta description and URL.
• Integration with Google Analytics is excellent - the 'Advanced eCommerce' option should be turned on - it results in a data going straight into GA for your conversions and sales.
• Page load time is good - bulk of the home page loads typically in 2-3 seconds.
• A comprehensive API for writing custom integrations with other backend software and systems.

• Marketing integrations - Facebook Ads for example - difficult and error prone to setup. Facebook Ads never worked for me after many headaches trying to setup. The marketing integrations seem like a quick way to lose money fast.
• Inability to structure the Products, Pages and Blog sections to be within a custom sub-folders structure (as is typically recommended to silo a website for SEO purposes).
• Checkout page customization is limited to Shopify Plus users.
• Checkout script editor is limited to Shopify Plus, so any custom logic to apply discounts has to be done through plugins.
• API is rate limited - will be fine for most users however ERP systems which run via batch processing or via polling may have issues. You need to implement everything as event driven webhooks rather than by polling the Shopify API.
  

• I'm not convinced of the need for many of the Shopify apps (plug-ins) that get automatically suggested. I have a feeling that they will result in bigger page sizes and slower load times. I have not needed to use any apps yet.
• Its sometimes hard to find the relevant place for a setting - whether under preferences of the online shop or under settings of the account itself. I should probably make more use of the search bar at the top for this in the future.

• The active marketing of your app that happened at launch has now stopped
• Your app's last update was several months ago
• The uninstallation rate has started rising above your installation rate month on month

• Gain new users; many users look at the last release date on the app store page before downloading your app. Anything over a year old can be immediately rejected as out of date.
• Prevent uninstalls; seeing your app has been updated on their phone keeps it in the user's mindshare, so they know you are still actively developing it.
• Update the dependencies; you will likely have several dependencies on open source libraries and mobile SDKs. The more often you release, the more often these can be updated too.
• Update the toolchain; Xcode / Android Studio / Visual Studio get updated once every month or two. Same applies to hybrid and cross platform toolchains such as Unity, Ionic and Xamarin.
• Update the store listing; since you're doing a build, take the opportunity to review and tweak the store listing and screenshots. Apple's App Store Connect website and Android's Google Play Console get updated regularly with enhancements you can take advantage of.
• Less build issues; there will be a lower chance of a major build issue if you regularly update your toolchain and its dependencies. In my experience, the longer you wait between app builds and releases, the greater the chance of a major build issue the next time.
• Source control change visibility; the project is kept active in terms of source control history; especially relevant if its an open source project with other potential developers able to see the change history on github or bitbucket.
• Developer benefits; you don't end up with a legacy mobile app that noone can get building anymore.

• Have the dependencies or toolchain been updated? If yes, that means your app has gained some potential bug fixes and enhancements for free - just by doing a build.
• There's always some minor refactoring you can do to make small improvements to your codebase. Just spend a couple of hours if that's all you can spare.
• The release note; just use the standard "Bug fixes, performance and stability improvements" if you can't think of anything else.

• The more often the better.
• Aim for a regular release cycle of between 1-3 months.