Introduction — The Accidental Era of "AI First" Over the last two years, you've probably noticed a strange vibe in the software world: everyone is moving at impossible speed while simultaneously questioning if any of this will matter in five years. We've crossed into a world where individuals can do what once required teams. A world where "engineering" sometimes means "describe the system you want and let an agent scaffold 70% of it." A world where the differentiator is no longer what you can build, but how well you understand and present what you're building. This post is about that gap — not the gap between good engineers and bad engineers, but the widening gap between what AI can do and what humans still uniquely bring to the table. In 2025, the superpower isn't AI; it's AI plus a human who actually understands the problem...and understands humans. What Brains Do vs. What AI Does If you strip the biology away, a brain is three things: A prediction engine — constantly guessing what h

Building Devdle: Notes from the Neon Arcade Devdle is a Wordle-inspired daily puzzle app I built for developers to solve coding challenges. It was a super fun project to build, and brand obnoxiously over-the-top, so I figured it would also be fun to do a deep-dive on how I built it, how it operates and where it's hosted. Enjoy. TL;DR Edge-first stack (Cloudflare Worker + Pages) keeps the daily puzzle snappy worldwide. Puzzles are generated on demand with OpenAI, validated locally, and cached in KV/D1. React + Vite powers a CRT-styled UI; all answer checking happens client-side with a public salt. Google Analytics events (app_open, play_click, first_attempt, guess, etc.) make DAU and funnel tracking explicit. Durable Object rate limiting + cron jobs keep the API steady without babysitting servers. What I Wanted One fresh coding puzzle per UTC day. Zero login, zero friction, works on a phone. A restrained scope I can support while everything else is on fire. So Devdle is intentionally sm

Securing a Banking System's UI and API The below was a talk delivered at fintech_devcon in August 2025 in Denver, CO. I've adapted it into the blog post below... I've spent the last several years building fintech products from the ground up. Today, though, I want to talk about something that often gets bolted on far too late: security. Not security as a checklist. This is about building systems that are secure by design — from the UI all the way to the backend — and doing it in a way that doesn't suck the life out of your product or your team. And let's be honest: systems are rarely, if ever, 100% secure. Once you accept this sobering fact, you can free yourself to focus on threat prioritisation over straight coverage. What I'll share here is how we made security an invisible but powerful layer in our systems. Not just for compliance, but to genuinely protect users without compromising developer experience… too much. Who Am I and Why This Talk? I'm a consultant today, but previously I

AI Can Help You Write Code - But It Can't Help You Think The hardest part of software engineering has never been the syntax. It's never been whether you used map or forEach, GraphQL or REST, Tailwind or BEM. The real difficulty is developing the ability to reason about an entire system — understanding how data moves through it, how changes ripple across it, and how one decision in a helper function might trigger cascading pain three services away. That reasoning muscle is what separates a competent developer from a great one. And we used to build it the hard way: by writing code line by line by navigating the thorns of state by realizing, too late, that the thing you built two weeks ago just broke the thing you wrote two months ago You weren't just shipping features — you were developing mental models of how the system fit together. Here's the problem: AI is hampering that learning loop. AI can write you code. Good code. Sometimes great code. But it doesn't help you build the mental mo

There's a strange delay in engineering leadership no one warns you about. It's the time between when you fix something and when you experience the tangible benefits of your actions. Fix a bug? You're a hero before lunch. Rebuild the monitoring system to detect drifts in a payment system? It might be weeks, months before those efforts come into fruition. That's the Problem → Solution → Impact Gap Everything Good Takes Longer Than You'd Like When I joined a Letter (a US fintech startup) as founding engineer and CTO, I had a rare opportunity: greenfield architecture (hello!). No legacy baggage. No weird constraints. Just a blank canvas and a set of make-or-break goals - high availability, airtight data integrity, and compliance-grade auditability. I designed the platform around immutable event streams, strict type safety, and multi-region resilience. Every customer action—from transfers to tax calculations—became an event in a chain, keyed by ULID, stored immutably, and passed through a h

Or, "How I Learned to Stop Worrying and Love the Journey" There's a running joke in engineering circles that if you sit still long enough, someone will come along and replace your perfectly functional code with the latest framework named after a fruit, bird, or obscure Norse god. I've seen the same thing happen at companies and startups when old contractors or staff leave, and new ones join: "oh no, this all needs to go" - 98% of the time, the real issue is: "its not how I would've done it" (spoiler alert: it often won't be, but you weren't around for the original context, motivations, decisions, meetings, PRs, discussions, etc) In the past 15 years, I've gone from writing Backbone.js for a UK accounting software startup to architecting real-time financial infra as a CTO. Along the way, I've been a freelancer, a startup co-founder, a team lead, an idiot and a contractor parachuted in to untangle Things That Shouldn't Be Tangled™️. This post isn't a framework war cry or "X vs. Y in 2025

Introduction No matter the size of the company or the maturity of the codebase, there's one question I've found myself asking time and time again when tackling a new task: Is there an existing solution I need to augment, or do I need to solve this from scratch? At first glance, this might seem like a simple question—just check the README, right? But in reality, it's never that straightforward. This decision point isn't typically documented in an obvious way. It usually surfaces: Too late—during a PR review, when I've already built a solution. By accident—when a more tenured engineer sees my approach and tells me about an existing pattern I wasn't aware of. With luck—if the task creator had the foresight (and technical depth) to flag an existing approach in the ticket. For new developers onboarding into a codebase, this lack of visibility can be frustrating and inefficient. Without deep insight into past decisions, how can we extract and pollinate that knowledge across the team—without

