Author: Chris

While driving back from lunch with a friend the other day, a crazy idea hit me about the nature of day-to-day activities for information workers in the 21st century. I turned to my passenger, who has endured building software with me at two companies thus far, and asked rhetorically “Why do we get up every weekday morning and drive to an arbitrary building filled with desks to practice our craft? What value could this noisy and distracting structure possibly add to the grand scheme of things?”

We don’t build physical widgets, treat sick people, or serve customers in any capacity. We ferry bits and bytes around to where they ought to go and potentially accomplish amazing things on both incredibly small and incredibly large scales. There is no inherent physical nature to either our inputs or outputs. On any given day we might slice and dice more information than the sum of knowledge that previous generations ever imagined – let alone had access to. It isn’t even a remarkable task anymore to pull in petabytes of data, crunch some algorithms over it, and spit out meaningful conclusions in nearly real-time.

What do we even call ourselves? The list of titles I’ve held for essentially the same type of work over the past decade is wildly varied – Engineer, Developer, Programmer, Architect, Tech Lead, Chief Interactions Liaison… (ok I made that last one up.) As a student of Uncle Bob Martin’s wise musings, I’ve decided on “Software Craftsman” as the best way to describe what I do and how I seek to accomplish meaningful results. The Software Craftsmen of the world are a loosely organized guild of creators, inventors, and problem solvers – the likes of which the world of just a generation ago had never seen. We’ve given up on trying to explain to non-technical folks what exactly we do, but know it is our responsibility to educate our fellow non-geeks in the best ways to interact with us so that we can together accomplish great things.

Back to my original point, though. With our varied expertise, breadth and depth, why does it make sense to work for an arbitrary company that just happens to be within a 30 minute drive of where we hang our hat? Sure, there are a laundry list of practical reasons, healthcare, regular income, a steady stream of work, vacation, societal conformity, healthcare again. These outputs are generally associated with spending 45 hours a week at an arbitrary building full of desks, but none of them are inextricably tied to the experience.

In software, we often organize reusable parts into interchangeable abstractions. Traditionally, we might think of a paycheck as an output, but a better abstraction would be a stream of income. A stream of income isn’t necessarily a check addressed to John Q. Developer that arrives like clockwork on the 1st and 15th (unless you work at a startup, where sometimes it doesn’t arrive at all). We could structure a stream that arrives in a less granular way where income arrives based on the successful completion and delivery of a product or project. We could implement a SaaS model in which the stream of income arrives only based on who is subscribing to the software currently.

The duplicate mention of healthcare was no error at all, especially in America where we spend more than all other developed nations on healthcare and have the poorest results. The cost of healthcare obtained outside of a traditional employer will cost you more than the mortgage on a nice three bedroom house. That’s worth repeating to yourself quietly as you realize this cost will also increase much faster than inflation. While worthy of its own series of blog posts, this is a reality that supports and furthers the 20th century giant-corp employment model.

While having a steady stream of work might seem to be a tall order in other industries, just browsing the myriad open source software projects being actively developed on Github puts that notion to bed right away. If you get bored in this industry, it’s your own damn fault. Connecting this stream of work to a stream of income is a trickier task, and often involves skills that are highly irregular to pure technologist. My advice to technical folks is to partner with someone with business savvy, as it is nearly impossible to play both sides of this coin effectively.

Vacations are what you make of them. I’ve spent what should have been a weekend at the beach, instead sitting in the trenches at a keyboard & cases of red bull with fellow Software Craftsmen sliding sideways across the v1.0 finish line with our hair on fire. To me, that feeling accomplishment from shipping high quality software is tantamount to any weekend at the beach. I’d trade a weekend of R&R at an all-inclusive resort for an all-night Hackathon pretty much any day of the week. That’s not to say I don’t disconnect from all things electronic on a regular basis. My wife and I have spent the past couple of years rebuilding my Grandfather’s “Walden cabin” on a river in the mountains of southern Virginia where there is no internet access or even cell phone access at all. Unplug regularly to recharge, you ironic human.

In the coming decade, I expect we’ll see a different kind of outsourcing than we’ve ever seen. We’ll see folks in the IT industry outsourcing themselves, building abstractions between the traditional brick & mortar employer and themselves. This transition may not be completely unlike the shift from brick and mortar shopping to an electronic marketplace of work. This new landscape excites me, and I look forward to the efficiencies and freedoms these new abstractions will bring. We’ll be able to form loose connections with experts in our network and reconnect as needed to continuously accomplish meaningful work.

Reading an article from a former colleague, Proliferation of Depencencies got me thinking about how we manage dependencies today. There are inherent risks to blindly taking on a dependency to solve a single point need.

source: https://lastlog.de

The tendency toward adding a dependency rather than writing code seems to be accelerating, at least from my observations.

The recent snafu with npm is a good example of how dependencies can be a risk. When Azer Koçulu removed all his npm modules, thousands of applications were suddenly unable to build. A situation that never should have happened due to namespacing, curation, and thoughtful dependency taking, it was a wake-up call to the node community. Many projects were dependent on a single package ‘left-pad’ that was only a couple of lines of code.

Taking a dependency on someone else’s code that isn’t part of a core language framework, especially for 3-4 lines of code, is an unnecessary risk. Alternatives to consider are to write the code directly into your project, or fork the dependency you’re considering taking.

The broader consideration is around how to curate an ecosystem such as npm. Languages and code bases with a benevolent overlord such as the Linux kernel, Microsoft’s .NET CLR, or Google’s Go have the benefit of a tie-breaking entity to minimize dependency sprawl. OSS projects without a strong advisory and curation group have a higher risk of dependency sprawl.

While a Swiss Army knife solves problems, a Swiss army chainsaw can make a mess.