19 KiB
| title | date | tags |
|---|---|---|
| 2023 Wrap Up - Articles | 2024-01-01T15:31:18-08:00 | [end-of-year-wrapups productivity SDLC] |
Stand-outs among articles I read this year - abandoning the table layout from last year in favour of readability.
If you just want the best-of-the-best, I recommend The Categories Were Made For Man, Not Man For The Categories, Many More Much Smaller Steps, and Five Geek Social Fallacies (with an honourable mention for Should You Split That File if you are a software engineer - the others are of general interest, even though MMMSS focuses on engineering)
Theory-building and why employee churn is lethal to software companies
(HN)
Software Development is not just the act of writing code (we knew that!), but the creation of an accurate and up-to-date mental model of the system - a model which is useful for understanding how to alter that system in response to desired changes. Corollaries are that deep understanding of the context and intention of a system is essential, that team churn is catastrophic, and rewrites-for-the-sake-of-rewrites are less self-indulgent than they may seem, as they (re-)generate this familiarity.
I'm reminded of the surprising (but correct!) claim that it's preferable to have a broken-but-easy-to-change system, than a working-but-hard-to-change one. Firstly, the system may actually be broken without you knowing; secondly, even if it is working perfectly now, requirements may change tomorrow. This article is also particularly relevant in the context of my team's work to establish ownership (which includes "understanding of the subject") of systems at work.
Velocity defeats itself. Get acceleration instead
(HN)
Do not neglect software engineering work which reduces the friction of development or experimentation
Hardly a novel perspective, but I liked this way of phrasing it, especially since it stresses the hard-upper-limit of "force" as an input to acceleration.
The Categories Were Made For Man, Not Man For The Categories
Starts off with a good abstract exploration of how categories should be created so as to be useful, but are neither authoritative/immutable nor inherently matters of fact; moves on to apply that, sensibly, to transgender identity.
I was very cautious of reading anything from the EA/Rationalist space, especially anything related to gender identity, as they have a certain reputation - but surprisingly this piece prioritized harm-reduction over the mastubatory satisfaction of retroactively declaring one's prejudices as "supported by science"
Social Justice and Words, Words, Words
A discussion of how the same terms can be used by the same person to mean different things - often with the outcome (intentional or not) that an indefensible claim can be made defensible by "retreating" to an alternative definition when challenged.
Another Rationalist article - this one a little less sympathetic, but certainly not inconsistent or obviously-wrong. I will say that his experience of Social Justice appears to have been more hostile than mine, but I also 100% believe that such people/experiences exist. Certainly, it's not a stretch to believe that some SJ folks take good intentions to harmful extremes, or subscribe to absolutist philosophies which admit no nuance.
This ties into a theme I've noticed recently, of disagreements persisting not because of differing views, but differing definitions of the terms being used in the argument. If I say "X isn't racist", and you and I have differing definitions of what "racist" means, we're going to struggle to make progress in understanding until we discover that mismatch. Along the way, we'll be hampered in reaching that understanding if there are value judgements associated with many of these differingly-defined terms - if you think you're hearing me say "I see the harm being done by X, but I don't care about it", when what I really mean is "I recognize the harm that X does, but that harm doesn't fall under the category of 'racism'", then our discussion will be fraught!
Of Dogs And Lizards: A Parable Of Privilege
A straightforward description (linked from the preceding article) of how Privilege arises through differing experiences/backgrounds, and how to react to that. I am a big fan of social justice proponents (hmm, we're overdue a new term for that, aren't we?) who prioritize spreading understanding and education rather than criticism and shame - famously poor recruitment tools. In my opinion very few people (not zero!) are deliberately or actively cruel, but many are either lazy or small-minded. In an ideal world, people would "do the right thing" simply because it's right, not just because you tell them how their patterns could harm people they care about - but, since we don't live in an ideal world, it's sensible to consider prioritizing harm-reduction over ideological purity1.
Communicating Like A Grown-Up
(HN Link) For a while, I have been convinced that clear written communication is one of the greatest superpowers that a human can possess. It is the best way we have to disseminate and preserve information; and while it may take more effort to write a persistent long-form piece than to make a convincing verbal argument, that effort will be justified by the ability to share and refer-to the durable copy, and by the higher-quality thinking generated by an inability to hide behind easy speech. In fact, a determination to improve my own writing was one of the primary motivators for this blog in the first place.
Plenty of good advice in this piece. A consistent theme I want to pull out is that, in any collaboration, we should always be of the mindset that we're all doing out best and pulling in the same direction. Assuming ill intent or stupidity is never a useful strategy - whether you're right or wrong, you will have made an enemy, and if you're wrong you'll make yourself look foolish. Much better to assume that information has not been fully distributed, or that incentives are misaligned - approaches which gracefully allow your collaborator to change their position without admitting defeat. In all cases, prioritize finding the best outcome for the team, not "winning".
The Copenhagen Interpretation Of Ethics
(Archive.org link because the original is no longer available) "The Copenhagen Interpretation of Ethics says that when you observe or interact with a problem in any way, you can be blamed for it. At the very least, you are to blame for not doing more."
This is a really interesting one. Prima facie, this interpretation seems to be nonsense - we should celebrate any amount of improvement or amelioration of a problem, even if the response doesn't completely fix the problem (so long as the "improvement" doesn't push someone into a local maximum from which it would be hard to escape to genuine long-term betterment). And yet, all the examples that the article gives of the phenomenon - of organizations taking steps which provide limited-but-non-zero assistance, with zero downside - feel, for want of a better word, "icky".
You could argue that the first example (paying homeless people to carry Wifi equipment) did have a downside in that it was dehumanizing to the participants, but, well...they're free to reject the offer if they (justifiably!) value their pride more than the associated payment. Sure, consent cannot be freely given when under duress, and you could argue that a homeless or otherwise-needy person isn't able to express their economic preferences accurately when offered compensation that would (however temporarily) stave off hardship2 - that is, that they're compelled to accept an offer which they would otherwise refuse - but, the Wifi-providing company isn't the one responsible for that person's hardship or for the existence of poverty, so why should they be condemned for offering a choice wherein the negative option is "remain in the situation you would be in if this choice wasn't offered"?
As I say, an interesting one - something I don't have a well-defined attitude to, yet, but that I do at least want to keep in mind in the future.
(Also, "Philosophy Bro" is just delightful)
The Seven Ur-Programming Languages
(HN Link) I have been fascinated with the different properties and priorities of Programming Languages since reading "Seven Languages In Seven Weeks" a few years ago. This was a fascinating read on some alternative perspectives on PL design.
(I still don't grok Lisps, though 😅 I can recognize that they are elegant and concise and all that good stuff, but the "Summer of Sexps" was one of the more frustrating months of Exercism's 12in23 challenge. I just missed named variables too much!)
Many More Much Smaller Steps
(First read a while ago, but I neglected to note it down at the time)
In my previous role, I half-jokingly compiled a Wiki page of short general-purpose statements which one could use to simulate me as a chatbot - randomly selecting one of the statements as a response in a conversation would do a good job of impersonating me. Manual Work Is A Bug and Code Only Says What It Does were among the list, and this article belongs alongside them.
(Honourable mention to Choose Boring Technology, which is referenced a little later as well)
Make It Easy To Do The Right Thing
The title is a mantra of mine - particularly since I've moved to an SRE role - and the article provides some good examples of the concept.
Five Geek Social Fallacies
A collection of social dysfunctions that geeks susceptible to, most likely due to a some combination of a. a history of being ostracized, and b. finding socializing unintuitive and thus trying to "learn" it as a skill.
One of those articles that, once you read it, you will notice the tendencies and patterns everywhere (probably including, uncomfortably, in your own past behaviour).
How Do You Keep Us Innovative? I Don't
An alternative view on Choose Boring Technology. It is a fallacy common to junior engineers to think that engineers are in the business of writing code, and that writing cool/efficient/modern/clean/exciting (delete as appropriate) code is what they are paid for. This is not the case. Engineers are paid to solve problems. If you can solve the problem well (and sutainably) with a few lines of hacky bash scripting rather than an elegant multifaceted framework-y masterpiece, that is perfectly acceptable - and often optimal. Newer tools are, by-definition, less-proven than the battle-tested dinosaurs - they represent risk. That risk must be outweighed by significant power or functionality elsewhere.
(An second-order effect is that using newer flashier technologies might be a positive recruiting consideration, but I suspect that that effect is negligible except in areas which are themselves cutting-edge - AI, Self-driving, etc.)
Should You Split That File?
(HN Link) A neat approach for code organization, sensibly balancing the competing pressures when developing code and considering the cognitive-load aspects inherent in them. I am a sucker for solutions which identify a spectrum of solutions which lie along some line of trade-offs, and which then ask "what if we could take some of the best of both worlds"? (Yes, I'm still trying to learn Rust 😝)
I do think it's interesting to note how some comments argue in favour of larger files because they allow for (say) searching within a single file in a single operation, when "searching across a whole project" is a single operation in well-set-up IDEs (fight me, Vimsters). This feels like a local maximum - to what should we keep using sub-optimal practices because the optimal practice is sub-optimal to those using sub-optimal tools?3
Bonus points because the HN comments include this classic form-of-comment: 1, 2.
Others
Articles that I thought were worth recording at the time, but which I didn't think warranted a paragraph-length write-up above. The snippets are not (usually) direct quotes but rather are my summations.
- How To Do Hard Things (HN) - A blend of mindfulness meditation (awareness of thoughts and aversion, recognition that thoughts are real but not necessarily true, center yourself in the present and the body, etc.) and therapy/productivity theory (let actions arise from values, form habits with routine).
- Everything Is A Practice (HN) - "You are what you repeatedly do. Do things that lead you down a path you want to be on. Don't neglect a diversity of skills." (not a new realization!)
- Systems Design: What We Hope We Know (HN) - "Engineering as a discipline of compromise (Science as a discipline of mechanistic testing of inspired hypotheses), Insight as a new-to-you realization, latency vs. throughput"
- Resisting Deterministic Thinking - "Outcome are almost never certain - pick the choice that best shapes the probability-space to your desired outcomes." (shared by George)
- We Don't Trade With Ants (HN) - an interesting take on how Human/AI relations might evolve
- The JavaScript Gom Jabbar (HN) - shudder
- Consider SQLite, via How I Run My Servers. Reminiscent of a great talk by David Crenshaw on the topic of ruthlessly prioritizing simple functionality in your tools - though, to be clear, I still find GoLang to be an extraordinarily-frictiony language for no apparent good reason (unlike Rust, for instance, which is also incredibly-frictiony but with the friction intentionally introduced with deliberate trade-offs)
- Don't Mess With A Genius - fun historical story about Isaac Newton's time as Master Of The Mint.
- Shamir Secret Sharing - an engineering war story
- That Time I Built Excel For Uber And They Ditched It Like A Week After Launch (HN) - "Every piece of code you write as an engineer is legacy code. Maybe not right now, but it will be. Someone will take joy in ripping it out someday." - plus a cool tidbit of how Excel works (read and find out!)
- Doing A Job - an exploration of the idea of ownership of (loosely - pride and competency in) a role.
-
though even this straightforward formulation can be fraught, as it leans close to an oft-maligned claim that it is the responsibility of the oppressed to educate their oppressors, and to do so in conciliatory and flattering ways - an unreasonable ask, when the oppressed are so often dealing with plenty of other exhausting hardships and trauma. I have a longer blog post planned on this general idea; but in short, this seems like an instance of a special case of "miscommunication via differing definition" - explicitly, the miscommunication which arises when making a normative statement (an expression of desirability - "you should do X" or "it's a good idea to do X") without expressing the criteria used for judgement. If your aim is to change the behaviours of your listeners, then a position which castigates them is less likely to be successful than one which explains to them the benefits of the change - but a victim has, in fact, no responsibility to try to directly effect that change, and not all their speech should be judged through that lens. Their speech might be intended simply to vent, or to build community with other victims, or to effect change indirectly by changing the opinion of large demographics or of policy-makers which will put pressure on their oppressors. ↩︎
-
In a broader sense, neither can anyone in a capitalist society outside of the 1% - but that's a whole tangent... ↩︎
-
FWIW, I'm sure that Vim could be set up to do "Project Search" just as well as IntelliJ/VS Code/whatever could do. Rest assured, if I'm talking about "Vim as a substandard IDE", then I'm not talking about your setup 😝 ↩︎