How I Led a High-Performing Engineering Team Without Micromanaging A great engineering team doesn't need constant oversight. It needs clarity, trust, and the right tools to execute. As an engineering manager, my philosophy was simple: ✅ Push the product forward. ✅ Unblock my team. ✅ Get out of their way. The result? A team that shipped fast, maintained high-quality code, and took full ownership of their work. Here's how I did it. 🚀 Laying the Groundwork for Speed One of the most effective ways to empower an engineering team is by removing friction from their workflow. For larger features, I often designed the initial architecture—laying the foundation so engineers could focus on implementation rather than figuring out structure from scratch. I built internal tools to eliminate repetitive work, such as a GraphQL schema generator that automatically created schemas from YAML. This meant engineers only had to define data structures once, rather than in multiple locations. The goal? Enable...

Introduction After 15 years in software engineering and engineering leadership—ranging from IC (individual contributor) roles to CTO—I've seen countless engineers thrive (or struggle) based on how well their working style aligns with the company's needs at the time, from the Cisco's and GoDaddy's of the world, to your favourite seed-stage startup, I've seen different engineers suit very different working environments and company stages. Over the years, I've spotted a pattern: all engineers exist on a spectrum between speed and accuracy. This spectrum isn't about skill or seniority—it's about how engineers naturally approach their work. Some lean towards speed, optimizing for fast iteration and progress, while others prioritize accuracy, ensuring long-term maintainability and scalability. Neither end of the spectrum is "better" than the other, but knowing where you sit—and understanding what kind of engineer your company actually needs—can be the difference between thriving in a role or

TypeScript has become the de facto standard for building robust, maintainable, and scalable JavaScript applications. Yet, migrating a large production codebase to TypeScript can be a daunting task, especially when you're dealing with 160,000 lines of mission-critical JavaScript and users with real money in your system, and their tax returns to submit. At WorkMade, I decided the pain would be worth the plunge (after founder buy-in!) and benefit us in the long-run, so we took on the challenge and migrated our entire codebase to TypeScript over six weeks – without any downtime. Here's how we did it, the challenges we faced, and the tools that made it possible. Shoutout to Anya Hargil and JD for joining me on this wild journey, and humouring me with my initial motivation and plan to carry this out... The Challenge: Migrating at Scale Without Disruption When working on a large-scale production application, the last thing you want is downtime. Our application was powering crucial financial a

The Illusion of Realtime in Computing In software development, we often talk about "realtime" as if it's a definitive concept—messages sent instantly, updates reflected immediately, data synchronized across systems without delay. But what does "realtime" actually mean? And does it truly exist? From event ordering to WebSockets, let's break down what makes realtime computing possible, the illusion behind it, and why time itself is a tricky thing to grasp. No Two Events Happen at the Same Time At the fundamental level of physics, no two events can ever truly occur at the same moment. Everything exists within a sequence, even if that sequence is measured in nanoseconds. When we say two things happened “at the same time,” what we really mean is that they occurred so closely together that the difference is imperceptible to us. But if we zoom in far enough, even the fastest events are still sequential. Computers, which rely on clock cycles, registers, and atomic operations, inherently proces

A structured approach to writing reliable software by progressing and ascending through three distinct levels of quality assurance. A software development quote I love is "Make It Work Make It Right Make It Fast" - to build on this pillar, I want to delve into my own personal mantra I employ when I've come up with a solution to a software problem. I ask myself: "Does it work, how you want it to, most of the time?" Writing quality software isn't magic—it often follows a clear, linear progression. If you've ever felt overwhelmed by testing, debugging, or making your code production-ready, it helps to create a mental model and break the problem down into three fundamental questions: Does it work? (Basic syntax and compilation) Does it work how you want it to? (Integration tests and expected behavior) Does it work most of the time? (Production reliability, resilience, and fault tolerance) Each stage represents a necessary milestone in writing reliable software. Let's walk through them one

Securing a Bank UI How I Didn't Lose Any Customer's Money And Retained My Sanity Throughout Before I joined Clerk, I was a fintech CTO for nearly 6 years, with 4 years at Letter and 2 years with WorkMade. Aside from the truck load of valuable lessons those experiences taught me, I also had the fun* challenge of securing people's money on a daily (hourly? MINUTELY??) basis. I pretty much poured my 15 years of overall experience into the following post: Chaos Engineering: Jurassic Park & Distributed Systems, which spun into the following talk: Letting go of perfectionism in distributed systems, given in Austin, Texas at fintech_devcon in 2024. However, I wanted to do a deep-dive on some of the more interesting ways I implemented security in a banking system, from the UI (React) through to the API (GraphQL) and beyond. *induced crippling anxiety Diving Deep in 3...2...1 Securing a user interface (UI) for a banking platform is a multifaceted challenge that demands careful attention to data

10 Ways I Approach Engineering Leadership That Doesn't Leave Me Hating Myself Leadership in engineering isn't just about writing code or managing timelines—it's about creating an environment where teams thrive, products succeed, and everyone grows along the way. Over my career, I've had the privilege of working with incredible teams and companies, and I've learned some key lessons on what makes leadership effective (and doesn't make people sad). Here's my take: Balance Speed with Stability Building quickly doesn't mean compromising reliability. At WorkMade, I focused on monitoring and deployment while still delivering new features fast. "Ben has a keen mind for evaluating and making responsible eng tradeoffs to balance speed with stability and reliability which is invaluable in a startup environment." - Anya Hargil Know Where to Cut Corners (and Where Not To) Chase Croft put it best: “Ben intuitively knows where to cut corners for speed and where shortcuts would come back to haunt us.”

