But if I were going to bet on a web technology, it’s HTML. Always bet on HTML.
This is clever—using custom properties to enable if/else logic in CSS.
This is a very clear description of the differences between libraries and frameworks, along with the strengths and weaknesses of both.
A library is a set of building blocks that may share a common theme or work well together, but are largely independent.
A framework is a context in which someone writes their own code.
I very much agree with the conclusion:
If your framework can be a library without losing much, it probably should be.
Ultimately, however, our decision to switch was driven by our difficulty in hiring new talent for $UNREMARKABLE_LANGUAGE, despite it being taught in dozens of universities across the United States. Our blog posts on $PRACTICAL_OPEN_SOURCE_FRAMEWORK seemed to get fewer upvotes when posted on Reddit as well, cementing our conviction that our technology stack was now legacy code.
This is all just mwah—chef’s kiss!—perfect:
Every metric that matters to us has increased substantially from the rewrite, and we even identified some that were no longer relevant to us, such as number of bugs, user frustration, and maintenance cost.
I am the programming equivalent of a home cook.
The exhortation “learn to code!” has its foundations in market value. “Learn to code” is suggested as a way up, a way out. “Learn to code” offers economic leverage, a squirt of power. “Learn to code” goes on your resume.
But let’s substitute a different phrase: “learn to cook.” People don’t only learn to cook so they can become chefs. Some do! But far more people learn to cook so they can eat better, or more affordably, or in a specific way.
Portrait of the genius as a young man.
It is fortifying to remember that the very idea of artificial intelligence was conceived by one of the more unquantifiably original minds of the twentieth century. It is hard to imagine a computer being able to do what Alan Turing did.
We construct top-10 lists for movies, games, TV—pieces of work that shape our souls. But we don’t sit around compiling lists of the world’s most consequential bits of code, even though they arguably inform the zeitgeist just as much.
This is a fascinating way to look at the history of computing, by focusing in on culturally significant pieces of code. The whole list is excellent, but if I had to pick a favourite …well, see if you can guess what it is.
A bit of a tangent, but I love this description of reading maps:
Map reading is a complex and uniquely human skill, not at all obvious to a young child. You float out of your body and into the sky, leaving behind the point of view you’ve been accustomed to all your life. Your imagination turns squiggly blue lines and green shading into creeks, mountains, and forests seen from above. Bringing it all together in your mind’s eye, you can picture the surroundings.
I find myself doing pseudo code before I write real code, sure, but I also leave it in place sometimes in code comments.
This is a great piece! It starts with a look back at some of the great minds of the nineteenth century: Herschel, Darwin, Babbage and Lovelace. Then it brings us, via JCR Licklider, to the present state of the web before looking ahead to what the future might bring.
So what will the life of an interface designer be like in the year 2120? or 2121 even? A nice round 300 years after Babbage first had the idea of calculations being executed by steam.
I think there are some missteps along the way (I certainly don’t think that inline styles—AKA CSS in JS—are necessarily a move forwards) but I love the idea of applying chaos engineering to web design:
Think of every characteristic of an interface you depend on to not ‘fail’ for your design to ‘work.’ Now imagine if these services were randomly ‘failing’ constantly during your design process. How might we design differently? How would our workflows and priorities change?
Lots and lots of programming advice. I can’t attest to the veracity and efficacy of all of it, but this really rang true:
If you have no idea how to start, describe the flow of the application in high level, pure English/your language first. Then fill the spaces between comments with the code.
Blogging about your stupid solution is still better than being quiet.
You may feel “I’m not start enough to talk about this” or “This must be so stupid I shouldn’t talk about it”.
Create a blog. Post about your stupid solutions.
This really is a most excellent introduction to React. Complete with cheat sheet!
This is a wonderfully written post packed with hard-won wisdom.
This are the myths that Monica dispelled for herself:
- I’m a senior developer
- Everyone writes tests
- We’re so far behind everyone else (AKA “tech FOMO”)
- Code quality matters most
- Everything must be documented!!!!
- Technical debt is bad
- Seniority means being the best at programming
A (possibly) Turing complete language:
As the validity and the semantics of a program depend on the structure of the London underground system, which is administered by London Underground Ltd, a subsidiary of Transport for London, who are likely unaware of the existence of this programming language, its future compatibility is uncertain. Programs may become invalid or subtly wrong as the transport company expands or retires some of the network, reroutes lines or renames stations. Features may be removed with no prior consultation with the programming community. For all we know, Mornington Crescent itself may at some point be closed, at which point this programming language will cease to exist.
This post absolutely nails what’s special about CSS …and why supersmart programmers might have trouble wrapping their head around it:
Other programming languages often work in controlled environments, like servers. They expect certain conditions to be true at all times, and can therefore be understood as concrete instructions as to how a program should execute.
CSS on the other hand works in a place that can never be fully controlled, so it has to be flexible by default.
Max goes on to encapsulate years of valuable CSS learnings into some short and snappy pieces of advices:
No matter what your level of CSS knowledge, this post has something for you—highly recommended!
fopenwhen you can write
throwVE. Call that name
fct. That’s German naming convention. Do this and your readers will appreciate it.
I missed this when it was first posted three years ago, but now I think I’ll be revisiting this 12 minute interview every few months.
Everything that Kyle says here is spot on, nuanced, and thoughtful. He talks about abstraction, maintainability, learning, and complexity.
I want a transcript of the whole thing.