Results: 58
-
Microblog
2022-08-27 00:00
This page serves as a simple index of all my microblog posts. This list should be roughly equivalent to searching for the #microblog tag.
If you're looking for my longer #blog posts see 201610270000 Tech — Work — Ramblings.
- 202410220101 The Final Edition of Embedded Muse
- 202410201110 Engineering Multi-classing
- 202408250920 1BRC in rust in depth
- 202408220939 Go is not worth it
- 202405051458 Mobile Content Width
- 202405051251 Timeout Killer
- 202405021450 Ideating
- 202404232122 Masonry Layout CSS
- 202404232120 Hell yeah NASA
- 202208270311 Up too late
-
CodeMash 2020 - Review
A More Formal Report on a Conference
2020-04-01 00:00
A review of the sessions I attended, what I learned, and how I liked the overall experience of CodeMash 2020.
Short Post
I said in my live blog post from CodeMash that I was going to do a follow up to the conference and review the experience. Since there were other people at Beam interested in writing about their experiences too, we decided to pool our effort as a team and write a single post for the Beam Engineering Blog. Because it was co-authored by other Beamers on Beam time, I'm not sure if I should cross-post it in its entirety. Instead, here's a link to the finished product, Yet Another CodeMash Blog Post. Go check it out.
On a final note, if you're on the fence about CodeMash, I'd strongly recommend going. I had a great time and would definitely go back in the future.
-
Making a Fitbit Sense Watch Face
Time for a Better Watch
2022-05-01 00:00
There are a lot of good first- and third-party watch faces out there for the Fitbit Sense, but none of them are exactly what I want.
Motivation
There are a lot of good first- and third-party watch faces out there for the Fitbit Sense, but none of them are exactly what I want. So instead of putting up with something slightly sub-optimal, I'm taking a look at what it takes to develop my own. Being a programmer is great isn't it?
This post is still a work in progress, but as I've said, I'm working on showing off more works in progress.
-
The value of a great tech stack
Non-technical reasons to have a great tech stack
2022-08-13 09:54
I’ve been doing some thinking lately about how much value to place on a great tech stack. There are two lenses in particular that I’m looking at this through: value to a product organization and value to the individual engineer as a measure of the desirability and enjoyment of working there.
I’ve been doing some thinking lately about how much value to place on a great tech stack. There are two lenses in particular that I’m looking at this through: value to a product organization and value to the individual engineer as a measure of the desirability and enjoyment of working there.
-
Tech — Work — Ramblings
2016-10-27 00:00
#structure #microblog #tech #ramblings #work #blog
This page serves as a simple index of all my blog posts. This list should be roughly equivalent to searching for the #blog tag.
If you're looking for my shorter #microblog posts, see 202208270000 Microblog.
- 202208010000 Making a Rust Roguelike
- 202206171206 Delivery Performance vs Value Delivery
- 202205150000 Learning Rust
- 202205010000 Making a Fitbit Sense Watch Face
- 202109150000 Idea Gardening
- 202109010000 Prototype Expand Consolidate
- 202108010000 Designing for Big Screens
- 202107150000 Working in Public
- 202107010000 Unifying My Domain
- 202106010000 Rewrites Are (Almost) Never the Answer
- 202105010000 The Silent Majority of Engineering
- 202009010000 The Only Correct Way to Organize Code
- 202007010000 2019 Work Reads
- 202006150000 Gestalt Principles of Design
- 202006010000 Revamping My Blog
- 202004010000 CodeMash 2020 - Review
- 202001080000 CodeMash 2020 - Live
- 201911150000 What React and Kubernetes Teach Us About Resilient Code
- 201810010000 Development Estimates
- 201809010000 Piping Code With GitLab CI
- 201808010000 Cloud Native Computing
- 201807010000 Architecting a More Modern System
-
The Silent Majority of Engineering
A Bit of Perspective
2021-05-01 00:00
Most engineers aren't using all the new shiny tools. Most are quietly coming to work every day, writing code in tried and true ways, and getting things done.
I once heard a quote about software engineers. It went something like this:
Most engineers aren't using all the new shiny tools. Most are quietly coming to work every day, writing code in tried and true ways, and getting things done.
The sentiment has stuck with me. It's something that we don't think about all the time as developers.
There's always something new and interesting to learn and try out. There are never ending amounts of opinions and preferences, ergonomics and design.
It's good to keep up to date. It's good to be a lifelong learner.
But what happens when we need to get something done reliably and predictably?
We don't use all the new shiny tools.
We quietly come to work every day, write code in tried and true ways, and get things done.
-
Idea Gardening
An Organic Process for Developing Thought
2021-09-15 00:00
Idea gardening is the practice of sitting on ideas so that they can germinate on the back burner of your mind.
TODO: remove in favor of the old regular zettel 202109090947 Idea gardening
The Idea Garden
We plant ideas, consciously or not, deep in the depths of our mind. The place is dark, quiet, and damp, heavy with the breath of life.
There they sit in a timeless state, slowly spreading their tendrils, taking root, nourishing themselves on the fertile soil of id.
Sometimes they tangle with other ideas, competing for nourishment or becoming indivisibly fused.
Sometimes they shrink, wither, and decay becoming part of the soil they took root in. Here they'll feed others. Or maybe their seeds will sprout again.
Sometimes they grow in a streak of tenuous height, bursting into the light. If they aren't plucked, their strength wanes and they sink back down to try once more.
And sometimes — very rarely — they grow strong and big. They form pillars between the soil and the sky, connecting deep intuition and emotion to the brilliant light of human intelligence.
This is the harvest of an idea garden and we reap the bounty.
-
Revamping My Blog
A New Coat of Paint
2020-06-01 00:00
You may have noticed that the <mark>blog</mark> got a new look and feel recently. The changes weren't purely cosmetic though. Let's take a look at how I migrated from a Bootstrap and PHP based <mark>blog</mark> to React, Next.js, and Styled Components.
Motivation
It's probably not a surprise to most people that I'd want to switch from a PHP based blog to something a little more modern, but honestly — and perhaps controversially — I think PHP is still an amazing solution for simple use cases like mine. No, the shininess of tech isn't a good enough reason on its own for me to rebuild the blog from the ground up. So what reasons were there for updating things and switching tech?
Criteria
- Ease of Maintenance — My blog was running like a dream for years on a crazy simple setup, so any solution that I went with was going to have to at least match it in terms of maintenance effort.
- Ease of Writing — There was quite a bit to be desired in the old setup. I was using a rich text editor that was hard to get well formed rich text data out of. It was also really difficult to use on mobile. Wanting to use a simpler format (like markdown files) and the ability to use a plain text editor was a big reason to make a switch.
- Performance — My old setup was slow for a host of reasons. I was running PHP and MySQL on the same old machine sitting underneath my printer. The thing was ancient when I acquired it longer ago than I care to admit. It would be nice if I could take advantage of something out there that did lightning fast static site edge cached delivery.
-
Making a Rust Roguelike
Making a Game Out of Learning
2022-08-01 00:00
In the process of learning Rust, I'm following a great tutorial for building a roguelike game.
Background
There are a lot of ways to learn a programming language: from docs and books to puzzles to fun side projects.
There's a really great community on Reddit called /r/roguelikedev and one of their coolest resources is a comprehensive tutorial for making a roguelike game from scratch in Python called The Complete Roguelike Tutorial or TCOD. A guy named Herbert Wolverson built a really amazing version of that tutorial in Rust (with some changes).
One of my friends who's into game development showed me all these things and how he was going through that Rust tutorial and porting it to his most comfortable language, C#. Since I was already learning Rust, I thought I would give the Herbert's Rust version a try.
So come along and join me as I document some progress and thoughts about Rust and game development. Hopefully I'll be able to build the final game to WASM and embed it as a project here on the site.
-
My Brand New Blog
An Exercise in Futility?
2016-10-28 00:00
Maybe it's the infinite hubris of a millennial or maybe its just that I doubt anyone will actually read this, but I found a few reasons to convince myself to do it anyway.
I thought about that question a lot before building this. Most blogs are out of date, under-maintained, new year's resolution-esque things that wither and die after a few entries. Why create something that has a high likelihood of being abandoned? Beyond that, how could I possibly think that anything I have to say is worth writing about? Maybe it's the infinite hubris of a millennial or maybe its just that I doubt anyone will actually read this, but I found a few reasons to convince myself to do it anyway.
I'm Already Writing Anyway
I've been in the habit of keeping a journal for a long time. I keep it for a lot of reasons: it helps me think aloud, it helps me recap my days, weeks, months, years, it teaches me about myself, it gives me perspective on why things did or didn't break my way. However, a journal, at least how I write mine, doesn't work well for giving a single topic more attention. I still write about topics that interest me, but diving in and exploring those topics fully isn't something that fits in a medium whose primary purpose is to record and reflect. A blog, on the other hand, is the perfect medium to write in-depth on a single topic. A blog also gives me the flexibility to write about any topic that's currently interesting me.
-
Unifying My Domain
A Question of Scope
2021-07-01 00:00
Bringing all my projects under one roof.
I've been working a lot of small projects lately, learning some cool things, and wanting to write about it all. At the same time, I want to host the projects so I can link to them and show them off.
So I started updating my old site so that I could use it for hosting these projects, but then thought better of it. Instead of blogging on my blog, putting my portfolio on my homepage, and other things on other sites and domains, I'm just going to put it all in one place.
I think this approach is a good idea for a few other reasons too:
- All the code will live in one place so I'll be much more likely to maintain it and keep evolving it over time to be the tool that I want it to be.
- Building things is quicker and easier because I don't have to bootstrap a new project every time.
- I can easily expose all of my ongoing work to the world.
- There's no question about where something new should live.
On the other hand, there are some downsides:
- The project will get big.
- I'll be constrained by the tech and framework I chose here. It'll be more difficult to show off something like a Haskell project.
- Rewrites are tricky to do well. Though I have a leg up here because I'm the demanding stakeholder as well as the developer and customer.
-
Have fun and be terrified
2024-08-22 20:21
Have fun and be terrified. I can do that.1
On quitting your job and striking out on your own, or more broadly, daring to do something and put your skin in the game #wip
-
Suresh, N. (2024, August 21). Quitting My Job For The Way Of Pain [Blog]. Ludicity. https://ludic.mataroa.blog/blog/quitting-my-job-for-the-way-of-pain/ ↩
-
-
Working in Public
A Way To Be More Open
2021-07-15 00:00
Finished things don't spring up out of the ground in their final state — people have to work hard on them. This is my way of pulling back the curtain on how I work.
Working in public is the idea that we should all share more of our work in progress. Finished things don't spring up out of the ground in their final state — people have to work hard on them. So working in public is an attempt to show that hard work. Or at least the time and effort that go into things, even if it's just a slow burn over some period of time.
Why would I want to work in public?
This is my way of pulling back the curtain on how I work. It's something that I feel is important and wish that there was more of on the internet.
The internet is such a big, corporate, impersonal, hate-filled mess, but there was a time when it wasn't and it could be cozy again. I consider mkalvas.com to be my version of a cozy little digital garden, safe from the ads, tracking, and noise of the rest of it. I don't know if anyone visits this site and I don't really care.
Another reason to work in public is that I believe that writing (more broadly doing) provides a final generative step in knowledge creation and retention). So anything that I can do to lower the barrier and promote more writing (code and words) is a good thing. One simple thing that can lower that barrier is to allow myself to be more comfortable with unfinished, unpolished things. I find that saying "this isn't done enough to go on the site" results in less doing in the first place.
-
Prototype Expand Consolidate
A Method for Building Maintainable Systems
2021-09-01 00:00
Today we look at an efficient, sustainable engineering loop — prototype, expand, consolidate.
TODO: remove for regular zettel?
The Loop
An efficient, sustainable engineering loop can be describe through the motto prototype, expand, consolidate.[^foote1994] This loop consists of three eponymous phases. This has also been referred to as the Fractal Model of software development lifecycles.
Phases
Prototype
Our primary objectives during the prototyping phase are learning about the problem space and fitting a solution to that. We pick specific portions of the problem space to stake our understanding to and just start building something.
We deliberately don't spend time trying to build perfect understanding and systems during this phase. Doing so is a waste of time because we're inevitably blind to the realities at the end location without walking the path first.
Expand
Our next objective is to expand. Similar to prototyping, we expand our understanding of the problem space and the robustness of our solution. This is the phase where nuance comes in. People find themselves saying "I didn't know that worked like that" or "I didn't know it needed to be able to do that" which causes us to expand our knowledge and systems to incorporate new ideas and functions.
-
Cleaning Out the Skeletons
An Effort to Put My Best Foot Forward
2016-12-01 00:00
Growing up at the start of social media has its downsides. Today I talk about cleaning up my online presence.
Cultivating a professional online presence is something that I've been casually working towards this year. In fact, I mentioned in a previous post that one of the main reasons that I started this blog was to further that goal.
In my mind, there are two important steps along the way to building something I'm proud of: cleaning out low-quality content from the past and adding new high-quality content going forward.
Out With the Old
Now begins the painstaking task of combing through every old post, tweet, status update, etc. that I've ever posted. If you've ever been a teenager, you probably know the kind of things that I'm sweeping under the rug here: teen angst, vaguely subtextual nonsense, humble brags, and any of the other cardinal sins of social media.
I've never publicly acknowledged it before, but for a while in college, I was lost. I didn't know what I wanted with my life, I wasn't happy with myself or the things I was doing. I felt depressed and anxious every day. I put a lot of my worth in other people. Many of my core values and perceptions of the world were changing for the better and I was experiencing growing pains. As you can imagine, I posted some things that I'm not proud of. I also posted a lot of things that bring back painful memories as I look back on them today.
-
Piping Code With GitLab CI
A Simple Way to Make Your Life Easier
2018-09-01 00:00
I finally got around to adding continuous integration pipelines to my personal projects.
What is Continuous Integration?
At its most basic, continuous integration (CI) is the practice of frequently merging developers' code changes into a mainline code repository. In recent years, the concept of continuous integration has taken on a life of its own and been expanded to include other aspects of development. For instance, almost anyone referring to continuous integration is under the assumption that the frequent merging will be automated. There have also been expansions of the idea such as continuous deployment (CD) where the code is not only automatically merged into mainline branches, but also built, tested, and deployed. By automating all of these simple repetitive tasks, developers can stop spending time on manual integrations and deployment processes and spend more time coding.
GitLab CI
For various reasons that are far outside the scope of this post, I host my personal code on an on-premises GitLab server. GitLab has hundreds of amazing features to take advantage and one of the nicest of them all is their CI/CD pipelines. GitLab has all of the automation and task running capabilities of other separate solutions built in.
-
Willful ignorance of reality in organizations
2024-08-22 08:51
In organizations, there's a tendency for people at higher levels or in roles further removed from the "doing" of a project to be vague to the point of harm. Some (bad) managers want something done and want other people to deal with how that gets done or indeed whether or not it's even possible to do it.
[I]t boils down to a psychological distance from the fact that true reality exists, and that someone lower status has to handle it.[^suresh2024pain]
I see this frequently in the interactions between (bad) product managers and engineers. The PM has an idea or a requirement to build something that they don't inspect closely or take the time to understand the reality of that idea. They don't understand what it would take to build it, what it would feel like to use, or whether it's a good idea once faced with all the edge cases involved. The idea of doing all that work is either too challenging or demeaning to these bad actors and it ends up falling on the individual contributor who actually produces the work output to solve these problems.
I've alternatively called this "compression of reality" and "where the rubber meets the road" to show that engineers don't have the luxury to hand wave or be vague when writing code. They have to specify — in exacting detail! — how it all works.
-
The abyss gazes back
2024-08-23 23:59
He who fights with monsters might take care lest he thereby become a monster. And if you gaze for long into an abyss, the abyss gazes also into you.[^nietzsche1886]
Firstly, we must not fall into the mindset or actions of the things we’re examining when studying evil, immorality, or even lesser undesirable things.
More abstractly, there’s a danger of being absorbed into the thing that you “gaze at.” This can apply to academia and learning for learning’s sake, where we lose sight of reality, purpose, or reason.
It also works to illustrate that merely observing something is not a totally detached process. It’s not possible to completely detach from the observed phenomenon. The mere act can change you and affect you in unintended or undesirable ways.
Lastly, it speaks to the dangers of romanticizing things that should not be: depression, abnegation, loneliness, and more. If I allow my mind to spend time gazing into depression for instance, I’ll be swallowed by it. 202408221304 Desolation tries to colonize you.
We can call the depression void-gazing. Everyone does it sometimes, but step two has to be wrenching your gaze away from the void and doing something. There's nothing in the void but more void and the curse[^suresh2024angry]
-
Designing for Big Screens
An Experiment in Adding More
2021-08-01 00:00
I've always wanted to see what was possible on the web when we use all the space we're given. Today we look at my take on how to add more for those who have the extra real estate.
There's that old, inaccurate saying, "we only use 10% of our brain". As terrible as it is, it's stuck with me over the years for some reason and it popped into my head the other day while working on this site.
I was trying to decide how to handle extra large breakpoints and was settling on containers with a
max-widthso that the content stays centered and predictable. It works well, but when using a ultra-wide screen or ultra-high resolution screen there's a lot of blank space just hanging around. So I started trying to think of a way to make the site more useful for people with all that extra real estate. After all, more and more people are using UHD screens.Note: For the rest of this post, I'm going to use the abbreviation UHD to refer to anything that's got enough screen space to end up in this category where there's usually a lot of blank space. Typically, I'm thinking of screens that are over 1440p. So something more in the 4k range, but not necessarily. A ultra-wide 1080p screen might also be considered UHD in this context just because it has much more horizontal space than a typical 1080p screen.
-
Optimal line length for readability
2022-07-06 16:26
The optimal line length for readability on a screen is 50-75 characters.1
-
Scott, E. (2022, May 10). Readability: The Optimal Line Length – Articles. Baymard Institute. https://baymard.com/blog/line-length-readability ↩
-
-
Rewrites Are (Almost) Never the Answer
A Difference Between Desire and Reality
2021-06-01 00:00
Rewrites are tricky to get right. Despite how often we're drawn to them, they're almost never the right solution.
As a developer, my first reaction when getting into a legacy codebase is almost always to bulldoze and rewrite it. Unfortunately, rewriting code is commonly a huge mistake for software companies.
If you've been around long enough, you've probably read the classic article by Joel Spolsky, a founder and ex-CEO of StackOverflow where he names rewrites the "single worst strategic mistake that any software company can make." In this article he walks through a dot-com era rewrite by Netscape that was such a bad idea, it can track directly to the downfall of the company.
As developers, want to do rewrites because we get our excitement from building things that we can call our own — grand, shiny towers of our Legos that we can point to and say, "I did that." But according to Spolsky, there's more to it.
There's a subtle reason that programmers always want to throw away the code and start over. The reason is that they think the old code is a mess. And here is the interesting observation: they are probably wrong. The reason that they think the old code is a mess is because of a cardinal, fundamental law of programming:
-
Shades of Self
A Look at Who We Are
2018-05-01 00:00
A rambling, philosophical look at how we exist as distinctly separate individuals in different situations.
I was in an unusual debate at work the other day. I took a stance that was odd for me which led to some introspection. Why did I debate for a position that I wouldn't typically support? I felt that I was disingenuous or dishonest towards my co-workers, but is that true? Is it possible for me to maintain different perspectives on the same subject depending on the context of the debate? If so, can I do that without being self-serving or hypocritical?
I believe that it's not only possible to maintain these different levels of self without being unethical, but also that most people probably do it every day without even realizing it. I've identified five different levels of my self that I express based on where I am, what I'm doing, and who I'm with. In my head, I picture these as a pyramid where the topmost level is the most restricted, manicured, public version of ourselves and the bottom is the most personal, intimate version.
Professional Public
We start at the top of the pyramid with our most carefully crafted public identities. This is the persona that we show during an interview or formal meeting. I like to call it the Professional Public self. It's the level that we feel most comfortable with the world seeing. It's where we put the information that we want people to see and know about us: our professional accomplishments and things we're proud of.
-
First Reactions to React
A Review of Building My First React App
2018-06-01 00:00
We're moving our corporate site in house and I thought it would be the perfect time to try out a new javascript framework.
There are plenty of good javascript frameworks out there right now; among the most popular are Vue.js, Angular, and React. (Yes, I'm aware that React is a library not a framework, but for the sake of this article, I'm going to set that aside.) There's also a ton of posts and articles that can help you understand the differences between them if you're not familiar. Breaking down all the reasons we chose React over the other two would be a whole post in itself. Maybe I'll write something comparing the frameworks and our opinions on their features in the future. For now, it's enough to say that we took a hard look at all three of these and we felt that React was the best choice for our specific situation.
Diving In
We're using webpack for build tooling, a React front-end, and a C# .NET Core API backend. Getting started was the most challenging part of the whole process with the majority of the issues coming from the webpack configuration. I only ever used gulp before and we wanted to switch to webpack so that we could more easily bundle and ship specific components to third-party API consumers. I'm sure that someone more experienced with webpack could have gotten up and running in much less time than it took me, but it's always nice to have the opportunity to learn a new tool. Besides my personal inexperience, there were some versioning issues between the .NET world and the NPM world that we needed to resolve. We also added to our own headaches by using a slightly wonky legacy environment setup (that's hopefully going away shortly) and by having some external requirements from businesses we partner with. With all of the preliminaries out of the way, we could finally get coding.
-
Architecting a More Modern System
A Look at Microservices
2018-07-01 00:00
Making the move from one monolithic service to many microservices can be a complicated process. Here are some reasons why we decided to make the move anyway.
We have a need for external businesses to be able to embed parts of our apps into their front ends, connect with our APIs, and not bother the third parties with implementation or data handling details. We also don't want to have to maintain too many different solutions and technologies, so if possible the solution should overlap with our own internal needs.
The Solution
Microservice architecture to the rescue, but what really does that mean besides being a marketing buzzword? I'm going to cover three core ideas of microservices: decoupling, distribution, and technology agnosticism.
Decoupling
The obvious result of turning one application or service into many is that the resulting services are less tightly tied together. For people who aren't developers, it might not be obvious why services that are less reliant on each other might be better than the alternative.
As in all things, programmers deal with side effects of their actions, or more precisely, the actions of their code. Without getting into too many details, programming side effects can be nasty. There are a whole host of frameworks, technologies, and design patterns that are specifically built to avoid unwanted side effects. Microservice architecture isn't built with that sole goal in mind but it does help us mitigate side effects by requiring our service to have well-defined interfaces for interacting with other services. Basically, when turning one application into many that act as one, we need to take the time to define how they talk to each other including any security and permissions that exist as part of those interactions. We now have a single point of failure for these interactions. It also means that one service can't accidentally do something with another service that it's not supposed to. It's much easier to test our services' internal logic, test their interactions with other services, and even test adding new external services before they even exist. Decoupling leads to more secure, predictable, testable, and fault-tolerant systems.
-
2019 Work Reads
A Slew of Short Book Reviews
2020-07-01 00:00
My professional reads from last year, rated and reviewed.
Overview
I like to read. I read a lot about a lot of things, but I would say that I devote maybe 40% of my reading time to things that I'd consider “professionally oriented”. These are books, articles, blog posts, white papers, etc. that I probably wouldn't read if I didn't have a job. They aren't all directly related to my job, but they all make me better in some way.
So here's a list of professional books I read in 2019 (roughly in chronological order) along with a rating out of five possible stars and the two second summary of why you should or shouldn't read them. Spoiler — they weren't all winners.
Clean Code
by Robert “Uncle Bob” Martin
Rating: 3/5
A slightly dated look at how code can be simple and maintainable. There are some good gems that can be extracted for programmers of any language or experience level. A bit long to read all the way through and considerably better in paper format as opposed to e-book because of the code blocks. Definitely worth a look if you're a day-to-day coder.
-
Think week
2021-10-23 14:33
Popularized by Bill Gates, a think week is a week spent in solitude, focused on thinking.1
The purpose of a think week is to remove distractions and stimuli that will detract from our ability to think deeply on topics and ideas for an extended period of time. A think week can include books or other information sources but shouldn’t include distractions like social media, TV, and the like.
Seclusion, solitude, peace, quiet, light exercise, simple healthy food, and simple living arrangements focused on the environment are all conducive to effective think weeks.
Similar to, but more deliberate and less frequent that 202304112203 Ten percent time.
-
Runaway Suitcase. (2019, June 18). How to do a Think Week Like Bill Gates. Runaway Suitcase. https://www.reservations.com/blog/resources/think-weeks/ ↩
-
-
Delivery Performance vs Value Delivery
2022-06-17 12:06
An alternate title for this essay is The "How" Matters.
I want to talk more about performance — the act of executing, building, delivering, how our team works together and with other teams, and how these stack up against our potential.
I don't want to stop talking about product value — the product, its value, our direction, how we choose what to build, or if what we built was valuable or not.
I just want to additionally talk more about performance.
Here's the way we typically talk about the product, its value, and our performance.
At an individual level you know if you’re doing a good job based on how effectively you’re contributing.
At a team level you see if the things the team built were valuable over a longer period of time.
Directors and executives plan for years out and it can take a long time to get feedback about the value of their decisions.
Therefore, we can’t know as easily or quickly if leaders (or groups of people as a whole) are doing a good job over these long, ambiguous timelines
See 202104291527 Live in the ambiguity and 202104291528 Leaders have to accept a slower feedback loop for more support of this position.
-
Gestalt Principles of Design
A Crash Course on the Whole
2020-06-15 00:00
Today we're looking at 'die Gestalt', the result of early 20th century studies in psychology that described how humans perceive the world, and how it can help us make outstanding user interfaces.
Gestalt Psychology
Gestalt (ɡəˈʃtælt) feminine noun: 1. An organized whole that is perceived as more than the sum of its parts.
Around the turn of the century, German and Austrian psychologists were investigating the human mind's ability to perceive the world around it. Even though we're confronted with a world filled with exceptions and strange sights, we can somehow sort it all out. How do we come to form a meaningful, consistent perception of reality based on the chaotic conditions around us?
The prevailing conclusion of this school of psychology is that when perceiving the world, the mind sees eine Gestalt — or a "global whole" — instead of a collection of individual parts. The mind also has the ability to organize these wholes into even larger wholes. For instance, the mind can recognize a hat or a person as a whole object instead of a collection of lines and curves, but our mind can also perceive a larger whole of a person wearing a hat instead of seeing two smaller unrelated objects near each other. According to one of the founders of Gestalt psychology, Kurt Koffka,
-
Types are not a substitute for tests
2022-08-11 22:28
Type systems cannot and should not be viewed as a replacement for testing. Types cannot ensure that the code you wrote produces the actual outcome that you want it to. Tests on the other hand, can be used to verify and maintain that correctness.
Tests can never provide an unbroken chain of checks, from the database all the way to the frontend React props, guaranteeing that all of the data has the right shape [emphasis mine]. Types can't (usually) tell us when we accidentally put a "!" in front of a conditional. Focusing on one or the other means sacrificing quality, work efficiency, or both.1
Conversely 202208112226 Tests are not a substitute for types.
-
Bernhardt, G. (2020, April 13). Execute Program. https://www.executeprogram.com/blog/are-tests-necessary-in-typescript ↩
-
-
CodeMash 2020 - Live
An Informal Report on a Conference
2020-01-08 00:00
Live blogging from CodeMash 2020
Welcome to CodeMash
This is my first time attending CodeMash. I had some content about PASS SQL Summit (the only other big tech conference I've been to) when I attended back in 2016 but that all got "lost" when I overhauled my servers/blog/websites. I say "lost" but I still have a backup of all of that data somewhere. It's all compressed down into cold block storage in a backup of backups. It'd be an interesting project to try and do a restore of that version of my stuff. I don't know if I actually could remember how to get it all going again. If that's the case, what's the point in keeping the old backups? I suppose I could still get that data even if it's not on a functioning server. I could grab the text from those old posts and add them here or something. But I digress...
I'm really looking forward to all the sessions here. This is also going to be a new experience for me. I was the only person I knew at SQL Summit, whereas there are at least 30 Beamers here. It should be fun having people to go to talks and sit at meals with. Although, SQL Summit pushed me to do those things with people I didn't know and make the most of it. There's probably good and bad to both situations. I'm glad I'll be able to experience both of them.
-
Freedom and Responsibility
2024-07-01 09:52
People must have the freedom to act and the responsibility to act wisely. Without the freedom to act, responsibility is pointless; the system decides what actions can be taken and the responsibility or lack thereof for those actions is vested in the system, not the individual. Without the responsibility to act wisely, the freedom to act is risky and unfair; consequences for those free actions have to be upheld, both positive and negative; accountability for outcomes and whether the act was taken with proper consideration lie on the free person.
Note that this doesn't mean that we all have to be risk-averse. Just because you are responsible for your actions, doesn't mean we have to exact painful consequences. We can create a culture that gives freedom, demands responsibility in return, and then is benevolent with punishment for bad outcomes. If the action was taken in good faith — responsibly — and didn't work out, we can accept that as one of the tradeoffs for the other benefits we gain from FNR. If someone makes an honest mistake, they don't need to be shamed, hurt, or expelled. In fact, this honesty and transparency about outcomes combined with the lenient forgiveness of failure is what drives true freedom to do, build, create, innovate, and achieve.
-
The great stagnation
2021-10-22 09:05
The 202110220859 Utilization adjusted total factor productivity of the US from 1947 through 1972 was 2.1%. Since then it decreased until the dotcom boom in the late 1990s and early 2000s. In 2005 though, the rate plummeted and has been a paltry 0.17% despite a rapid rise in the rate of scientific and theoretical technological progress.1
One lesson to take from this is that science alone isn't enough to end the stagnation. We need science to be applied to goods and services that affect the general public before we'll see a new period of sustained growth.1
One way to understand the forces at play here is to study 202110220853 Second-order thinking and make predictions about what technologies are capable of making an impact on the general public in the next 10 years or so.
-
Dourado, E. (2020, December 31). Notes on technology in the 2020s. Eli Dourado. https://elidourado.com/blog/notes-on-technology-2020s/ ↩ ↩2
-
-
Lightning Talks
A Great Way to Teach and Learn
2018-05-15 00:00
Lightning talks are a great way to share knowledge in your organization. Here's how to get started and get everyone to love them.
A Lightning Talk is a short 5-10 minute presentation on any topic followed by about 5 minutes of open Q&A. A common format for a lightning talk is 6 minutes for presenting and 4 minutes for Q&A. The goal of a lightning talk is always to share knowledge, but can also be to convince people of the benefits of something or to take a particular action. Basically, lightning talks are lightning-fast knowledge sharing.
What's the Benefit?
Ok, so we know what a lightning talk is, but what's the point of doing them? There are plenty of obvious benefits and some that aren't so obvious. The important thing is that everyone who participates, from the speaker to the audience to the organization all benefit. It's an all-around win-win situation.
Share Knowledge
The IT industry is a knowledge industry and the vast majority of us who work in IT are knowledge workers. It's our job to gain, handle, and use information and it's impossible to be an effective knowledge worker without the ability to share that knowledge with others. We all gain insights and learn new things on a regular basis as we work on our projects. It's important that the knowledge gained is passed on to everyone even if they're working on a different part of the project or team.
-
PARA Method
2021-09-07 16:20
A universal system for organizing digital information.[^forte2017]
Projects
Series of tasks linked to a goal, with a deadline
- Complete app mockup, develop project plan, execute business development campaign, write blog post, finalize product specs, attend conference, etc.
- Goal has to be achieved (completely checked off at some point) and has a deadline
Areas
Spheres of activity with a standard to be maintained over time
- Health, finances, professional development, travel, hobbies, friends, apartment, car, productivity, direct reports, product development, writing, etc.
- Standard to be maintained with an indefinite end date
- Areas for me are hierarchical. All projects must belong to an area and all tasks may belong to a project, but must belong to an area.
Resources
Topics and themes of ongoing interest
- Habit formation, project management, transhumanism, coffee, music, gardening, online marketing, SEO, interior design, architecture, note-taking.
- I use resources as my reference manager. For this reason, transient items like projects, areas, and tasks should reference resources and update them with relevant information that comes out of the doing of the item.
-
Development Estimates
A Different Take on a Contentious Practice
2018-10-01 00:00
How to get value from development estimates and why I've learned to love them.
Working as a programmer, I can't count the number of times that I've heard colleagues complaining about development estimates. Some of the complaints are simply grumblings of people who aren't generally cooperative. There's not much you can say to these people to change their minds. Other complaints are valid reasons that a lot of estimates aren't valuable or realistic. Here are 5 common mistakes that I see and what you can do to avoid them.
A Story
Let's start with an all too familiar story.
TechCo needs to develop a new product that will fit in with their offerings.
Jane the manager asks John the developer how long it will take to build the product and how much it will cost.
John says he'll think about it and get back to Jane. The next week during their weekly developers' meeting, John gives Jane an estimate that he thinks is reasonable.
Jane gives John's info to upper management who make a decision to go ahead with the project.
Months later when the project is about to meet its deadline, John, Jane, and upper management realize it's not going to be done on time and start trying to figure out what happened. Upper management puts pressure on Jane to make John finish on time. Jane pushes John hard to finish on time. John ends up finishing on time after putting in an 80 hour week. John is burnt out, Jane is glad to have upper management off her back, and upper management are happy the product went out on time.
-
Tests are not a substitute for types
2022-08-11 22:26
Tests cannot and should not be viewed as a replacement for a type system. Imagine needing to test all function arguments against all permutations of possible variable types in a dynamic language. It's certainly possible, but it's not done in practice and would bloat your test suite immensely. Instead tests should be used to verify the code under test is logically correct and produces the intended outcome.
Tests can never provide an unbroken chain of checks, from the database all the way to the frontend React props, guaranteeing that all of the data has the right shape. Types can't (usually) tell us when we accidentally put a "!" in front of a conditional [emphasis mine]. Focusing on one or the other means sacrificing quality, work efficiency, or both.1
The constraints, invariants, and information encoded in type systems also serve more purposes than just ensuring things like correct usage. They also serve as documentation and communication mechanisms about intent.
Conversely 202208112228 Types are not a substitute for tests. These two systems need to be used together to achieve the best outcome.
-
Bernhardt, G. (2020, April 13). Execute Program. https://www.executeprogram.com/blog/are-tests-necessary-in-typescript ↩
-
-
Timeout Killer
2024-05-05 12:51
Timeouts and Cancellations for Humans
Nice article on the difficulties of actually doing timeouts correctly. And an idea for a malicious endpoint that returns 1 byte every second or so for the same request to keep poorly coded timeouts from triggering.
-
Learning Rust
A Quick Lesson in Ownership
2022-05-15 00:00
I'm learning rust
A note on format
This is a little stream of consciousness post about my experience working through the official intro to rust book. There's not much point to it other than to help me evaluate how I feel working with the language.
Getting going
I started out by installing
rustup, but immediately hit a problem. I already had a version of rust installed on my system. It was an old one installed through homebrew. Nevermind that, I just needed to uninstall the brew version and install a newer one via the recommended approach.Next, I installed
rust-analyzermaking sure to grab the VS Code extension which (at the time of writing this) is the recommended language server even though the RLS extension has many more downloads. There's been some sort of maintenance issue or something. I didn't look into it too much, but this is the community direction right now.I found that
rust-analyzeronly works when you have a wholecargoproject as the root of your workspace in VS Code though. It's a bummer that we can't have non-root rust projects and still get the benefit of the language server and all it's hover/intellisense/type goodies. I think there's a way to make this work with arust-project.jsonfile, but I didn't want to get sidetracked before even getting started. -
Cloud Native Computing
A New Way to Build
2018-08-01 00:00
First Salesforce revolutionized IT with SaaS, then other service platforms extended those ideas for the full stack. Cloud Native Development is here to stay.
Eons ago, people developed enterprise software as standalone packages that were delivered to companies who then painstakingly installed and updated them. Often installation or upgrade projects could take over a year to complete. The software ran on servers that cost hundreds of thousands of dollars and were physically located at the company's headquarters. To the younger readers, I know this is sounding like some sort of nightmarish hellscape, but I promise that it really happened.
Software as a Service
In 1999 at the beginning of recorded history, a man named Marc Benioff founded a company called Salesforce that saw a better way forward. The goal was to provide a better experience and value to their consumers — enter the software as a service model (SaaS). SaaS aimed to improve on enterprise software delivery in a few key areas.
First, it decided on a subscription pricing structure so that customers were only paying for the features they were using. It also lowered the barrier to adoption and let users land on a platform for lower cost. The idea was that after the users landed, the quality of the product and the variety of features would incentivize them to increase their usage and feature adoption on a higher subscription tier.
-
Second-order thinking
2021-10-22 08:53
Second-order thinking is the process of going beyond the immediate impact of a decision or event.
For example, if the USA shifts to renewable energy and electric cars in the 2020s, we'll have no need to be allied with Saudi Arabia anymore. This is a first-order consequence. Going further, we can see that things like a Saudi-Iranian war or general instability in the middle east could come from the dissolution of that alliance. Take it another step — if China and other East Asian cultures aren't able to modernize to renewable energy and electric transport in a similar time-span and the middle east's oil production is destabilized, then their economies could be disrupted. The possibilities in that event are vast and wide-ranging.[^dourado2020]
Here’s the thing about electric cars: they are better than regular cars. They have lower fuel costs. They have fewer moving parts and thus lower maintenance costs. They have higher low-end torque and faster acceleration. If you mainly drive to and from work and have a charger at home, you never have to stop for gas. Electric cars will win because they are better, and the shift will happen suddenly.
A list of specific 202211020929 Second-order thoughts about the 2020s.
-
What React and Kubernetes Teach Us About Resilient Code
A Similarity Among Widely Different Tech
2019-11-15 00:00
A brief intro to control theory and declarative programming
This post was initially published as part of the Beam Engineering Blog here and cross posted here on my blog.
Two Concepts
Here at Beam, we're on a quest to make our technology work for everyone. As part of this quest and as a need stemming from our hyper-growth, my development team is shifting our focus away from feature development toward platform technology and developer experience.
On the infrastructure side, we've been working on a CLI tool for our devs that will let them easily manage infrastructure from the command line. They can spin up entire AWS environments and deploy code from multiple repositories with a single command — no more waiting on other developers for testing and staging environments to be free, and no more inconsistency between production and testing environments. The quest for consistency led us to containerization, and our quest for easy infrastructure management led us to infrastructure as code. Our containers and infrastructure then lead us to a need for better orchestration of those containers. We needed tools that would make the often complex task of deploying, integrating, scaling, and managing services simple and routine — enter Kubernetes.
-
Masonry Layout CSS
2024-04-23 21:22
Help us invent masonry layouts for css grid level 3
I remember getting this working in ~2013 with flexbox columns, but I had to do a complicated interleaving operation to make the sequence correct from left to right then top to bottom. Cool to see this happening finally.
-
Abstractions and future-coding are actively harmful
2022-04-03 10:33
Abstractions and future coding are the single greatest cause of convoluted, complex, unintelligible, inflexible, and unusable code.
“Saving typing” is the most inane excuse for any piece of code to exist. It’s completely divorced from any measure of why that code is good or bad.
Future coding is gambling and dictated by random chance.1
-
Sylvan, S. (2013, August 16). The Perils of Future-Coding [Blog]. A Random Walk Through Geek-Space. https://www.sebastiansylvan.com/post/the-perils-of-future-coding/ ↩
-
-
Architecture Decision Records
2022-04-02 12:18
An Architecture Decision Record (ADR) is a document that captures a decision, including the context of how the decision was made and the consequences of adopting the decision.[^blake2020]
While the name implies that these would be used for mainly architecture level decisions, many people advocate for using them for nearly any decision, no matter how mundane.[^blake2020][^perkins2020] The purpose of recording as much as possible is to facilitate the 202110231449 Externalization of knowledge for software projects and product organizations. (202110231440 Knowledge is the backbone of a product organization)
ADRs are beneficial because they enable persistence and transfer of knowledge. They’re a great example of the 202110231445 The SECI model of organizational knowledge in action. They take 202110231457 Tacit knowledge and transform it into 202110231459 Explicit knowledge
ADRs can be used proactively to propose changes, or retroactively to record decisions that were already made.
My experience with ADRs has been split across two levels of use.
- Organization-wide — Valuable to an extent, but can be used poorly to push things that shouldn’t be approved under the guise of seeking wide consensus. The important thing for these to work are having good, competent coworkers and/or to have people who are not afraid to actively dissent in a widely public forum. They can be an invitation for people to engage in costly bike-shedding or an indispensable log of the collective mind of a group. Which side of this your group falls on is hard to tell and requires some radical candor to identify.
-
Project structure notes should answer a question
2021-07-29 23:12
Ask a question to start a knowledge project. This could be as simple as focusing your interest to an area worth reading, exploring, and adding to the Zettelkasten. Or this could be something as final as the thesis for an article, essay, paper, blog post etc.
Once you have your question to focus your project, answer it with the standard workflow while making sure to do your thinking inside of the structure note for that project.
Conversely, there are good structure notes that are organizational in nature. They implicitly ask the question "what do we know about this topic?" but they are not "project structure notes" as described here. They aren't about a specific project to learn research, learn, or develop ideas.
-
Teams exist for a reason
2021-08-19 10:25
Teams only exist because something needs to be done by that specific team. It's clear from this perspective that 202104291524 Execution is the priority of team management because without execution, we could never be addressing or fulfilling the reason that the team exists.
We could always have a new VP tomorrow - and that the VP's first order of business could be asking, "why do you have so many people here and how do I know they are doing the right thing?"1
It's not sufficient to simply 202106221152 Define success for a team though. It's also important to 202108191029 Measure what you do to ensure that your purpose is truly being fulfilled. It's possible for the team to perform excellently while working on the wrong things.
Another reason that teams exist at all is because 202202011405 Teams abstract individuals over time. Our purpose — our raison d'être — isn't important enough if we don't want to safeguard against its failure through personnel changes.
-
Zalewski, M. (2018, February 24). Getting product security engineering right. Lcamtuf’s Blog. https://lcamtuf.blogspot.com/2018/02/getting-product-security-engineering.html ↩
-
-
The Only Correct Way to Organize Code
A Joking Rant About Keeping Code Neat
2020-09-01 00:00
Why we need a system for code organization and what that system should look like.
Highway to the Danger Zone
Though the pattern is full and it will definitely get me in trouble, I'm going to metaphorically buzz the tower by putting some pretty strong opinions out there today about file naming and code organization. So buckle up Goose, and don't hit that eject button.
First off, file naming. The correct answer here is
kebab-aka-hyphen-casewhich is all lowercase and hyphen delimited. No exceptions, and no, your community standards aren't a good enough reason to change this one as we'll see in a minute. Looking at youComponentName.jsx👀 .Second, code organization. The only correct answer is
folder-by-featureas opposed tofolder-by-random-devs-logicorfolder-by-tech. We'll take an organic trip through all three of these systems and see where we end up.Either of these alone is enough to spark a holy war among devs, but unlike tabs vs spaces, I think there's good enough objective reasons to pick one over the others. Let's take a look.
File Naming
I don't want to spend too much time on this topic because it's much less important to a team of developers than having a consistent system for creating, finding, and maintaining the actual functionality of your product through its source code. Still, you can see how it's in the same vein and deserves an honorable mention.
-
Staff-plus engineer
2022-06-11 22:33
Staff engineering is a complex topic. As nebulous as it can be to get promoted to a 202206112236 Senior engineer role, it’s considerably harder to move into staff-plus roles. Whereas the definition varies a bit from company to company for senior engineering, the definition or even existence of staff-plus roles is completely irregular across the industry. Will Larson wrote an excellent book, Staff Engineer: Leadership Beyond the Management Track[^larson2021staff] on what it means to be a staff-plus engineer. This structure note and its children mostly come from that resource, but also other citations where noted. That book is also (mostly) publicly available at staffeng.com.
[!important] Being a staff engineer is not just a role. It’s the intersection of the role, your behaviors, your impact, and the organization’s recognition of all those things.
The value of the title
- Bypass informal gauges of seniority (especially useful for underrepresented groups)
- Facilitating access to “the room”
- Increase current and career earnings
- Access to interesting work
- Different rather than better
Archetypes
-
Go is not worth it
2024-08-22 09:39
I had to spend a lot of time recently — yet again — debugging weird edge case Go code in production. The person who wrote it had no idea how far off they were from writing something that behaved reliably and correctly. But they're also one of the people who I constantly hear proclaiming how easy it is to use Go, how simple it is, and how productive they are with it. To be fair, they're very productive at churning out bugs. But I'm tired of being on call for it.
This experience triggered me so hard, I almost wrote a whole blog post about how bad Go is. It constantly papers over real world complexity, has a whole arsenal of guns to shoot yourself with, and the people who don't realize that are the ones who love it and make my on-call shifts hell.
I hear the same arguments over and over about "simplicity" in the language that just don't hold up. I really don't understand if I'm just an absolute idiot or if there are loads of developers who don't realize that they're writing half-assed, buggy Go code while thinking it's "so easy and simple".
But honestly, I just couldn’t be bothered to write it all out. I'll never get through to those people. They'll have to learn it for themselves.
-
Sturgeon's Law
2023-12-20 14:32
Ninety percent of everything is crap.[^wikipedia2023sturgeon]
Coined by Theodore Sturgeon in a 1957 edition of Venture Science Fiction, the quote was used in the context of critique. Sturgeon argued that science fiction — which at the time was derided for its low quality — was no different than other genres. He argued that all genres were mostly poor and therefore valid criticism against a genre (or anything really) should be leveled against the best examples of that genre rather than the 90% that's crap.
This is one of the most common problems that I have with modern writing, argumentation, and criticism. Many books, articles, blog posts, etc. level arguments in bad faith against a poor example of how something works in order to advocate for some other thing.
There is a small counterpoint, or perhaps more accurately, footnote to this idea though. It can be valuable for criticism to be leveled against the whole of an idea. For instance, if you focus your criticism against the best 10% of the idea and feel you've come to a conclusion or alternate idea, it can still be valuable to talk about the other 90% as an example of the scope of the downsides. If the worst 90% of my position result in better outcomes than the worst 90% of another position, that's a valuable data point.
-
Prefer duplication over the wrong abstraction
2022-04-26 20:54
Notes from Dan Abramov's talk The Wet Codebase[^abramov2019]
Start with two modules
flowchart BT a((a)) b((b))Abstract
flowchart BT a((a)) b((b)) c((c)) a-->c b-->cAwesome, we’re reusing it and everything. But then something comes along and there’s a slight difference.
flowchart BT a((a)) b((b)) c((c+)) d((d)) a-->c b-->c d-->cbut then there’s bug in
c+that requires a special case forb’s use-case.flowchart BT a((a)) b((b)) c((c+*)) d((d)) a-->c b-->c d-->cAnd then another slightly different one from
aflowchart BT a((a)) b((b)) c((c+**)) d((d)) a-->c b-->c d-->cSo we pull those cases out and parameterize the call sites in
a,b, andd.flowchart BT a_((a_)) a*((a*)) b_((b_)) b*((b*)) c((c+__)) d_((d_)) d*((d*)) a_-->a* a*-->c b_-->b* b*-->c d_-->d* d*-->cLater, after small fixes over time, logging, minor changes, you end up somewhere like this.
flowchart BT a_((a_)) [Continue reading](/notes/202204262054) -
Second-order thoughts about the 2020s
2022-11-02 09:29
Much of these excellent thoughts are from Eli Dourado's great post on the subject.[^dourado2020]
- Bring science to market in order to end 202110220905 The great stagnation.
- mRNA vaccines are amazing. They can be developed quickly and cheaply. There is an HIV/AIDS vaccine in trials and it could be eradicated this decade. There are also "miraculous" treatments for cancer in this vein that aren't true vaccines, but could improve outcomes drastically.
- There are a number of anti-aging techniques coming out that are backed by more credible science than before (therapeutic plasma exchange, aging clocks, other senolytic drugs). Expect people to live longer and healthier by the end of the decade.
- Solar and wind costs were drastically cut in the 2010s and in the 2020s deployment will accelerate. We need a storage price of $20/kWh for a grid powered completely by today's tech. The closest we come is a $542/kWh battery based solution from Tesla.
- Instead of solar and wind we need scalable zero-carbon baseload energy — nuclear or geothermal. Current tech for nuclear targets around 6.5¢/kWh but is delayed until at least 2030. More likely is geothermal which looks to crack 3.5¢/kWh. Not only this but geothermal's drilling advancements mean that even Lockheed Martin's promising compact fusion reactor might not be able to compete if it comes to market this decade. This is because digging the wells this decade means we just have to replace the heat exchange pieces but not re-dig the wells, effectively halving the cost of new wells for the following 15 years, meaning 1¢/kWh energy by the 2050s. Fusion will kill in space though.
-
Stock and flow
2022-05-02 12:52
The fundamental observation of systems thinking is that the links between events are often more subtle than they appear.[^larson2018systems]
Big changes appear to happen in the moment but there is usually a slow accumulation of small changes that lead to that moment.
Static values or accumulations are called stocks. They are how changes are stored over time. Stocks are the elements of the system that you can see, feel, count, or measure at a given time.[^meadows2011]
Changes to the stocks are called flows.[^meadows2011] These are rates of change. They can be inflows or outflows.
System dynamics are the relationships between different stocks and flows. For example, the rate of water pouring into a tub can be less than, equal to, or greater than the rate of water draining from the tub. This system dynamic can result in different long term outcomes like overflowing, equilibrium, or emptying.[^meadows2011]
Keep in mind that stocks take time to change because flows (as units over time) require time to flow. As such stocks often act as delays or buffers in systems. They also produce lag in indication. Additionally, they allow the inflow and outflow rates to be different and temporarily out of balance. This creates feedback processes by which we monitor the inflows and outflows to keep a stock at some acceptable value.[^meadows2011]
-
Knowledge is constructed
2021-09-06 08:35
Constructivism and also Constructionism are theories of knowledge that requires there to be a learner for knowledge to exist. Until someone learns information, connects it to things they already know, and internalizes the information in a personal context, knowledge cannot exist.
Supporting arguments
- Having a text or reference at hand does nothing to increase knowledge, we have to create something, do the work, wrestle with the ideas, and engage effortfully to create our own knowledge.
- Research works better one thing at a time. Find a source, process it to completion, then use your newfound knowledge to find another source. If we don't, we run the risk of picking sources that are useless by the time we get around to reading them. Processing to completion includes writing about what you've read. This is where these notes come in. We take transient notes as we're reading and then write our thoughts here or in drafts of actual writing. (Iterative accumulative approach to writing #thread and writing is important #thread)
- Consider that data patterns and descriptions mean nothing on their own. For instance, strongly correlated but spurious patterns may be obviously meaningless.[^vigen2013] Instead, we require a pattern or description (what), an interpretation of that pattern (why), and — critically — to synthesize multiple interpretations, hypotheses, theories, or models into a bigger picture and create something useful or interesting (why why or higher level why). Patterns and interpretations are the main work of our knowledge management system here. Synthesis happens when we write about (or just read and string together all the knowledge we accumulate in the system).
-
The Art of using a Zettelkasten
2021-07-27 22:42
Using a Zettelkasten is more of an art than a science. It's a personal relationship with an extension of your knowledge. Above all, it's important to just consistently work and think in this system to get the most out of it.
Personal preferences
- 202109091129 Evergreen notes
- 202107272238 When to write a new Zettel
- 202107292312 Project structure notes should answer a question
- 202107292136 The context of a link should give you a reason to follow it
- 202109091133 Notes should associate organically
- 202109091131 Notes should surprise us
- Use a reference manager. The references in the manager should only be ones that have been read and processed, ready to be cited in Zettel as I write them as the last step to processing a source. Don't clutter the reference manager with things I would like to read some day.
- Use a plain text editor and files. This makes everything much more cross-compatible and future proof.
Workflow
There are categories of things that I do regularly, and my Zettelkasten has a specific single place in a broader workflow. It's important to understand how we think and how the processes we use to do that thinking and synthesizing affect your ultimate knowledge (202109080847 As We May Think).
-
Career checkup template
2022-06-12 20:47
Sourced from Will Larson's blog Irrational Exuberance[^larson2022checkup]
This is a simple template for checking in on your career. Here’s how to use it:
- Look through the sections. If there are any sections that don’t resonate with you at all (as opposed to just feeling hard to fill in), then remove or edit them.
- Fill in the sections. Feel free to jump around to answer the parts that you have the most energy for.
- Revisit a few days later: anything you want to change after sleeping on it?
- If possible, find peers or friends to share and discuss each others checkups together.
- Store it away somewhere to review a year from now.
Summary
Write this section last! How would you summarize everything else you wrote below? Try to keep it to max of two paragraphs.
<start writing here!>
How are you feeling about your career right now?
Write a few paragraphs about how you’re feeling about your career right now. Don’t worry about writing this for consumption, focus on finding words that resonate with you!
<start writing here!>
What did you expect / what happened in the last 5 years?
When you think back to five years ago, what did you expect to happen over the following five years? What has happened? How do you feel about the difference between those two?
-
Computer Science
2022-06-19 13:00
The nitty-gritty of computation and technology. Contrasted with 202109061338 Software Engineering which is more about the practice of writing software and careers or organizations in that field.
Curriculum
- 202208101944 Zero to engineer
- 202206282018 Curriculum design for software engineering
- Maybe start here?: MIT OpenCourseWare for Computer Science
- Maybe I should make this yet another structure note that lays out the whole process and what order and how things are connected? Probably just start doing that in this note and maybe split it out later.
Programming language design
- 202107272307 Data-first pipe design
- 202107272306 Data-last pipe design
- Go kind of sucks?
Asynchronous computing
- How does asynchronous stuff really work in JS? Promises, async/await, under the hood etc. #thread answer: JS spec requires implementations of JS to implement an event queue which JS processes fifo. Could be fun to implement a JavaScript runtime in Rust or something. (Might already exist from Mozilla, V8 is written in C++)
-
Software Engineering
2021-09-06 13:38
Maybe this should be a structure note of structure notes only since this is a huge topic that I'd like to really dive deep on. There is also the 202206191300 Computer Science structure note that I’ve split out to dig in to the more technical, theoretical stuff in order to keep this one focused more on the practice of writing software and careers or organizations in this field.
Topics
Documentation
- Co-locate tech docs with the code
- C4 Modeling
Abstraction
- You aren't gonna need it (YAGNI)
- 202204031033 Abstractions and future-coding are actively harmful
- 202204262054 Prefer duplication over the wrong abstraction
- On the spectrum of abstraction[^lou2016]
- Open for extension closed for modification O in SOLID. Means you can add new behavior without modifying any existing code. Always green, always confident in lack of side effects.[^metz2013]
Measurement
- 202304231046 List of SDLC metrics
- 202204272219 The fastest code is no code
- 202109251100 Verify behaviors and assert properties
- Thought experiment. Coding as function, what do the derivative and integral represent? Related to 202107291950 Optimizing requirements and implementations and 202110111901 Run to change ratio of a program.