"Alright, five years ago, right before Thanos, I was in a place called the Quantum Realm. The Quantum Realm is like its own microscopic universe" - Scott Lang, Avengers: Endgame Every line of code we write is an act of creation—a way of collapsing the infinite potential of an idea into something real. Yet, we rarely stop to consider: what if our UI components themselves could exist in a state of quantum potential? What if the principles of the quantum realm—superposition, entanglement, and collapse—could inspire how we design and build interfaces? This is not a post about buzzwords (although, granted, it's rife with them). It's about rethinking the way we approach interface development. By applying quantum mechanics as a lens for UI design, we can unlock new ways to think about state, interaction, and composition. And perhaps—just perhaps—we can glimpse the future of what user interfaces might become. Superposition: Designing for Potential, Not Certainty In the quantum world, superposi

"We do not ‘come into’ this world; we come out of it, as leaves from a tree." – Alan Watts The world is built on systems. Some are physical, like the weather or a Kubernetes cluster. Others are abstract, like the algorithms behind a recommendation engine or the thoughts racing through your mind during a late-night coding/anxiety* session. Systems surround us, often unnoticed, until they break. Then, they demand our attention. *same thing in my eyes But systems don’t work the way we expect—they work the way they do. Learning to understand them means stepping back, observing, and letting go of the urge to impose our pre-existing, oft faulty, frameworks on their behavior. Whether it’s a distributed system, a social dynamic, or our own thought patterns, systems reveal their truths to those who pay attention. Observing without interference or judgement is the first step. Watching Systems: The Art of Non-Interference Alan Watts once talked about letting the system show you how it works. This

Predicting Unpredictable Bugs & Testing Distributed Systems Or, "No-One Expected Dennis Nedry But Maybe Could Have Better Prepared For His Actions" Dr. Ian Malcolm For most people, Jurassic Park was the first time they'd been exposed to the term "Chaos Theory": Malcolm: "You see? The tyrannosaur doesn’t obey set patterns or park schedules. The essence of Chaos."Ellie: "I’m still not clear on Chaos."Malcolm: "It simply deals with unpredictability in complex systems. The shorthand is the Butterfly Effect. A butterfly can flap its wings in Peking and in Central Park you get rain instead of sunshine." – Jurassic Park (1993) Chaos theory states that small changes in complex systems can have big, unpredictable effects. Although not a small change, Dennis Nedry's actions were unforeseen, they brought about dire consequences. Chaos theory says that when you deal with very complicated situations, unexpected things are going to happen. When you build software, even the simplest of applications b

How I manage time off and schedule in new work AKA "Asynchronous Pipeline Building", but more on that below... Read this bit first I've made this post with contractors in mind for two reasons: 1 - I've been one for 7 years now, so I feel a little more confident talking about it 2 - My definition of contracting is basically "staff augmentation for one company at a time", where you're just paid differently (via invoices and such) and don't get company benefits, so its easier to talk about time off around one client at a time (vs freelancers who might be working with various clients at once) A lot of this post will be applicable to freelancers and consultants, but I've based most of it on my, and other contractors I've known, experience. Intra-contract time off As a contractor, depending on the exact terms you sign, you actually get quite a bit of flexibility on how and when you work. To simplify things dramatically, a usual relationship between client and contractor is: client: hello con

Thanks to Pete Lacey’s tweet, I decided to turn the inability I was facing to come up with some useful concepts to blog about, into writing a post on the inability most people seem to face on starting something. Pete gave me lemons, I'm going to see how I do making lemonade. The Issues I believe the issue most face with starting something, anything, a blog post, a software project, a book, a painting, can be reduced (for simplicity) to two main causes: won’t start or can’t start. Lets start with the “won’t” camp. Perfectionism My belief is that the “won’t” people are afraid of what they produce not being good enough, either objectively based on peer review, or subjectively based off their own high standard. Ira Glass articulated this “Gap” between our taste vs. our ability beautifully in video form and in transcript form. This hits us all, even Paul McCartney. Just...stuck Sometimes, the issue isn’t “this won’t be good enough”, its more, “how do I possibly begin??”. This could be due t

Intro This post should serve as general observations and remarks on my own personal experience using both Vue and React for production applications and services, as opposed to simply drawing you in to a VUE VS. REACT clickbait fest. Background of my use-cases I began using React at the beginning of 2015. My first big use of it was on a project for Cisco, building a real-time test automation platform with websockets. Since then, I've used it on countless personal projects; Ekko and Top Spot to name a couple. My experience with Vue began a little later, this time in April 2017, on a client project for Soho House; specifically The Ned. Since then, I've built Readme App with Vue. What follows is an informal, loose account of the differences, strengths and highlights between the two libraries. Obligatory disclaimer: this really was my own experiences. There's inevitably multiple solutions to a problem, so my comparisons are based on my own approaches. Stateless functional components One of

I recently re-designed my personal site after not touching it since December 2015. When I sat down to re-design it, I felt like Jekyll's workflow and development experience suddenly felt...outdated. Mostly because a lot of the development I tend to do is JavaScript-based and (all fragility jokes aside), JS development in 2017 is pretty slick. This post is essentially going to be a collection of resources and links, because I've not created anything new, I just found a few things along the way to make Jekyll-based development a bit slicker. Git branches If you want to embark on this journey, you're going to want to use Jekyll plugins, and some of them are likely to be custom ones you've installed. Great! However If you're like me, and like a lot of other people, you're going to be pushing your Jekyll site to GitHub for free hosting, using GitHub Pages. However, I hope you're not like me in forgetting that GitHub won't run custom plugins on the Jeyll sites they host on GitHub Pages. I re

Creating a real-time test automation platform for Cisco with React & WebSockets…and React Native Amongst other things, highlights include: Building a command line interface in the browser for test engineers to remotely debug scripts they’re running Fine-tuning the performance of the UI to handle hundreds of messages a second over the WebSocket connection, whilst keeping the interface responsive Porting a section of the web application to an iOS app using React Native Purpose of the application I was brought onto the project in May 2015 to build a web application from a set of pre-existing wireframes. I was given complete freedom to pick a tech stack/libraries to use on the front-end as long as: I could justify their use and my choice in them My choices in them contributed to what the application needed to do I was going to be building a client-side application that would connect over a single WebSocket connection to a Python backend. The application (including the Python backend) would

Speculo Speculo is an easy way to visualise colour palettes. Every time you change a palette colour, it updates a set of commonly used website layouts. This allows you to visualise your colour palette in a variety of design scenarios. Visit Speculo → Features Automatically updating preset layouts Click any layout to zoom in and focus on only that layout Colours can be selected via the colour picker, or you can simply enter a hex value Export your palette in a variety of mediums at any time, with one click Thinking behind Speculo I tend to lean more over to the developer end of the spectrum and attempt to do my own designs at any given opportunity (mostly on side projects). However, I feel like this leads me to feel more comfortable designing in the browser, as this gives me a sense of a more realistic environment (ie. it's going to be viewed in a browser, so lets design it in one). However CSS isn't the most visual tool, so I wanted to create something that would use real HTML and CSS,

I really didn't want to bum people out with this post, so that's why I've named it after a Take That song, as opposed to a Smiths song (was going with "Heaven Knows I'm Miserable Now...with Web Development"). Blame my recent viewing for the teen angst tone of this post. Essentially; everything is the same, nothing is new, stop worrying about stuff. This post isn't a cry for help, I'm actually hoping it acts as some reassurance to new developers, old developers, developers with Imposter Syndrome™, basically anyone who's ever felt left behind or out of touch with modern development. (I'll keep it to web development specifically, for brevity sake) Overload Everyone is probably aware of the flurry of new stuff and the fragmentation of old stuff that seems to be happening lately. Open up Hacker News and see 20 different React.js architecture patterns, open up Designer News and see "101 Different Flat UI Kits You Should Be Using", or ask around on Twitter for responsive image strategies (and

Aim Provide a sane way for a user to search our static Jekyll blog and view a bookmarkable page containing the relevant results. For the eager-beavers among you, take a look at the Installation details at the bottom of the post. Intro "Transform your plain text into static websites and blogs." Simply put, that is Jekyll. This post isn't an intro to Jekyll or even a sales pitch for Jekyll. The Jekyll site does a good enough job of that by itself. This post will, hopefully, provide a needed solution for people (power users?) trying to get more out of Jekyll. Well, more than it was intended for... Static with a side of dynamic please Gone are the days when a monolithic heap of PHP was needed to run a simple blog or website. Jekyll came along with a monolithic amount of Ruby but left it on your machine, and not clogging up your webserver. Templating logic, Markdown and HTML go in...a static site comes out. That static site (by "static site", we simply mean HTML, CSS & JavaScript) gets dump

Permeate iOS app → Intro I've been a web developer for 4 and a bit years now, primarily using JavaScript & Node.js to build web apps. This was my first foray into the native world. I thought I'd share my experiences of approaching iOS from a web background. I certainly wouldn't class this as a tutorial of sorts, as my knowledge is going to be minimal after just one app, but if you do learn something as a result of reading this; then that's swell. I've been in the web world for a little while now, so I know the people to talk to, the sites to visit and the blogs to read. However, I feel like I'm starting all over again with iOS, so if any iOS people do read this, your wisdom and advice would be greatly received. Resources I always see posts where the resources are at the end of the post, but I thought I'd save you the trouble of listening to me waffle on and just put them first. So, without further adieu (some are quite specific to Permeate's functionality, some are more generic iOS one

iHi.im → Preamble Jack Smith and myself made a web app a couple of years ago called iHi. It ran on a PHP/MySQL backend and some Google Maps driven JavaScript on the client. The user would hit the site, the PHP would allocate them a unique URL (stored in the database) and they could share the URL with friends, essentially sharing their location. The hosting expired on that site, so I pulled it offline and only just sat down last week to rewrite it with no database or backend to speak of. I hope to show you a couple of tactics for writing backend-less apps below. Here goes. Templating The app itself is only 3 "views". A start view, a share view and a viewing view. Templating is a really fast, usable way to bring HTML rendering and control into your application. No more building up HTML strings directly in the JavaScript, but maintaining a separation of concerns so we can work on our HTML separately from our JavaScript logic/app code. Stateful URLs JavaScript apps which just replace conte

Making elements the same height Sometimes you might have a need to grab a few elements, and then make them the same height. In an ideal world, you'd use CSS, but this isn't an ideal world, so we must use JavaScript! So drop this code in and you can achieve equal heights, really easily: <script type="text/javascript"> function sameHeights(selector) { var selector = selector || '[data-key="sameHeights"]', query = document.querySelectorAll(selector), elements = query.length, max = 0; if (elements) { while (elements--) { var element = query[elements]; if (element.clientHeight > max) { max = element.clientHeight; } } elements = query.length; while (elements--) { var element = query[elements]; element.style.height = max + 'px'; } } } </script> Stick this code anywhere on the page (or in a JavaScript file) to include it. To actually run it you can use the following markup: <div class="sameHeights"> <div data-key="sameHeights"></div> <div data-key="sameHeights"></div> <div data-key="sameHeight

A constant barrage of "new things" When I started back in 2009, I remember having a handful of bookmarks that I used to scour for all the information I could lay my hands on... Sites like Nettuts and Line25 were big enough buckets of information on development and design, if felt like those were all a beginner really needed. Then I joined Twitter and started following Smashing Mag, HackerNew Popular and CSS-Tricks and many more, each account/site/service being amazing at what they did, but their purpose was to share information and thus help people. However, like many developers and designers, I'm a little like a magpie in the way that I consume information; if it's new and shiny, I feel compelled to check it out. And boy, does the information come in droves. If I were to check the last 200 tweets in my Twitter timeline, I imagine I'd find 5 JavaScript libraries I'm not using or 3 CSS naming conventions I haven't adopted. Jeez. Selective learning I've never been one for learning things

Everyone and their mother is now telling you to "stick your site on GitHub", but if you don't know what a GitHub is or the idea of forking, pushing and committing freaks the hell out of you, then I hope this short guide will at least help you overcome those barriers and come to realise that it's a dream workflow to have your site hosted on GitHub and all the benefits that come packaged with it. Why the sudden increase in popularity? Well, as GitHub's own popularity has grown and is finding itself more deeply engrained into developer's workflows, more and more projects are going up on GitHub and therefore more project/demo pages are being hosted on GitHub. Naturally, as more of your stuff is on GitHub and your workflow is more finely tuned, the next step is hosting your blog or portfolio on GitHub using the same workflow. Benefits: It's free A lot of people use it, so there's lots of help You can optionally use Markdown, which is ace You can edit and re-upload your files directly on the

Controlling navigation in a large client-side application As more and more applications are moving to the browser, we're now finding ourselves having to fix some of the already solved paradigms, ie. navigation. Sending the user to a different URL is no problem, whether you're using hash based navigation or HTML5 PushState, this is probably going to be handled by your MV* framework of choice. However… The real fun happens when you want to start doing stuff like "in-app back buttons". We began this venture by simply using window.history.back() as a blanket solution. How naive we were. For the most part, it works. But like all blanket solutions, you'll unstuck at some point because with large apps, you end up with a lot of custom requirements. We found that our main issue with a blanket window.history.back() solution was that we often didn't always want the user to be navigated back historically, but rather hierarchically. So going from "items/123" back to "items", is a hierarchical manoe

They're also decisions and choices in disguise A while ago, I saw this Dribbble shot from Morgan Allan Knutson and I have to say, other than thinking the design of the poster was visually pleasing, the message on the poster didn't really mean that much to me. But… Recently, I've been working on the rewrite of KashFlow's software alongside a dedicated UI/UX guy and noticing how much thought goes into the tiny details which can swing the mood of a user to polar opposites of the spectrum; a big no no. What I've noticed, more in life than in UIs, having gone through these UX processes, is that people genuinely hate or get flustered being presented with options...or decisions in disguise. I was sat in a restaurant the other evening (ok, it was a chip shop, but hey, who's keeping count?) and was half listening to a man order his meal: Him: "fish and chips, please", Her: "large chips or small chips?", Him: "ummm, large", Her: "large fish or small fish?", Him: "oh, er, ummm, small please." The

Kill your output with premature optimisation "Design Patterns", "Code architecture", "Scalability", "OOP", "Maintainability", "The code you write now, is the legacy code of the future", "Be kind to your future self" & "Code smells". Just like Bruce Almighty trying to block out the voices in his head, my pangs of guilt and angst come from the paradigms above; like an unwavering, continuous stream of distraction overwhelming my thinking as I'm trying to write one single line of code. One single line of code. That's it. Nothing special. No one's going to live or die if it's not the most optimised, architected and scalable line in the world. We are under a constant barrage of posts, tutorials and articles about these paradigms. I often feel guilty if these paradigms aren't at the forefront of my mind whilst developing. It often kills my output. I'm trying to adopt a new workflow where I won't try and solve a problem until it becomes a problem; until I see it in the 'wild'. Just like Adii P

Tim Berners-Lee on the Principle of Least Power: "Computer Science spent the last forty years making languages which were as powerful as possible. Nowadays we have to appreciate the reasons for picking not the most powerful solution but the least powerful. The less powerful the language, the more you can do with the data stored in that language. If you write it in a simple declarative from, anyone can write a program to analyze it. If, for example, a web page with weather data has RDF describing that data, a user can retrieve it as a table, perhaps average it, plot it, deduce things from it in combination with other information. At the other end of the scale is the weather information portrayed by the cunning Java applet. While this might allow a very cool user interface, it cannot be analyzed at all. The search engine finding the page will have no idea of what the data is or what it is about. The only way to find out what a Java applet means is to set it running in front of a person."

This post is a re-publish from an article I did for .Net Magazine back in September, 2012. Since they've gone and deleted it from their site after redirecting everything to CreativeBloq, I thought it'd be a shame to see it trashed. The internet’s mark is forever; a saying that has plagued the minds of copywriters and web designers for the duration of the modern web. A flippant scrawl on a notepad or piece of paper is disposable, the internet’s ink is permanent. This isn’t a bad thing though. This unequivocal notion forces and encourages us to be more thoughtful and precise about how we portray our services and messages across the web. We create websites for people, because websites are read by people: people don’t like to be treated like Google bots or spiders crawling content. A bot can’t understand a subtle joke or catch a movie reference, a person does. This is important as you get the opportunity to think about who you want your intended audience to be. Human touch Recently, I crea

"Side projects, yo!", "Are you going to Open Source it?", "Is it on GitHub yet?", "Please don't make another one; contribute to an existing OS project", "Have a full time job and you create Open Source projects? Congratulations, now you have two full time jobs." Everyone talks about the amazing sides to being involved with Open Source; as we all know, there are many. You can be a complete beginner on the web, have no client experience to speak of any yet, you could contribute to the Bootstrap project on GitHub and affect a ton of sites out there. High impact, high exposure. Another MV* framework...really? James Padolsey put this way better than I'm going to attempt to, in his post, "There is no directive". A tl;dr if you don't want to read the whole thing is roughly: "We’re all running around solving problems that we care about and discovering new things to improve our understanding of the world, and that’s wonderful. We’re not automatons working in unison towards an absolute." The int

Backbone is awesome. It allows you to write large scale apps but still keep control of the code you're writing (read: it doesn't do all that much for you). However, a lot of people struggle (people, being me, for ages) to level up from the 'Todo' App in the early stages. Hopefully this post and the related GitHub repo will assist you nicely. We're going to be using Dan Harper's sweet ViewManager for our post's code. It's nowhere as sophisticated as something like Marionette.js, however it does give you a really nice method of controlling/destroying the Views within your application. The one thing that confused me when starting out with Backbone.js, was actually creating a real world application, ie. an app with lots of different states, lots of different "areas" or "regions" - sidebar, header, content, etc... ViewManager So I thought, lets use Dan Harper's ViewManager to create a small application. The nice thing about Backbone.js, is that we can create a whole app with just Views (DOM

