Posts filed under 'technology'
One of my understated goals is to transform ideas I've written down from single-sentence entries in a notepad somewhere into something a bit more robust and shareable. While sorting through Bear notes today, I found one idea that I feel I can expand on in short order.
Ticks are fascinating and terrifying creatures. They have one overall motive—to suck blood—and they are singleminded in that pursuit.
In the Army we went into the Kentucky backwoods for a group land navigation course, and during a break for lunch (happily, away from the Drill Sergeants) my battle buddies and I stopped for a tick check. One of our guys—Palmer—found a tick on the back of his arm, in a place that had been covered by his blouse sleeve, and spent the next five minutes freaking out as we attempted to get it off him.
By this late point in our training cycle, our DS allowed us to purchase and carry multitools, and having eaten MREs we had matches on hand. So, remembering the old wisdom about tick removal, we tried heating up a knife blade and putting it on the underside of the tick to get it to release. Between curses and shaking his arm, Palmer informed us that all we had accomplished was burning him. So, we got more aggressive: one of our knives had a pair of tweezers, and we used those to wrench the nasty creature out of his skin. After several attempts, we got the tick out, and (to the best of my knowledge) Palmer was shaken but otherwise okay.
The mere existence of ticks is enough to make me want to have nothing to do with them. If they bit and moved on, like mosquitos, I might tolerate them more. But they bite, and they suck your blood, and they spread diseases like Lyme—which is often misdiagnosed for years, and causes remarkable neurological effects—and can even cause you to become permanently allergic to meat. Seeking to avoid these effects, any time I go into the backwoods or anywhere that has a chance of having ticks, I spent ten minutes with a mirror fastidiously checking every part of my body for ticks. So far, I've been lucky.
However, in their quest for blood, they have pursued me. In 2013, I visited my dad in State College, PA, and together we traveled to Gettysburg to see the battlefield in person. There's a little trail on the east side of the battlefield, a little south of the Union artillery emplacements, that's mostly meant for horses and small vehicles. On a lark, my dad and I began to walk down this trail (consisting mostly of dirt and tall grass) when something—the twitch of a hair, a stir of breeze—prompted me to glance down at my legs.
You have to realize that since Iraq, and the Internet, I'm absolutely paranoid about parasites. So when I saw this little… <expletive> punaise1 crawling among the hairs on my leg, I about lost it. Imagine: here I am, a 230+ lb person, cursing up a storm while trying his damnedest to swat a tick off his legs, while the little bugger is holding on for dear life. It hadn't even bit into me, and already it had a firm grasp.
Now, the internet says that ticks can't jump, but I'm pretty sure I didn't brush any grass while we were walking up that path. Perhaps it got on board the Peter train much earlier, when we were walking out on the battlefield, and I only noticed it once it got higher up and the difference in feeling on my leg hairs clued me into its presence. No matter how it got there, though, I was pretty sure I managed to swat it off, and, not wanting to risk any further encounters, we turned back.
Well, wouldn't you know it, not ten minutes later I found another one (or perhaps the original was more tenacious than I thought). Just as profanely but much more focused, I got rid of this one, and promptly tied my shorts2 as far down my legs as they would go. Crisis averted, we spent a few more hours wandering the battlefield before hopping back in the car to return to the hotel. I spent a chuck of the ride back that night telling my dad (who was apparently uninformed) about the dangers of ticks and Lyme, and encouraging him to check himself.
All this is to say that ticks are very good at what they (try) to do. But there's another, more salient point that I want to bring home. There's a reason health professionals no longer recommend people use the "hot knife" method to remove ticks (other than the risk of burning your battle buddy), and further a reason they recommend you use shard tweezers and grab as far down the tick as possible when removing it.
You see, ticks aren't optimized for letting go; they're optimized for hanging on for dear life. Ticks that let go don't breed. Burning a tick can cause it to vomit into the bloodstream, increasing the risk of catching any diseases they carry, and failing to grab a tick far down its head can cause the head to break off while drinking. The head might not get the message that the body is no longer there, and continue 'drinking' well after it should be dead (again, raising the risk of infection).
Why don't ticks evolve to have a stronger connection between their heads and their bodies? Well, first of all, that's not how evolution works; they have to work in large part with the pieces they have. But, more importantly, a stronger neck is a cost without a direct benefit to the singleminded purpose of hanging on for dear life. A tick with a strong neck might have a better chance of surviving separation from the host, but a tick that risks getting separated from the host at all is a bad tick.
High ROI, from a tick's perspective, comes from a) skill in finding a host b) escaping detection while they seek a good feeding spot c) hanging on while feeding d) escaping to lay eggs. None of these criteria is improved by surviving removal, because when one tick dies, there are many ready to take its place.
If we view design, or business, as a competitive environment like nature, we can see parallels: there isn't much potential ROI from being a "careful" company, to insure against unlikely scenarios. The most successful configurations are those that are singleminded in their pursuit of survival, avoiding the risk of removal in the first place. Your survival chances are dictated not by how "good" a company you are, but rather how dogged you are in pursuing a single goal, and if someone comes along and cuts your company off at the head… that's just business.
I've just started to read Corman's Algorithms, and in the first chapter a thought occurred to me.
There was a recent post about how inter-connected the Facebook codebase is. First of all, I found it quite surprising how much code there is, but I assume a good chunk of it is for scalability, which is certainly important (it's basically a mystery to me how facebook works at all, given that there's no way their user database can exist as a single object on a single machine).
However, thinking further, and thinking about the sorts of companies I see out there, it seems like there are a lot of people solving the same kinds of problems. And between one thing and another, I started wondering: how much of this is because our languages for expressing common problems haven't matured?
There's a cap on median engineer intelligence (it doesn't really matter what this means, but for the sake of argument, let's say the median engineer working in web technologies has an IQ no higher than 130, or two sigma above the population). Engineers are in a weird spot inasmuch as they work in one of the few industries where your job is very similar to your training and tool-building. A teacher can take classes on being a better teacher, and make resources to make teaching better and easier, but at the end of the day if they don't get in front of a classroom, they're not doing their job.
An engineer, on the other hand, can write a framework to make their work easier, learn (or create) a domain-specific language to speed up one aspect of their job that's repetitive, and at the end of the day have in hand new knowledge, work that pays the bills, and a tool they can release for other developers to use. This probably goes a long way in explaining the galapagosation of technologies, especially web technologies.
At some point, the learning curve of understanding how everything goes together becomes too challenging. Thus, our median engineer can't get much more efficient, because there are too many things to keep track of, and too many things that can break, and he wants to understand his toolchain and not look a fool because he can't tell his boss why the database got borked.
The thing is, we already have specialists (Database Engineers, SysAdmins, Front-end, Back-end, Project Engineers, the list goes on), and the role of "DevOps" kind of papers over the fact that at some scale, a company should be concerned with differentiation of responsibilities. All engineers should have some idea of how their work might affect other domains, but the job of optimization should lie in the hands of experts. (Note here Conway's Law, which states that "organizations which design systems … are constrained to produce designs which are copies of the communication structures of these organizations".)
Is it possible to make a framework which would make engineers more productive, and capable of expressing higher-order concepts without having to worry about the entire stack?
The original "killer app" on Facebook was (probably) checking out the pictures of cute girls in your classes, and bragging about your awesomeness in an attempt to improve social standing, and not much has changed. They leverage more aspects of homo now, ten years on—the desire to be informed, the desire to feel social without the costs—but these things depend on the network that was bootstrapped via "cool, attractive young people".
And yes, I'm being a bit glib, but the problems that Facebook solves in interesting ways mostly center around speed, availability, scale, and presentation. The CRUD core is kind of… boring?
The company that eats Amazon's lunch, by contrast, will make it easier to actually shop, and not just find something close. This is presentation and filtering layer technology, and Amazon's existence hasn't shut the door on other online marketplaces the way Facebook has largely supplanted all other entrants to vanilla social networking.
Amazon's power has come, in turn, from its infrastructure and its internal APIs. Most engineers, when they hear "Amazon" now, will think more naturally of AWS than of the original online bookseller. Sure, Amazon will always mean books on some level, but they drive so. much. of the web that I wouldn't be surprised if that becomes their core business (just like I joke about Google becoming primarily a car manufacturer).
[A funny sidenote: how many online stores, I wonder, are running on AWS on the backend? Amazon is pretty content-agnostic, even when the instances they're hosting would compete with their original niche.]
Meanwhile, technology stacks are maturing—
capistranofor server management,
dockerfor deployment—thus freeing engineers from having to roll their own, so to speak. Interesting companies are getting more meta (sidenote: I really need to play with SquareSpace to see what they enable people to do… but it's possible that they'll kill the indie web dev)… and I don't actually know what the engineers are doing at the rest of these companies? Is it all just gluing frameworks together, whiling away time until the company is aquihired?
And there's something empowering to playing the "Full Stack Engineer" game as long as you can. Outside Project Management, FSEs are among the few who can say they're able to realize a vision, which the parts-and-glue, division-of-labor engineers probably can't.
Other than inertia, then, I suspect a primary reason this industry hasn't settled on a single stack is because as long as there's capital flowing, people are having fun at work—and occasionally making money doing so. If software engineers collectively decided they wanted to change the world in a more meaningful way, they certainly could (or at least could make a good stab at it). However, at that point, the majority of the industry would be consigning themselves to grunt work, the sort of work that mostly appeals to milquetoast personalities with pocket protectors, and late-career people with families and hobbies.
A business idea, then, would be "do whatever would make software engineering boring, the fastest, for the most people". That would pull the rug out from under the entire field for a while, though, until the middle-road engineers could figure out a way to build on top of this new stack and have fun doing so.