I use Svelte at my job. It has a thing called stores and they are nice.
In a nutshell, they help you with reactive state. But I don't come here to tell (sell) you Svelte or its stores and why you should use them; there are too many plenty of online articles and courses that do that already.
I just want to tell you that they are just variables with not much more on top.
If you are like me, you like to poke at the source code of your dependencies, even if it's a compiler[1]. I was surprised to find out how simple the implementation of a Svelte store was. They are just a variable (technically it is a lexically scoped variable or closures but that's not too important).
Below is a synopsized version of the implementation[2]:
function writable(value) {
const subscribers = new Set();
function set(new_value) {
if (value !== new_value) {
value = new_value;
notify_subscribers(subscribers);
}
}
function update(fn) {
set(fn(value));
}
function subscribe(run) {
const subscriber = [run];
subscribers.add(subscriber);
run(value);
return () => {
subscribers.delete(subscriber);
}
}
return { set, update, subscribe };
}I omitted some parts of the implementation related to some utility callbacks—but they're not used as often nor are the selling point of stores.
I think that—besides the simplicity—there are deeper lessons here.
For one, scrutinize what your tools are made of!
We live in the era of open-source. Stallman et al. fought hard for you to be able to do this. Take advantage of the times we are living in.
After all, many tools are written by people no more intelligent than you, but (probably) more diligent than you. But you also have way more agency than you think over that second trait.
In fact, minutes before writing this, I was reading the code for the Clojure compiler to (really) understand the differences between (standard) macros, reader macros, and special forms. At first, I was a bit scared. But no more than 15 minutes in and I already had code that corroborated my understanding.
The great thing about learning through scrutiny is that, by the end, I am confident that I learned well.
It was my terminal running code against the source code of the compiler; me against nature. And I won.
I love this approach for two reasons:
Why don't most people do this? The answer is boring and simple: because it's painful. It's the same reason why people spend millions of hours and dollars looking for magic meals and a perfect routine instead of just eating less and moving more. Losing money and time is less painful than actually trying to accomplish your goals.
So, the feeling of pain should serve as a hint that you should do it this way. Reading axiomatic material feels painful but, if you time yourself, you'll realize you've actually not spent that much time. Doing things the “good way” always feels painful and slow. That's why we spend hours on platforms like YouTube, Twitter, or Instagram and yet it only feels great and fast—until it doesn't.
So anyways, Svelte stores are great for handling app state and can teach you a thing or two about life!
Plug: we use Svelte stores at KREA all the time. And if this kind of engineering mentality resonates with you, we are hiring technical talent. Send me a direct message over Twitter/X or send me an email to d at krea dot ai.
[1]: if you didn't know, Svelte is a compiler that outputs JavaScript as opposed to, say, bytecode or x86 instructions.
[2]: The actual implementation can be found here.
Understanding is sensing well.
When I ask illustrators or designers what is a fundamental skill when it comes to their craft, many reply “seeing well”. It sounds obvious, but it's easy to ignore the deep implications because of how simple the answer is. Many aspiring artists grab a pencil and start drawing right away. But few focus on what the world is really telling them.
I try to be mindful of this and practice the skill often. It's a keystone skill; seeing well makes life more riveting: if you pay attention to your loved ones, your relationships flourish; and, if you see people wholly, it's hard to judge anyone.
Seeing well simplifies problems; a lack of vision makes them more difficult.
Why did it take me so long to see this? The best reason I could come up with is that is hard not to take reality for granted. That's why many drawing exercises involve tricking your brain by fighting presumption: drawing upside down, focusing on the background (instead of the foreground), or drawing simple shapes until they become second nature.
Kill presumption to understand the world.
Seeing things for what they are is priceless. And this does not only apply to vision: understanding is sensing well.
I wonder if this is the reason why we say “Oh, I see.” when we (think we) understand something.
]]>Everything has foundations. Have you thought about that?
If you've undergone formal education, you've heard a professor mention the importance of foundations. In fact, math curricula are built that way: you learn the basics of arithmetic before you jump into linear algebra or group theory.
The core value proposition of foundations is that they help you learn well: learning foundations implies easier progress.
Sometimes it's hard to see what builds upon what. This happens often, especially as a field of knowledge matures.
What's interesting is that each layer of foundation does not necessarily stack on top of each other. While analogies are great for initial intuition development, they can lead us astray in our search for truth. I've heard expressions along the lines of “building the roof before the walls” when emphasizing the role of foundations. But, this assumes knowledge is linear—which is wrong if you look at the history of human discoveries. What many consider useless may turn out to be extraordinarily useful and vice versa. But figuring out what has value and what has not is hard.
For example:
Foundations stacking on top of each other is useful to understand the utility of core skills (better learning), but it may be erroneous to think of knowledge as bricks. At that point, we've overextended the analogy. What happens if you have knowledge that is interconnected? In that case, there is no single piece on top of another piece; both are valid pieces of knowledge. The analogy breaks particularly as the number of pieces increases.
At that point, it's more useful to think of human knowledge as a graph—or, if you want to be pedantic about it, a hypergraph.
]]>Does foundational knowledge disappear? If so, how long does it take until it happens?
We forget how to do things all the time: civilizations, skills, languages. Oh, languages... Many are lost in time. Or rather, they get stuck in time: we know where they are; we just can't reach them anymore—they're stuck there.
The same happens for software. But digital preservation is hard. Have you ever tried running really old software on modern computers? How many computer programs do you own that would work without an internet connection? Do you really own that program?
Some people interact with computer programs but they don't really know how a computer works. I've written C and x86 assembly programs and I know that I do not know how computers work. I know many computer science grads in the same situation: not knowing how a computer works and who've never done science. I did not forget how computers work, I never learned it. At one point, most of the software engineering population will be in that same spot (is it there already?). What happens then?
Most of my family forgot to be self-sufficient in one generation. Before my generation, we were farmers. Now, they know how to cook but do not know how to get food from Earth. The newer generation uber-eats but under-cooks. It only took one generation to forget how to conquer the world woven by nature and another one to forget how to skillfully maneuver the one crafted by humans.
Yes, there are still farmers and chefs around. I am just skeptical about our ability to distribute and preserve foundational knowledge in the constant pursuit of new one.
]]>You should write. You (probably) already know that[1].
I started internalizing it more when I came to a simple (high-school math related) realization: an unlikely combination of rare skills is unintuitively unlikely.
The probability that two independent events, P(A) and P(B), occur is P(A) times P(B). If the probability of events A and B are 10% and 10%, the probability that both occur is 1%. Easy-peasy. But of course, in reality, finding completely unrelated events is rare, but let's put that aside for a moment.
However, we can analogize events with skills and probabilities with percentiles. That is, the percentile of two independent skills P(A) and P(B) is roughly P(A) times P(B). So, finding a person in the top 1% implies finding someone within the top 10% of two independent skills[2].
Given that writing is a communication and thinking tool, it's safe to assume that if you do not write well, you (probably) cannot be a great hacker. Smarter hackers than I have already said this many times.
To become a top one percent hacker, you can either be a top one percent hacker or a top one percent that happens to be a hacker. The former is about becoming insanely great[3] at programming. The latter is about becoming great at the hacking craft while also being great at something else.
If how well you communicate with computers is independent of how you do so with people: we have a jackpot.
Learn to talk to/write to/read computers and people alike.
After all, the probability that you can do both may be rare squared.
Footnotes
[1]: This post is, in small part, a response to a post I saw on HackerNews titled “Engineers should focus on writing”.
[2]: Or any other solution to the equation, I know, I know...
[3]: I still wonder about the relationship between The Macintosh and Insanely Great.
]]>