This post isn't going to go too much in depth about what Jekyll is, but more how to get going with it insanely quickly, however; Jekyll is a static-site generator. You give it Markdown, Liquid, HTML & CSS and it gives you a deployment ready site to upload to your server. Go read more on the site. Fire up your command line Now type these commands: gem install jekyll jekyll new my-awesome-site cd my-awesome-site jekyll serve --watch # => Now browse to http://localhost:4000 What did we just do? Well, we installed Jekyll as a Ruby Gem (I should point out, that I have zero Ruby knowledge, so hopefully that gives you comfort...or you've stopped reading). We then created a new Jekyll site, put ourself into the newly created folder and then tell Jekyll to start up a lightweight webserver. We can then access the site on the URL above. We add on the --watch flag to tell Jekyll to re-generate the site on save of any of our source files. Super rad lovely workflow. Folder structure Jekyll creates y

Backbone is frickin' awesome. What I feel makes it awesome is the fact that it helps you write and structure better JavaScript code and not better "framework-x" code. It's amazingly intelligent but not opinionated, which is what causes problems for a lot of people when getting to grips with it (myself included). The site itself and corresponding docs don't really go beyond the syntax and methods Backbone provide, not much in terms of architecture and structure. Head on over to Google and you'll find a plethora of Backbone tutorials, most go over theory and the syntax, a few go over building a small app (a Todo app - the new "Hello World"), but very very few actually delve into building multi-regioned, multi-stated, authentication backed Backbone applications. I've had the pleasure of building one of the latter described applications for the past few months at KashFlow and have picked up a few tips and patterns along the way which have made building this large scale application a heck o

