It reminds me of the old jQuery philosophy: find something and do stuff to it.
Gall’s Fundamental Theorem of Systems is that new systems mean new problems. I think the same can safely be said of code—more code, more problems. Do it without a new system if you can
A cautionary tale of the risks involved with embracing new frameworks.
But when you introduce a new system, you introduce new variables, new failure points, and new problems.
…almost anything is easier to get into than out of.
I’m following Remy’s experiments with great interest—his approach sounds like the holy grail:
I’m trying to build a web app that uses progressive enhancement as a design principle with state as a core value to the coding approach.
Adult training represents a way into coding for millions of women who never learnt when they were younger. Meetups such as those run by organisations such as Women Who Code and Codebar can introduce women to the collaborative, problem-solving world of programming.
This looks like it could be a very nifty tool to have at your disposal while coding. I like that it’s editor-agnostic.
One of these days I’m going to step outside of my PHP comfort zone and actually build something in Node. One of these days. When I do, this book looks like a good place to start (and the online version is free).
I was just helping out with some debugging at work and it reminded me of this great talk/post by Remy:
- Replicate: see the bug
- Isolate: understand the bug
- Eliminate: fix the bug
More of this kind of thing, please!
It seems grossly unfair to refer to this as an article. It’s a short book. It’s a very good short book; lucid and entertaining in equal measure. A very enjoyable read.
It is, unfortunately, surrounded by some distracting “enhancements” but perhaps you can use your cleaner-upper software of choice to route around their damage: Instapaper, Pocket, Readability, whatever works for you.
I think there’s a lot of truth to this. By any objective measurement, PHP is clearly inferior to just about every other programming language out there …but its preinstalled out-of-the-box nature means it’s the path of least resistance.
This article first appeared in Fast Company almost twenty years ago. It’s a fascinating look into the culture and process that created and maintained the software for the space shuttle. It’s the opposite of Silicon Valley’s “move fast and break things.”
To be this good, the on-board shuttle group has to be very different — the antithesis of the up-all-night, pizza-and-roller-hockey software coders who have captured the public imagination. To be this good, the on-board shuttle group has to be very ordinary — indistinguishable from any focused, disciplined, and methodically managed creative enterprise.
A quick drag’n’drop way to base 64 encode your web fonts so you can stick ‘em in local storage.
I don’t agree with the conclusion of this post:
But I think the author definitely taps into a real issue:
The real problem is the perception that any code running in the browser is front-end code.
This is something we’re running into at Clearleft: we’ve never done backend programming (by choice), but it gets confusing if a client wants us to create something in Angular or Ember, “because that’s front end code, right?”
I’m not sure if I agree completely with every point, but this is a great shortlist of things you can do to make your code more resilient and understandable (thereby making you, by any sensible definition, a better programmer).
Tom is running a Node School at 68 Middle Street on the evening of March 27th. I plan to attend and finally wrap my head around all this Node stuff.
Executing console.log(“hello world”) or window.alert(2+5-20) brings immediate feedback, makes you feel as though you’re getting somewhere and that you are interacting directly with the computer as a programmer. For those of you old enough to own a Spectrum, C64 or Vic20 – BASIC (itself heavily derided) had the same benefit.
A well-written piece on the nature of work and value on the web, particularly in the start-up economy.