I've built a couple for myself so far; the most recent is in zig (sqlite extension that treats markdown files / frontmatter as virtual tables) and it's lasted me. I plan to rewrite it soon to adapt to how I've been using it :)
This was the first time I bought a font, and -- surprisingly -- I haven't regretted it at all. Every time I look at my terminal there's always a little bit of happiness at how elegant the font looks.
I've been writing here sporadically for more than 10 years at this point, at ~1 post a year. The more recent posts took months to write, and tend to cover things I find myself repeating frequently while working with other engineers.
I wanted to express thanks for your post on ramping up on large projects. It's concise, links to further reading, and echoes a lot of the advice I have had to give to junior engineers. You've saved me time from having to write these tips out myself. :)
(As an aside I kind of disagree with the common quote of:
> "Show me your flowcharts and conceal your tables, and I shall continue to be mystified. Show me your tables, and I won't usually need your flowcharts; they'll be obvious"
I find that most software I've worked on is muddy, confusing, and contradictory. Perhaps I will get better with time.)
Heh, definitely depends on the software itself but I generally find the contents /schema of tables used to save the data very illuminating: you can see the UX, whatever form it takes -- and then what is saved to the backend so it makes things slightly more understandable for me.
> "you don't have to code all parts of your design".
That's an excellent articulation of what I think as "invisible seams" when I write code: they're soft points of extensions that don't need a separate interface/function/class _yet_. Sometimes I just mark them for myself with an extra newline within a function.
As much as I enjoy writing to think, simply writing doesn't lead to reality testing -- I've found even greater clarity by trying to add numbers or simulations and trying to program around what I'm writing. Writing with real data intertwined and numbers applied is much better.
That can work, but it depends on what you're writing about. Different methods apply in different situations. But good writing has at the very least the advantage of doing what the article notes: it forces you to take what are vague convictions and impressions and justify them. You start to notice gaps in knowledge, inferential leaps, and logical inconsistencies. Only then, and only in empirical settings, do numbers come into play because they need to be motivated by and understood within some prior context. (Even when your writing begins with some number, that number is contextualized in your mind.) Of course, good writing presupposes humility and integrity or else you risk rationalizing and bullshitting.
> As much as I enjoy writing to think, simply writing doesn't lead to
reality testing
Yes it's possible to get cloistered. But I find writing and
formulating ideas gives way to the ability to say it. What was
ineffable becomes clear language I can test with people to see how
it's received.
Agreed. I'm currently working on a book on statistics[1] and keep discovering slight (and not so slight) misconceptions in my thinking thanks to the "optional" code examples and demonstrations. In the end, it seems the code examples won't be optional at all, but essential for understanding.
It's the same with many science and tech subjects. You don't really know it until you can code it. I'm intentionally converting some of the derivations/experiments into exercises for readers to complete on their own, so they can also benefit from this learning process.
I fully agree with you, but as a warning: most people are lazy, so if valuable points are hidden in exercises for the reader, there is a significant chance that many will miss them
I'm glad to see someone with the same idea was able to take it to completion. Life got in the way for me and I never got to implement that part. If I ever get back around to it I will consult your solution if I get stuck.
https://github.com/kunalb/termdex