I’m writing this post at the end of a particularly odd week in terms of things going wrong. And this is the type of post that you write with fingers crossed, praying that you don’t have to come back later and update something because the universe decided you shouldn’t open your big fat mouth.
I’ve already done that once today:
For as long as I’ve been in a technology, you’d think that stuff catching fire would roll off my back by now, but the truth is the anxiety of things breaking never really goes away. In reality, it really only seems to escalate the closer and closer you get to the source. It’s easy to say “Sorry, but it looks like that service is down. Our partner is working on it,” but much harder to do when you literally manage the server that is down or you wrote the thing that is broken.
There is a ton of flowery idealism about working in the coding profession nowadays, which is definitely justified. I spend most of my days, even in spite of weeks like this one, engaged in some of the most thoughtful and creative discussions on a daily basis with tons of smart people. But there is certainly a deeper truth that underlies all of the positives:
Software development is hard.
The rest of this post will be a thought provoking, and hopefully humor inducing, look at some of the things that make this type of work hard when it gets hard.
The Pace of Change is Blistering
We all know that technology changes at a rapid pace, but I would argue that the tool belt the modern web developer uses to create the products most consumers think of as groundbreaking changes at twice the speed. It has gotten to the point that some pieces of tech experience their full life cycle before your very eyes. Something will be born, live, and then die all before you’ve shipped a large project.
While this is something that has been talked about extensively in the JavaScript community, it is also a huge barrier to getting new people into the field and is disincentive to learn most tools deeply for fear they will become obsolete before we can use them effectively.
At the end of the day, a lot of these tools are interchangeable and there is some amount of carryover, but it still leaves us feeling whiplashed.
We are Writing for Humans, not Computers
This is perhaps the single biggest lesson I learn over and over again, and it becomes more important as your projects consume and interact with other people’s projects. So you need to be acutely aware of this dynamic as you develop projects for open release or when you use, modify, or maintain the work of others.
When you are writing a plugin or library, try to think about the things that other people in the course of day-to-day will do that could clash with your code.
In other words, if people are very likely to use the variable $index when writing their own programs, try to make your code more resilient and use a variable name specific to the context.
Like humans working any other job, sometimes things don’t make sense, aren’t well documented, or are just plain overlooked in the course of accomplishing some other, more important objective.
It’s very easy to leave a Google Maps API Key tied to your email in a production system at an old job that chugs away for months until someone catches it.
It’s very easy to assume something that works and make sense to you now will do so 6 months from now to yourself or other people.
It’s hard sometimes to get to a level of understanding about the situation that allows us to accept these inevitable miscommunications and trust the other developers who make our lives easier on daily basis, in one way or another.
// ¯\_(ツ)_/¯ Dont you dare delete this comment for it is magic
Creating Sustainable Patterns
One of the things we’ve been really looking at hard at ALT Lab is how we structure our development processes internally. Right now we’re working through how to make sure we can all collaborate and work on code in GitHub without creating conflicts, figuring out the best way to automate deployments to keep production and source control at parity, and pondering how to structure theme or plugin updates when literally 1000’s of sites have dependencies on them in unknown ways.
All of this while remaining fast and agile. Innovation is our bread and butter, so there is no room for unsustainable process in the name of safety.
Like most things in development, there isn’t a RIGHT answer here, just lots of options with associated trade-offs.
There are certain laws that I use to guide most of my decisions, like 80/20, think win-win, but continually I’m bashed over the head with the law of diminishing returns in my developer life.
Like most learning curves, at first things are glorious, but your typical effort quickly stops producing the typical results. From my perspective, any investment in refining a development process is destined to follow the same trajectory. At some point, the tools and processes meant to make our lives easier will begin to work against us if we continue beyond a certain point.
However, this is the essential quagmire of the situation.
It’s easy to look at a chart from profile and pinpoint when we start to regress, but it’s much harder to do when you are standing on the chart.
It’s like trying to get a view of the mountains while you’re looking at your feet while you hike.
But these are they types of decisions that need to be made, and just other reason to quietly whisper the refrain:
damn, this stuff is hard.