Whatever Happened to Programming? We Did. We are to Blame.
I saw this article on Daring Fireball this morning, and decided to give it a read. Daniel J. had tweeted about it yesterday, and was in the middle of something so I didn't take the time to dig into the article. Well... this morning, I'm glad I did. The follow-up is equally interesting and as worthy of a read as the original.
There's just so much in this article to talk about. First, he's completely right about the state of typical development these days:
I want to make things, not just glue things together. When people ask me what I like about my job, I always say the same thing: that its the thrill of starting with nothing and making something. That, for me, is the essence of programming, and it hurts that there isn’t as much of it about as there used to be.
He's right on the money about the state of anything called Frameworks:
Here’s a rule of thumb (which, like all such rules, is often broken and should not be taken too seriously): beware of anything that calls itself a Framework. Anything that, instead of providing stuff that you can call, takes over the wheel and tells you what code to provide for it to call. Not always, but often, that marks the line where this stops being fun.
and:
You know the real problem with frameworks? They demo too well. Someone shows you their favourite framework and demonstrates how you can build 50% of your application in half an hour! Great! That other 50% can’t be hard, can it? But it turns out that what looked like 50% is actually 5%, and filling in the other 95% gets exponentially more difficult as you approach the 100% mark. Frameworks are great for building toys, and that fools us — again and again — into assuming they’re good for building products.
and whatever has Enterprise in it's name:
Especially, I have learned that anything that has “Enterprise” in its name is so incredibly boring that the people who use it had to shove the name of the Star Trek ship into its title just to keep themselves awake. (I am convinced that this is the case.)
Pulling it Back Home
I'm sitting here thinking these same things, and realize that there's an element that's missing here - it's the user community, or business users. They are the drivers of this change, not developers. It's not something the author touches on in his writing, but it's something I've come to realize in the past few weeks, and it's bothersome.
No good developer says I want to glue crap together! or Please let me use this Enterprise Java System! Nope. Bad programmers say that, and that's because they probably shouldn't have the job in the first place, and gluing things is at the limit of their skill set.
No, real programmers want to create things. Then why don't they? The answer is in those Framework Demos, and the press releases on the libraries and toolkits that the business users read and think that the act of creation takes exactly 3 hours, 15 minutes, and then there's no need for that documentation because they can use the frameworks to add in the features like so many Excel Macros.
It is we, the developers, that are to blame.
Why We are to Blame
Like Prometheus, or even Pandora, we brought this on ourselves by doing too good a job for those that had no understanding of the complexity and difficulty in the creative process. These people would never have thought to walk up to Picasso and say Hey, Pablo - Babe! Draw me a tree, will ya? And get it on my desk today, or tomorrow morning if you need more time. Yet in my experience, they think two days is too much for a complete new feature set.
When we create something out of nothing, and do it faster and batter than they expected, they'll simply shift their expectations for the next time. No problem there... in fact, that's an exercise they like having to do. Next time, they'll expect more, and more, and then when you have to do something a little more difficult, they'll try to compare this to something done six months ago, and how you did it fast then, so why can't you do this fast now?
This makes an individual tired.
Then some CTO who may never have even been a good programmer, decides that the entire organization is going to use some Framework, or Enterprise Widgets, and then you're a Glue Monkey.
At each turn we do something that those requesting it have no understanding of so they can't possibly understand the cost of requesting it. Many of the bad programmers see this as nothing more than a digital assembly line, and for them, it takes no more thought than assembling a toaster or DVD player. But for the good developer, the act of creation is mentally, emotionally, even physically draining. That's why it's so rewarding.
But to the non-programmer, it seems like you sat down in front of a glorified TV set, and a few hours, or days later you came up with exactly what they asked for - no matter how crazy, difficult, or near impossible it was. To these people, there is no cost of that request. Nothing could be further from the truth.
Where Can We Go From Here?
I've been thinking of solutions to this problem, and realizing that anything involving the changing of other people is arrogant in the extreme, so I have to focus on myself and what I can do to change this for me. I've come up with a few ideas. None is trivial, but I believe one of these is the solution for me.
Getting a Better Job
This seems obvious, and it is, but it's not trivial, and it's not a direct solution. You may land in a better place, or you may land in a worse place - it's impossible to tell, and in this day and age, I've run into employers that are not above decorating the truths about their organization in order to attract the top talent. Certainly in the financial sector which I'm most familiar with.
Yet, if you can find a place that matches your ideals and goals in software development, you're in business. Maybe there aren't that many places in the world like that, but I believe there are some. Maybe they're no more real than Santa and the Easter Bunny, but I really believe they are there, and as long as I believe they are there, I'll try to find one. Just one is all I need.
But lately, I've been thinking maybe the better approach is to settle a little on the job, and just change the environment.
Keep the So-So Job but Work at Home
I worked at home for 2.5 years while at First Chicago. I got more done there than I have ever gotten done in any office environment I've ever worked in. Why? Lack of distractions. It's simple, really. I have an office at home, with good internet connectivity. Just move the necessary machines to my office, start working there. For me the benefits are obvious:
- No more 1.5 hr (one-way) commute - I spend 3 hours a day commuting. I can turn that into more downtime, and therefore increase the quality of my life an enormous amount.
- No more distractions - this is a huge boost in productivity.
- Comfortable, familiar surroundings are calming - and when you're calm, you're more likely to be happy, and that will make any job seem better.
- Seeing my kids more - I'm more connected to my family, and therefore able to give more to the effort.
All these reasons make a so-so job a "good" job because you approach it every day with a sense of happiness. You don't mind going to work, because it's a comfortable, warm environment that you don't have to travel 90 mins to get to. It makes all the difference in the world.
Indie Mac Developer - a.k.a. Midlife Crisis or Complete Change of Lifestyle
This is the most interesting to me, but it's also the path most fraught with danger and uncertainty. I've done the small consulting shop thing but what I'm thinking of is just taking some of my ideas for simulation tools and putting them on the Mac. I know it's not a career path that a lot of people would see as going in the right direction, but it's the extreme case of my second point of working at home. In this case, I work at home, but I also have to generate my own revenue.
But the path to this goal is clear: get some apps, start to generate some revenue, and then replace the day job. Not easy, and not guaranteed, but it's something I could do, and something that I want to do.