A few years back, I presented on a topic near and dear to my heart: software abstractions.
I think it is critically important to take a pragmatic and critical view of software abstractions and I feel this well represents my views. I hope you enjoy this as much as I did sharing it with the wonderful audience at CraftConf.
I haven’t talked much publicly about libmtev, but I think it might be about time to start. The C programming language isn’t going to die anytime soon and it has some distinct performance over some of the more populate emerging languages: the compilers are the most mature and there is no garbage collection{% sidebar-link gc %} (so no GC pauses). Alas, this isn’t about C as a language, but about the library that I started (within another project) in 2007.
Open plan offices are bad. Breaking my concentration is wasteful. You hired me to code, so don’t interrupt me. I keep reading statements like this and feel compelled to supply a counterpoint. It isn’t that these are lies, it is that the are immature perspectives on a complex set of circumstances that clearly only represent a certain type of coder. In fact, I’ll claim that “coder” is either junior or selfish or both: immature.
Defining the term: I recently used a term and was hit with a lot of out-of-band requests for explanation. It’s a good one and excellent food for thought.
ywahusty (yuh-wuh-hus-tee): you will always have users smarter than you.
This basic concept is one of sound, pragmatic systems engineering that might appear to fly in the face of traditional product engineering… but doesn’t.
In traditional product engineering, there is a goal to produce a product that is both accessible and useful to the largest subset of the predefined audience of the product.