Any guesses as to which will alert first? window.addEventListener("click", function(){alert(1)}, false); window.addEventListener("click", function(){alert(2)}, true); Answer: the second one. Explain that to me, yo! The third, now optional, parameter in addEventListener is "useCapture", which literally means fire the event at "capture" and not "bubble". When an event is attached to an element, it will fire once the event has fully bubbled up to the document. However, if you set the useCapture flag to true, the event will fire on capture, and not wait for the event to fully bubble up the DOM tree. tl;dr "Events can be activated at two occasions: At the beginning ("capture"), and at the end ("bubble")." from Unable to understand useCapture attribute in addEventListener Deeper understanding Javascript Events – Capturing And Bubbling

In the relatively brief time I've spent learning to design and develop, I've learnt a great amount but the most scary and humbling thing I've learnt is what I still have left to learn. It seems to be a rabbit hole of knowledge and understanding. Constantly feeling stupid whilst looking at what others are producing and achieving both drives and grounds me. The key thing that struck me very recently, and subsequently sparked me into putting these thoughts down, was that we constantly see results. Results of people's hard work, obsessive iterations and revisions. We see the popular page on Dribbble, 12 highly perfected designs, we see the Backbone source on GitHub. We see the end of a person's journey. The very gleaming, shiny version of their hard work, frustration and pain. Something that Jonathan Ive said has always stuck with me, from this video Objectified he says that (not a direct quote) the light on the side of the Macbook (to indicate that it's sleeping), which slowly "breathes"

