Awhile back I wrote The Forty-Year Programmer. You can think of it as my declaration of programming as art, not business. It’s about taking your time and getting good gradually over many years, which works great for art, but often badly for your career.
Today I want to talk about the differences between programming-as-art and programming-as-business.
In the age of using internet sites for important things – social media, say, or banking – the Internet has grown status pages, to let companies know whether a particular service is currently working.
Companies have always had internal status pages. But these days most have external status pages, so non-employees can tell whether the site is working. First people outside the company started doing that, and then companies realised they couldn’t avoid it happening, so better to provide status pages for themselves.
Why is it so bad for somebody else to provide your status page? What’s different about a company’s official status page?
As I write this there’s an ugly Discord outage which is barely acknowledged on their status page, so it’s a great time for me to talk about that.
Tech companies are recent. They also tend to die quickly. If you wanted your tech company to last awhile, how would you do it?
That’s one of those “selling yourself short” questions. If you wanted your company to last awhile, how would you do it? Tech companies don’t last long.
Let’s talk about what counts as “long” and why modern-style companies die much, much faster.
The oldest companies in the world have a few things in common, but the big one is being about their mission, most commonly supporting their family. Why? Well, companies constantly set short-term targets. You have to balance the short term against the long term, and companies are terrible at that. One trick to avoid that is to stop working for Q3 profitability and start working for your children and your grandchildren.
This is a scathing indictment of companies, if you want to do anything long-term.
In fact, even tech companies recognise this and try to work against it. That’s how obvious it is.
I can talk about keeping software working and why we care and theorise all I like. But normally people have something decent working on the ground long before the theorists catch up. What’s working on the ground? How do we currently keep software working?
I’m writing this with an eye toward individual software developers keeping things working by themselves, which says a few things about methods and budget. So let’s look!
We use many methods, with many tradeoffs. And we all use a mixture of them.
Sometimes folks will tell you to think about your value proposition – what actual benefit you bring to the table – as a software developer. That could be to negotiate your salary, interviews or promotions. It could be as a freelancer or consultant. It could also just be a way to let you get included in a really cool project (“hey, I can help you out!”)
So what’s your value proposition? What do you actually bring to the table?
They say that programming is the art of getting things working, while software engineering is the art of keeping things working.
That sounds like most programmers aren’t good at keeping things working. Which is true.
If you build to keep things working, you’ll have a superpower, one that very few software developers have. I’ll explain.
But first I need to tell you about Scarpe.
There’s an old lightning talk from RubyConf 2019 that I love, about how there’s no such thing as knowing your computer “all the way to the bottom.” At no point does it stop being a stack of leaky abstractions.
An unsuspecting fellow emailed me in response, asking, “yes, but isn’t there one, final...
On Mastodon, FullStack Ruby asks:
It’s a strange sort of environment to be living in as a Ruby programmer.
On the one hand, so much momentum behind low-level “systems” programming languages with strong, static typing.
On the other hand, the “future of programming” is guiding the education of...
A fellow recently asked me for advice about running a Ruby workshop. And folks, I had forgotten I knew so much about it before he asked!
Before Rebuilding Rails had a video class, I had written a lot of the material for Rebuilding Rails workshops that I gave at Southeast Ruby and at Railsconf. I...