i-got-lucky.com Just thought of creating i-got-lucky.com, where successful people could describe how it wasn’t just their virtues that gave them success. They could describe how much sheer luck mattered. It might be useful because an amazing number of people don’t believe luck played a part in their success.
More on the definition of "boundary object" The very first episode of Oddly Influenced was about Star & Griesemer's idea of "boundary objects." That's proven to be a fairly hard concept to pin down, and I did at best an average job. Fortunately, I'm rereading Étienne Wenger's
Tinkerable software and Mastodon More than 20 years ago, I wrote an editorial proposing what I called tinkerable software. We expect houses to be tinkerable: ordinary people, not the original builders, can modify them in both small and large ways. Even those who don't want to tinker expect tinkerability from physical products.
Mastodon, quote boosts, dread, and the science fiction of A. Bertram Chandler (The above is what's called, in Mastodon land, a "CW", which used to mean "content warning" but is now often referred to as a "content wrapper": i.e., the subject line. You have been warned, or wrapped, about what I will now
Bricolage This is an addendum to podcast episode 20 on Orr's Talking About Machines, about copier repair technicians. Orr uses Levi-Strauss's idea of "bricolage" as a way of talking about what makes a good copier repair tech. Broadly, bricolage is the process of rummaging through
Two lessons from learning to fly gliders Many years ago, I learned to fly gliders (sailplanes, airplanes but without the complicated engine bits). I learned two contradictory lessons that have stayed with me. Don't just do something, sit there Since gliders don't have engines, something has to pull them into the air. Probably
Scientific peer review compared to pull request peer review @Migueldeicaza pointed to an article titled "The rise and fall of peer review", which argues that the current method of scientific peer review is relatively recent (it only became common in the 1960s) and hasn't worked out. The problems are fairly well-known: peer review takes a
Addendum to "What got left out of software patterns" In response to "What got left out of software design patterns," Joel Tosi asked what Alexander got wrong in Notes on the Synthesis of Form. To answer, I think it worthwhile to quote Alexander's "Preface to the paperback edition" in full. All emphasis is
What got left out of software design patterns For some years around the early '90s, I was a regular attendee in Ralph Johnson's software reading group. As such, I had a ringside seat to the development of design patterns. We read and discussed at least selections of the three seminal books by architect Christopher Alexander,
Cross-discipline education: a question based on copier repair techs and copier users In Orr's ethnography of photocopier repair techs (https://www.goodreads.com/book/show/20081966-talking-about-machines), he discusses how techs have to educate copier users to produce good bug reports - that is, descriptions of problems useful to the techs in diagnosing the underlying problem. I'm way out
What if legibility/formalism is not the driver Scott and I think it is? In episode 17 and episode 18, I discuss Scott's Seeing Like a State: How Certain Schemes to Improve the Human Condition Have Failed. Scott puts a lot of the blame on people's love of formalized systems (and the closely related concept of "legibility"). Fair
Scrum vs. XP: what if Scrum was right? (sort of) So here's a question. As an XP person, my consulting leaned into saying people should for real try all of XP for a while before passing judgment. I think that was fairly common, back in the day. The Scrum approach was different in two ways. First, they were
A wiki for odd influences on software practice Abstract There's a big set of non-software books that have inspired software people to change the way they develop software. Sometimes those changes have rippled out to many other developers. But the effects are second-order: people adopt changes in practice without knowing the odd influences that inspired them.
macros The How of Macros 5: Unquoting As you now know [https://www.crustofcode.com/how4/], quote descends the syntax tree that is its argument and converts it into code that will, when executed, build the original syntax tree. quote is usually not useful unless the tree contains unquote or unquote_splicing nodes. This post explains how
macros The How of Macros 4: `quote` When the Elixir parser sees quote do: content, it produces a 3-tuple of the form {:quote, metadata, [[do: content]]}. Marick takes a deep breath. :quote is a special form that takes the abstract syntax tree content (which represents Elixir code) and turns it into an abstract syntax tree for literal
macros The How of Macros 3: Syntax trees for literal data The previous post showed how code is represented as syntax trees. This one shows how literal data like %{a: 3} are represented.
compilation The How of Macros 2: Syntax trees The last post looked mainly at the different binding maps that are created and used during bytecode generation. This post looks at the syntax trees that are parsed from Elixir text, then delivered to the bytecode generator.
elixir The How of Macros 1: Elixir compilation As Abraham Lincoln did not say: those who like this sort of thing (details of programming language implementation) will find this the sort of thing they like.
macros Macrofunology 4: atoms and function names Because previous posts looked at function-defining macros that supported the same structure as def, they could ignore the difference between names and atoms. This post will discuss cases where the difference matters. TL;DR: When creating a function name from an explicit :atom, make sure you provide a parenthesized argument
macros Macrofunology 3: guard expressions The gotcha: in quoted text, guards wrap the head (function name and arglist), so they require special-case code.
macros Macrofunology 2: wrapping bodies, dissecting arglists Any def contains a head (the function's name and argument list) and a body (what comes after the do). This post shows how to build a macro that takes the same structure but uses a part of the argument list to wrap code around the body. That is,
macros Macrofunology 1: module structure This series of posts is about macros that expand into Elixir def expressions. That is, they expand into definitions of functions that get "attached" to a containing module. Such macros are not wildly more complicated than normal Elixir macros, but there are some subtleties and some gotchas. This
testing Custom assertions with ExUnit Any unit testing library makes it easy to build your own custom assertions on top of the base assertions: just write functions. Often, though, you lose important information like appropriate line numbers, output that highlights structure differences, and so on. ExUnit makes it fairly easy to keep those, but you
testing Code for comparing TDD to Property-Based Testing Hillel Wayne [https://twitter.com/hillelogram/] gave an example problem [https://gist.github.com/hwayne/e5a65b48ab50a2285de47cfc11fc955f]. The idea, as I understood it, was for people to solve it via property-based testing (PBT) or test-driven design and see what the differences were. In particular, I'm interested whether I missed
testing Tabular tests in Elixir I recently read Aleksandr Skobelev [https://twitter.com/ilowry]'s nice "Fundamentals of Optimal Code Style." [https://optimal-codestyle.github.io/] I like that he uses principles of human perception – how the eye tracks things, how humans read – to produce his suggestions for style. And I especially like