Joschi is documenting his commitment to “contribute at least one meaningful commit a day to a public Open Source project or a similar community effort.” So far it’s a really nice mix of coding and face-to-face activities.
Tuesday, January 31st, 2017
An excellent potted history from Cassie on women in computing.
NASA’s “Keypunch girls” would work in cramped rows translating programming instructions onto paper pads, whilst the machine operators would sit in comfort, feeding the code decks through card readers and enjoying the esteem of the end result (I imagine it a bit like Mad Men, but with more sexism and astronauts).
Wednesday, January 11th, 2017
Friday, November 25th, 2016
It reminds me of the old jQuery philosophy: find something and do stuff to it.
A superb 2012 essay by Olia Lialin. J.C.R. Licklider, Vannevar Bush, Ted Nelson, Douglas Engelbart, Don Norman, Lawrence Lessig, Jonathan Zittrain, Douglas Rushkoff and Cory Doctorow all make an appearance.
There’s a lot to think about here. I’m particular struck by the idea that calling people “users” isn’t necessarily the dehumanising Lakoffian language we think it is; users have power and control. If we stop treating people like users, we may end up infantilising and disempowering them.
But when you read it in a broader context, the denial of the word “user” in favor of “people” becomes dangerous. Being a User is the last reminder that there is, whether visible or not, a computer, a programmed system you use.
Monday, November 21st, 2016
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.
Sunday, October 23rd, 2016
A collection of assumptions programmers often make.
“Dates and Times” is tied with “Human Identity” for the most links.
This is a very thoughtful analysis of different approaches to writing maintainable CSS, which—let’s face it—is the hard bit.
I often joke that I don’t want to hire a code ninja. Ninjas come in the middle of the night and leave a bloody mess.
I want a code janitor. Someone who walks the hallways of code, cleaning up pieces, dusting up neglected parts, shinning up others, tossing unnecessary bits. I prefer this gentler, more accurate analogy. This is the person you want on your team. This is a person you want in your code reviews.
Also, can I just say how refreshing it is to read an article that doesn’t treat the cascade like a disease to be wiped out? This article even goes so far as to suggest that the cascade might actually be a feature—shock! horror!
The cascade can help, if you understand and organize it. This is the same as any sophisticated software design. You can look at what you’re building and make responsible decisions on your build and design. You decide what can be at a top-level and needs to be inherited by other, smaller, pieces.
There’s a lot of really good stuff in here to mull over.
My hope for this article is to encourage developers to think ahead. We’re all in this together, and the best we can do is learn from one another.
Tuesday, August 23rd, 2016
I’m in a similar position to Remy:
But, like Remy, I’m interested in knowing what are the ideas and techniques embedded within large frameworks that will end up making their way into the web stack:
What I want to know is: what should I be taking away from React into my own continued evolution as a web developer?
There are some good responses in the comments.
Wednesday, July 27th, 2016
Never let fear get in the way! Don’t be afraid to continue even when things appear to be impossible, even when the so-called “experts” say it is impossible. Don’t be afraid to stand alone, to be different, to be wrong, to make and admit mistakes, for only those who dare to fail greatly can ever achieve greatly.
Monday, July 25th, 2016
class keyword. This introduction has been accompanied by a fair amount of concern and criticism.
Now if you believe that outcomes matter more than understanding, then this is a perfectly acceptable trade-off. After all, we use computers every day without needing to understand the inner workings of every single piece of code under the hood.
The most common way that people refer to the new
My personal opinion is that this isn’t healthy.
(Full disclosure: Kyle also some very kind things about some of my blog posts at the end of that episode, but you can switch it off before it gets to that bit.)
Both Ashley and Kyle bring a much-needed perspective to the discussion of language design. That perspective is the perspective of a teacher.
In his essay on W3C’s design principles, Bert Bos lists learnability among the fundamental driving forces (closely tied to readability). Learnability and teachability are two sides of the same coin, and I find it valuable to examine any language decisions through that lens. With that mind, introducing a new feature into a language that comes with such low teachability value as to warrant a teacher actively telling a student not to learn how things really work …well, that just doesn’t seem right.
Friday, July 8th, 2016
Margaret Hamilton’s code after scanning and transcribing.
Tuesday, June 28th, 2016
People who excel at software design become convinced that they have a unique ability to understand any kind of system at all, from first principles, without prior training, thanks to their superior powers of analysis. Success in the artificially constructed world of software design promotes a dangerous confidence.
Great stuff as usual from Maciej, ending with a rallying cry for us to pay attention to history:
This is not the first time an enthusiastic group of nerds has decided to treat the rest of the world as a science experiment. Earlier attempts to create a rationalist Utopia failed for interesting reasons, and since we bought those lessons at a great price, it would be a shame not to learn them.
There is also prior art in attempts at achieving immortality, limitless wealth, and Galactic domination. We even know what happens if you try to keep dossiers on an entire country.
If we’re going to try all these things again, let’s at least learn from our past, so we can fail in interesting new ways, instead of failing in the same exasperating ways as last time.
Saturday, June 11th, 2016
Thursday, May 26th, 2016
Thursday, April 14th, 2016
This looks like it could be a very nifty tool to have at your disposal while coding. I like that it’s editor-agnostic.
Sunday, April 10th, 2016
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).
Tuesday, March 29th, 2016
Not to sound all “Get off my lawn, kids!” but I think there might be something to this. When you’re requiring hundreds of dependencies to do little tasks that you should be able to code yourself, something’s not right.
But, for the love of all that is programming, write your own bloody basic programming functions. Taking on dependencies for these one-liners is just nuts.
That said, you don’t want reinvent hundreds of wheels either (as most of the comments point out). There’s a balance to be had.
Friday, January 22nd, 2016
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