Alex Russel, software engineer for Chrome and sometimes harsh critic about the state of web performance, talks about how we're forsaking our users in favor of our shiny developer tools.
“These tools let us move faster. Because we can iterate faster we’re delivering better experiences. [...]”
This argument substitutes good intentions and developer value (“moving faster”, “less complexity”) for questions about the lived experience of users. It also tends to do so without evidence. We’re meant to take it on faith that it will all work out if only the well intentioned people are never questioned about the trajectory of the outcomes.
These kind of conversations should happen on a case by case basis; it's impossible to have meaningful discussion without context here. However, I do agree with the sentiment that our tunnel vision on developer experience (using heavy frameworks for no reason, pulling in a gazillion libraries,…) has a deteriorating effect on the user experience provided by our applications. We can and should do better.
shared a shitty article about software quality guided by his "Everybody poops rule".
Everybody poops. But you don’t poop in every room in the house. You have a special room where you poop, you put a door on it and you only poop there.
A program is never "done", and in turn will never be perfect. It's important to differentiate between parts of a codebase are worth investing in, and parts that can be crappy, as long as they're contained in their own space.
The Everybody Poops rule is about admitting some parts of a system will be… well, crap. Not every part of the system could or should be top tier quality. Eventually, everybody poops. It’s a natural process. [...]
Just because you can manage poop successfully doesn’t mean you should do it everywhere. No amount of engineering will ever make a kitchen toilet a good idea. Similarly, don’t crap in the domain layer.
I recently stumbled across this idea in a Hacker News comment.
The principle of least astonishment applies to user interface and software design. A typical formulation of the principle, from 1984, is: "If a necessary feature has a high astonishment factor, it may be necessary to redesign the feature."
In general engineering design contexts, the principle means that a component of a system should behave in a way that users expect it to behave; that is, users should not be astonished by its behavior
In my experience it's often a good idea to draft your program's public API before actually building it. Don't let implementation details influence design.
Amber Case expresses her frustrations towards the use of touchscreen in modern machines. Being software-driven, touchscreens are a lot more flexible than analog interfaces, but they come with their own tradeoffs.
Serious interfaces — those that are repeatedly used by a knowledgeable professional and/or in potentially hazardous situations, should not be touchscreen based. If a touchscreen must be used, it should be embedded alongside a set of fixed, physical buttons that support muscle memory and single actions.
My takeaway is that we should stop making everything more “high-tech” for the sake of it, and shouldn’t be afraid to take a step back and evaluate our creations from first principles.
—who has managed to blog consistently every week this year 😯—shares his experience applying “consistency” rules to his objects.
When you create an object, it should be complete, consistent and valid in one go.
In the post, a geolocation service gets a refactoring treatment. Matthias goes through multiple iterations, each with their own tradeoffs.
It is derived from the more general principle that it should not be possible for an object to exist in an inconsistent state. I think this is a very important rule, one that will gradually lead everyone from the swamps of those dreaded “anemic” domain models. However, the question still remains: what does all of this mean?
Despite the title, the beauty of this article isn’t in a quick guideline, but in the refactoring process that we get guided through.
Whats the worst that could happen? People are gonna talk shit? I got news for you kiddo, you could put out the most perfect, useful, fuckin mind blowing code that ever touched GitHub and guess what? Some asshole is gonna come in and whine about something. Its an inevitability. Worst case scenario, you learn something. Someone will be like, “Hey this makes performance suck” and you can either be like, “Ugh I’m bad at programming, I quit” or you can be like “Oh wow, thanks for the tip, just fixed it, now its better”. Be the person who makes it better.
Igor Mandrigin gives an illustrated introduction to optimistic UIs. You may have not heard of optimistic user interfaces yet, but they're all over the web.
Optimistic UIs don’t wait for an operation to finish to update to the final state. They immediately switch to the final state, showing fake data for the time while the real operation is still in-progress.
Optimistic user interfaces are a core concept in today's web applications. Our interfaces expect a user action to succeed, so they don't need to wait for a server response to move on to the next task.
It is a very simple concept behind a fancy name. Yet it can make a huge impact on your users’ happiness. Firstly, it makes your app feel faster. User can start doing something else while your app uploads a Hilarious Betty the Cat Picture or posts a Smart And Ironic Comment to a discussion. Secondly, it streamlines the experience by removing unnecessary states and distractions. The app will look simpler and more friendly.
As developers and designers, we face criticism on a daily basis. Criticism can come from anywhere: clients, colleagues, other peers, social media; that's why it's important for us to be able to take (and give!) criticism in a constructive manner.
I firmly believe you can be a critic while being kind and open-hearted. I don’t even care if that sounds naive. Most people think the number one goal of a critic is to judge whether work is good or bad. They are wrong. #imo The number one goal of a critic should be to make things better. That’s it. None of this binary good/bad stuff.
Event sourcing is a hot topic (well, it's heating up). Kickstarter's engineering team decided to dive in and build their next product with a home-grown event sourced approach.
Author Philippe Creux compares event sourcing to Git:
Most software developers use a tool to keep track of code history. Git is a fantastic example that’s used widely across the industry. Type git log and you can see all the changes made to a codebase. Who made the change, when it happened, what the change was, why the change was made and how the change was performed. Git is also a time machine, that allows you to go back in time and see what the code looked like back then. You can also replay history and play what-if scenarios: go back in time, checkout a new branch, commit a change, and replay all the events commits that happened after that.
A more formal definition by Martin Fowler is:
All changes to an application state are stored as a sequence of events
The article serves as a hands-on guide to build a pragmatic event sourced system. It's an interesting topic for both back- and frontend developers. If you're a frontend developer, you might already be applying event sourcing ideas with state management libraries like Redux.
Having this feature available in Babel has gotten me thinking about how we can use private fields in our code and how they influence our designs. And I think the possibilities are pretty significant. To see why, let’s look at a scenario when we might want to refactor our code to private fields, and the impact it has.
Hidde de Vries, a freelance frontend developer from the Netherlands, had the honor to follow a lecture from no one else than Sir Tim Berners-Lee, inventor of the world wide web. Hidde recaps Sir Berners-Lee's talk about the history, current state and future of the web.
Berners-Lee first showed a virtuous circle: if all goes well the web lets people publish, which inspires conversation and more publications. This is the utopian scenario and we’ve seen a lot of this actually happen. The web community itself it s a great example of this, we teach each other stuff and good blogs inspire other people to start blogging.
The creator of the web warns about a dystopian future, where algorithms decide what we get to see on the web, which in turn narrows our view. It's time for a redecentralised web!
React in patterns is a free book that serves as an introduction to React. Even though it's tied to React, it's a compelling read if you do anything with user interfaces.
It is nice that we may think about every React component as a black box. It has its own input, lifecycle and output. It is up to us to compose these boxes. And maybe that is one of the advantages that React offers. Easy to abstract and easy to compose.
Instead exploring React's API surface like most guides do, it gradually explains the idea of a component model, and how to deal with state & data flow.
Thinking in components, and more specifically learning how to separate your applications concerns with components, has changed the way I tackle interfaces for the modern web.
Mark Rosewater is a game designer for Magic the Gathering, an immensely popular trading card game. He gave an hour-long talk at a game development conference about the lessons he learned in 20 years of game design. Afterwards, these lessons were published as a three part column.
What I've learned over the years is that you shouldn't change your players to match your game; you should change your game to match your players. Don't get yourself into a fight you're probably not going to win. Human behavior is a powerful force. We are creatures of habit and instinctually fear change.
The articles focus on game design, but the lessons are applicable to anything that requires design thinking.
Mark precedes every lesson with an anecdote, explaining what went well or what didn't. Another one of my favorites:
Players' need for individuality is strong, which means that they will be looking to find a small corner of your game where they can feel a special connection. Big things tend to gather too much attention, so it's in the smaller details where players will attach the strongest emotionally, which means that the details are actually far from insignificant.
I don't have any prior knowledge of the game myself, so don't worry about not understanding parts in spite of the topic. If the first six lessons piqued your interest, here are parts two
What a clickbaity title!
I fell for it though. Andrew Askins recounts his recent experience of buying the Startup Watchingnewsletter.
I'm not really into the startup world, but the way Andrew wrote this article, especially how transparent he was about the whole process, makes it a very compelling read.
There are multiple privileges I was born into that made this process easier and I thought it would be good to discuss those. [...] I tried to become financially independent early on. But I also know that even if I empty my savings, and get into a catastrophic accident, my parents will do everything they can to help me. I don’t ever want to put them in that situation, but even subconsciously having that helps me to take more risks.