The JavaScript below is perfectly legal, it grabs a DOM element that doesn't exist and then sets it's text. No errors at all. setTimeout(function () { document.getElementById('myEl').innerText = 'Hey there, yo!'; }, 0); var myDiv = document.createElement('div'); myDiv.id = 'myEl'; document.body.appendChild(myDiv); Great Odin's raven!? Imagine your code as building blocks, all stacked on top of each other, this is how the browser's engine executes your JavaScript - top to bottom. It processes one piece then the next, then the next, one at a time, essentially blocking the progress of execution until the current operation is complete. JavaScript is single-threaded, ie. it can't do more than one thing at a time, like a multi-threaded application can. What's actually happening above is that the setTimeout is added to the browsers event queue, right at the end. So it's not executed until all other operations in the current stack are carried out and complete. tl;dr setTimeout() buys you some

I must hear the word "API" about 20+ times a day. However, I've noticed a few people recently on Twitter and email me asking "where do I begin with APIs?" or "how do I get started with APIs?". Well I'm hoping after reading this today, you'll 1. Know what an API is and 2. Not to be so afraid to just get stuck in with them! I've tried to write this tutorial whilst trying to remember what concepts confused me when I first started with APIs. So if I've not explained something enough or left something out that you're struggling with, then let me know in the comments below or on Twitter - @benhowdle. AP-what? Without quoting Wikipedia or telling you what it stands for (because it's not really that helpful), I'm going to describe exactly what an API is and what it does in my own words: An API is an exposed set of methods for a developer to use, not needing to know the working guts of a system. People often associate APIs with things like Twitter or Facebook or Foursquare, services like that.

Today, I released Heisenberg.js, a project base for building modern JavaScript applications. Features From the site itself, here are the key features: Not a framework, but a base project to help you structure your JavaScript code and files. Makes use of the Mediator Pattern, so you can trigger events around your application. Templating built in - Handlebars is included but feel free to change engines. Follows the Object Literal Pattern with one global namespace, usually 'myApp' or 'chatApp'. In this case, it's 'breakingBad'. Included: jQuery, Underscore.js and Handlebars. A fully commented source to show you why it's doing what it's doing and how to build upon it's foundation. The JavaScript version of the HTML5 Boilerplate The thing that I hope makes this project succeed is that it's almost the same code you've been writing in jQuery or JavaScript. It's just that I'm hoping to provide a way for people to kick off their next project with a little more structure than maybe they've had b

I believe that passion is the underlying reason why people and products succeed. Have you ever used a product and you clearly know that there was no passion involved in the design, manufacturing or shipping of said product? Yep. That’ll be the the lack of passion. Misalignment of a button, displeasing typography, odd placement of parts, all of these things, at first glance, might be misconstrued as accidental. Nothing is an accident. When a person ships or builds a product, may it be digital or physical, the level of passion will directly affect their ability to check for these inaccuracies. People’s passion will run parallel with the nature in which they conduct their design or development, when they make the conscientious decision to put their name to a product, they send it out to the public in full knowing that it’s going to be critiqued and observed by all and sundry. Passion (or lack thereof) will shine through. The same principle’s will be prevalent when you look for work. Or in

"Mobile Last" - is this guy trolling?? Maybe. Maybe not. It's a slight tongue in cheek dig at our community; what usually happens: Industry Big Wig says 'Mobile First (or similar) is the new way we do things', then everyone thinks 'right, we must now do Mobile First', then we start telling clients we are now a 'Mobile First' agency or designer, clients then think they must go with someone who implements 'Mobile First'. I don't know about you, but I get very nervy when we start "unofficially" labelling approaches. "Mobile First", "Responsive Web Design", "Adaptive Web Design" and "Future Friendly". Haven't got a problem with these actual approaches, it's just the furore that surrounds the use of them. Conversations on Twitter usually go like "You're using LESS, I hate you", "Well, you're using Sass, you're a douche". Please. Who cares? The client? No. Your users? No. You and your team? Yep, these are the only people that is affects. With my latest site redesign and domain name change, I

Twitter Bootstrap takes some flack. Some horrible flack, which I'm certainly guilty of dishing out in the past. But this, after much thought and a recent plethora of negative activity and animosity in the web community, I realised that it's not Twitter Bootstrap that's the problem; it's developers and designers not willing to go that extra mile. 24 Ways recently published this article. I've never read a more half assed title - "How to Make Your Site Look Half-Decent in Half an Hour". Come on. "Half-decent". Is this what you want to output? To be known for? I can't understand why, if you have an ounce of pride, you'd not want everything you release to be the best you could do? Twitter Bootstrap was made by @mdo and @fat for internal use at Twitter and released it because they thought it'd be useful for rapid prototyping of web elements or UI components (correct me if I'm wrong). Twitter Bootstrap can be likened to the default drop shadow setting in Photoshop. It's not that people hate t

Smashing Magazine sent me a preview of their upcoming book The Mobile Book, which initially you might think, "Hmmm, that's a seemingly bold title". It is. It's saying, this is the standard, the reference book for Mobile. Well, it is. I worked for a mobile web publishing company for 18 months and the depth of knowledge provided by the experts in this book (and I mean experts) is extraordinary. It blew me away. It reminded me of the time I was learning jQuery and thought "I should really get to grips with JavaScript as well", it was the tip of the iceberg of what I had learnt and seeing what I had to learn scared the crap out of me. This book provides that much needed solid foundation for designing and building for Mobile, it fully equips you for the journey ahead. The book is honest, it even says it's an "artefact of it's time", which means it admits that one day, we'll look back and think, gosh can't believe we used to design/build for mobile as a separate entity. But this is ok. The i

Harnessing jQuery's cooler features in your application can really enhance the performance and, sometimes more importantly, the maintainability of your web application. The short snippet below utilises the Observer Pattern and the Object Literal Pattern. To read more about these and other Design Patterns, I can't recommend Addy Osmani's excellent "Learning JavaScript Design Patterns" enough. Firstly, the snippet. var app = {}; app.mediator = $({}); app.walt = { init: function() { app.mediator.on("yo", this.yo); }, yo: function(event, params) { console.log(params.name); } }; app.hank = { init: function() { var data = { name: "jesse pinkman" }; app.mediator.trigger("yo", data); } }; app.walt.init(); app.hank.init(); What the above does, is uses an intermediary Object to handle the Publishing (triggering) and the Subscribing (on) of messages and data within your application. You may sometimes see the Observer Pattern being referred to as "PubSub" - this is simply short for Publisher/Subsc

I saw an article posted on Netmag the other day for which I contributed a couple of coding tips. The tip I'm talking about in this post reads as follows: Ben also thinks that falling back on frameworks and libraries isn't always the best answer. "If you're coding a small project and always, for example, include jQuery, think 'Can I do this with Vanilla JS?'" You may find that, indeed, you can do it in JavaScript, better and faster. See, I wrote this tip back in July sometime (only now has it been published) so my thoughts have somewhat evolved since then. The line that struck me was the last one: "you can do it in JavaScript, better and faster" - the real truth is that, no, I can't. John Resig and his team at jQuery have put many, many man hours into optimising jQuery to the max, I don't think you'd find a line in the source that hasn't been put under a microscope and scrutinised, benchmarked and refactored. I think the problem with my quote, apart from it being an over-generalisation,

Earlier, I set up my own GitHub page. There is a helpful guide on the GitHub site itself. However, I thought I'd add a couple more points to it and explain my process a little. Your own GitHub page is just a plain ol' repo, nothing special, it's just the name of it that matters. Make sure you create a new repo following the format of [GITHUB_USERNAME].github.com, so for me, my repo was "https://github.com/benhowdle89/benhowdle89.github.com". Now you can place an index.html file in the root with CSS & JS files as normal in there and GitHub will automatically push that repo to the "benhowdle89.github.com" URL. With my GitHub page, I wanted to display all of my GitHub repos and a small bit of "me" information from GitHub. I also decided to use the excellent HandlebarsJS for the templating solution - makes sense as our GitHub repo markup was going to be repeated and exist as 'boilerplate' code in large. Please feel free to Fork the repo and use it for your own page. To use the JavaScript f

For good or bad, Ethan Marcotte coined the term Responsive Web Design a while ago and from that point, #RWD was plastered across tutorials, Twitter, conferences, I think some people even got "RWD4 LYFE" tattooed across their knuckles. People went crazy for it. The humble pixel was outcast as villainous, inflexible and just plain wrong. Ems and percentages were the new kings, proudly thrust forward into stylesheets everywhere for type, layout and grids. But I think, somewhere along the line, people got silly. Now, no one is going to take my opinions in this article seriously unless I provide examples of what I mean. By doing this, I'm going to have to link to certain sites that highlight my point. I really do hope that the owners and designers of these sites do not take offense to my words, it's not personal. My first issue: big sites. The thinking before RWD fever hit, was that mobile and narrow viewports were the afterthought in design and development. You would slap a 960px width on

A google around reveals lots of ways to structure your JavaScript code. My method is nothing special, nothing new and is probably covered hundreds of times across the web. But, it's always useful to see different methods, right? Maybe you hadn't seen this way yet... var myClass = function() { var privateVar = 'do not look at me from the outside'; return { publicVar: 'access me from anywhere', fname: '', init: function(fname) { this.fname = (fname !== undefined) ? fname : 'guest'; console.log('you've kicked this class off, ' + this.fname); }, getPrivateVar: function() { return privateVar; } }; }(); myClass.init(); // you've kicked this class off, guest myClass.init('ben'); // you've kicked this class off, ben console.log(myClass.publicVar); // access me from anywhere console.log(myClass.privateVar); // undefined console.log(myClass.getPrivateVar()); // do not look at me from the outside I'm always interested in people's methods of structuring their code, so stick a link to a Gist or a J

Remember in Austin Powers where he met his past self, how well did they get on, right? Well this is not really like that. What I mean by "hire yourself" is; you know all those times where you've gone, "Can't wait to see if a client asks me to use [X] technology in a project" or, "wow, I get to design this!". Probably won't happen, unless you're really lucky or unless this happens all the time and I've severely misjudged this post. As a developer, designer or any of those types, I'm guessing you chose to do it. Not many people find a sign in a shop window saying, "WEB DESIGNER WANTED - ENQUIRE WITHIN". It doesn't happen. So I'm also guessing that you have an eternally unsatisfied perception of your own skills and knowledge, insatiably reaching bigger and better goals? Just hire yourself. Do it. Start making your own timeline for learning. Do things and experiment with new libraries and code when you want to. Think of a side project? Do it. Release it. Think of the next million dollar id

Preface The below is a suggestion. Only that. It's my method and it may not suit everyone. As you were. Intro Playing on the "step out of your comfort zone" cliche, saying "yes to everything" involves a lot more risk. Risk of embarrassment and risk of not delivering something. Why Only doing what you do is dangerous. I'm not talking about if you're a designer, then just designing is dangerous, that's ridiculous. I'm talking about taking your strength, whatever it may be and pushing yourself to do an aspect of it that normally you might think you're too inexperienced for or unable to perform. The risk part of it involves saying yes to clients/potential clients. You can sit on development blogs or look at design tutorials for a long time and of course, you're going to learn a heck load, but when you're in a situation where you've quoted a number of days and a cost to perform a task, you get that unpleasant feeling of panic wash over you and a slight nauseating sensation of "I cannot do t

Preface Articles like this - http://michaelwright.me/critique make me sad because he is discouraged from giving critique, "This is why I, and others I know, are a lot more reluctant to provide critique. "I have followed Michael on various networks for a while now and once you see past his, sometimes, short manner (honest and blunt), you realise that the guy is trying to help you, not make you feel silly. I am the first to admit that when I was starting out, I didn't take criticism very well. As a web professional, your work is constantly on display. That means you have to be ok with receiving comments on it, the good and the bad. Others are better than you The "penny-drop" moment for me was realising that there are people that are actually better than you, of course I knew that there were better people out there than me, I'm looking at you Sir Jonny Ive. But, what I mean is, when taking critique it's very easy to jump on the defensive, immediately defending and throwing back comments o

I started out in 2009 creating websites. I started doing this in the evenings and weekends because I realised that that was what I wanted to do. It took a fair amount of motivation to come home from a full time job and to learn new skills. I think the web design industry demands motivation, it keeps everyone on their toes. If you stay static and refuse to look at new technologies/findings then you get left behind. This is unfortunate but true. So stay open and hungry! I hope newcomers (I've only been in the industry for 2-ish years so I suppose I am still a newcomer) to web design read this article and come away with a reinvigorated sense of optimism and passion. I got into the web because it's not just a 9 to 5 job. It's a lifestyle choice, it's the ultimate way to express yourself and create just about anything you want. Pictured above is from The Social Network, now this came out a while after I started developing but I actually found this incredibly inspiring. I'm not too much of a