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.
—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.
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.
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.
Functional programming fascinates me. In many cases, a functional solution feels like a better solution to day-to-day programming problems, but it's hard to fully apply them in an object oriented language.
That said, keeping some core FP ideas in mind will help you write cleaner code in any environment. Steven Vandevelde explains a few basic concepts accompanied by beautiful illustrations to visualize it all with Lego blocks.
This is a more visual approach to the topic of purely-typed functional programming. What does it mean to have a “functional” programming language? What are types? What makes a functional-programming language “pure”? These are the questions we will answer here, with a focus on simplicity.
Dave Akins wrote 42 laws you should abide by when building spacecrafts. I'm not planning to build a spaceship any time soon, but apparently there are a lot of similarities with web development. A few examples:
- Engineering is done with numbers. Analysis without numbers is only an opinion.
- Design is based on requirements. There's no justification for designing something one bit “better“ than the requirements dictate.
- Don't do nuthin' dumb.
- Space is a completely unforgiving environment. If you screw up the engineering, somebody dies
Well, that last one is absolutely not applicable to the average web developer, but it's a good one to keep it this in mind next time something goes wrong in production.