Developer experiences from the trenches
Mon 05 January 2015 by Michael Labbe
tags rant
I enjoyed consumer computing in the early eighties. I started programming on a Commodore 64 at a single digit age. Even with only 64KB of RAM, I was hooked. Too young to afford the raw resources necessary for creating physical things, I was able to sit at a computer and build worlds. By five I had written a racing game in BASIC. By six, I had made a game called Ninja which was my love letter to 80s ninjas, replete with cutscenes. (Yeah, I had played NES Ninja Gaiden by this point).
For me, computers have always been about making things, and not just games. Using them as a base for invention, learning and experimentation is incredibly enriching and rewarding. This, my personal approach to computing, has become increasingly dissonant with the direction of OS X and Windows. Jumping between the two as I shipped a commercial project, I became increasingly held back with a focus on closed-ecosystem communication and link sharing rather than creative and technical productivity.
When you run third party software to replace every meaningful piece of user-facing functionality that ships with the OS, it is time to take stock of how misaligned your creative endeavors are with the direction of your OS vendor. Stepping back, I realized I don’t even like where commercial operating systems are going anymore.
Linux, in 2015, is still difficult to set up correctly. EFI BIOSes, binary NVidia drivers, webcams that work in a degraded state, sound systems that are deficient in execution. If you love computing, these are all worth overcoming.
Once you have made the (oft-frustrating) investment of smoothing your way towards an actual, working Linux desktop, there may actually be a lot less friction to getting real work done. Gone are the mandatory workspace transitions animations, the need to convert vcxproj files to get libraries to compile and printer driver toast popups. Even if there isn’t a true sense of control (you can’t or won’t really influence most open source projects in reality), the people who do have that control haven’t chosen default settings that represent a bias in opposition to your interests. I enjoy Linux Mint’s defaults the most, by the way. Thanks to Dan Leslie for this recommendation.
It won’t be a small investment. Open source is the land of time consuming false starts. There are many software projects which claim to be finished but lack serious features. There are legions of bad alternatives, and it costs real time and money to investigate each one of them to figure out what is a complete, sane and functional choice.
A solid example of this is Linux C/C++ debugging. There are plenty of GUI wrappers for GDB out there but most of them are horrible and the ones that aren’t have considerable trade offs that may grate against your personal preferences. I had the fortune of attending Steam Dev Days last year, where Bruce Dawson introduced me to QTCreator. (Youtube, ppt) I have been using it for basic logical debugging on a 300kloc C++ codebase for a year and I haven’t gone crazy, yet.
Intent is an important, loaded word. We need to correctly apply the term “user hostile” to software that does something that a user ostensibly should not want. Shoehorning a full screen tablet experience into an OS built on APIs that clearly have not been dogfooded at scale by the vendor is user hostile. Putting social tracking cookies via a share button on a webpage is user hostile. Forcing your OS to have no browser competition through corporate policy and application signing is user hostile.
It is important to know the difference between user hostile software and bad software. Bad software may become better — it needs more time, more users to provide feedback, a better process, more experienced developers. User hostile software will not get better. It directs resources based on values that ensure a future of friction for creative and productive people.
I have seen talented, experienced developers publicly give up on switching to Linux, lashing out against bad software that is damping their forward motion. It is frustrating to hit a snag and it is a good idea to warn people against expensive blind alleys in open source. However, I wonder if these people, who often have similar creative origins to mine, would still have the tenacity to re-amass the experience necessary to contribute at the level they currently are. Building an alternative workspace that empowers your trade is hardly as difficult as becoming an experienced developer in the first place. Patience borne of the love of the craft must be plied to building tools we can all rely upon.
People who care about the future of computing will benefit in the long term by warning against user hostile decisions companies make and instead, make an effort to use to software that aims to serve them by working through the frustrating blind alleys and false starts. Software simply doesn’t get better without users. Usage is contribution.
On on positive note, I recently rediscovered the Raspberry Pi and Arduino communities and some of the great projects that have been attempted. A lot of the spirit of the early days of creative computing is couched in modern hardware and software hacking and the “maker” community. As an exercise, you can Google a cool project idea, append it with Raspberry Pi and usually find someone who has experimented with it. This is a tremendously fun rabbit hole.
Fun!
