"Programmers are the brick-layers of the computer industry."
When I was 12 and professed an interest in computers and programming, this was the advice my friendly neighbour offerred. Being 12, I can't remember if I had a clever retort to this line, but it certainly struck with me.
The neighbour in question was an engineering manager, running a large enterprise team delivering various aspects of online voting systems for government (amongst other things.) That Australia still does not have online voting available to most of the population probably goes some way to explain his view. (For what it's worth, it's now available in NSW to disabled voters who can't reach a poling booth as a trial run of the service, which has been in development for over a decade. It is a complicated system due to all the negatives ramifications of stuffing it up, but this is still a stupidly long time!)
As I grew up, studied engineering, then physics, then robotics, and then ultimately ended up working as a software engineer (not a programmer? Here's why...), I've thought back to this line more often than you'd expect for such a throwaway remark. But the question that really bugs me is; was the remark engendered by his management of a large team of varying talents on a long, complicated, and tedious project? Or is there actually some truth to it?
The neighbour in question was an engineering manager, running a large enterprise team delivering various aspects of online voting systems for government (amongst other things.) That Australia still does not have online voting available to most of the population probably goes some way to explain his view. (For what it's worth, it's now available in NSW to disabled voters who can't reach a poling booth as a trial run of the service, which has been in development for over a decade. It is a complicated system due to all the negatives ramifications of stuffing it up, but this is still a stupidly long time!)
As I grew up, studied engineering, then physics, then robotics, and then ultimately ended up working as a software engineer (not a programmer? Here's why...), I've thought back to this line more often than you'd expect for such a throwaway remark. But the question that really bugs me is; was the remark engendered by his management of a large team of varying talents on a long, complicated, and tedious project? Or is there actually some truth to it?
Like most thorny topics, it's a bit of both. In particular, both the skill of a programmer and the potential impact of their work play a big part. If the potential impact of her work is low, then even the best programmer might as well be a bricklayer. And it's not like being a bricklayer is particularly bad work - you get paid fairly by default, often have the option of far better paid overtime, are a critical part of the overall project, and get a decent chunk of local societal recognition. There's some dialogue in Good Will Hunting that nicely illustrates this viewpoint:
SEAN It's not about the job. I don't care if you work for the government. But you can do anything you want, you are bound by nothing. What are you passionate about. What do you want? I mean there are guys who work their entire lives laying brick so that their kids have a chance at the opportunities you have here.
WILL I didn't ask for this.
SEAN No. You were born with it. So, don't cop out behind "I didn't ask for this."
WILL What do you mean "cop out?" I mean, w-w-what's wrong with layin' brick?
SEAN Nothing.
WILL There's nothing wrong---That's some-- That's somebody's home I'm building.
SEAN Right. My dad laid brick. Okay? Busted his ass so I could have an education.
WILL Exactly. That's an honorable profession. What's wrong with..with fixing somebody's car. Someone can get to work the next day because of me. There's honor in that.
There's honour in bricklaying. There's honour in the schlep of programming. But where programming differs from bricklaying is in its potential to be so much more! And this is where skill and impact play their part.
Michael O. Church has an excellent take on the trajectory of a software engineer, which neatly condenses skill and impact into a scale from 0 to 3. In brief:
Michael O. Church has an excellent take on the trajectory of a software engineer, which neatly condenses skill and impact into a scale from 0 to 3. In brief:
Teams, in general, have four categories into which a person’s contribution can fall: dividers, subtracters, adders, and multipliers. Dividers are the cancerous people who have a broad-based negative effect on productivity. [snip] Subtracters are people who produce less than they cost, including the time of others who must coach and supervise them. As a temporary state, there’s nothing wrong with being a subtracter – almost every software engineer starts out his career as one, and it’s common to be a subtracter in the first weeks of a new job. Adders are the workhorses: competent individual contributors who deliver most of the actual work. Finally, multipliers are those who, often in tandem with “adder” contributions, make other people more productive. In many industries, being a multiplier is thought to be the province of management alone, but in technology that couldn’t be farther from the truth, because architectural and infrastructural contributions (such as reusable code libraries) have a broad-based impact on the effectiveness of the entire company.
What this scale intends to measure is the transition from a subtracter to an adder (0.0 to 1.0), from an adder to a multiplier (1.0 to 2.0), and from a “local” to a “global” multiplier (2.0 to 3.0).
From 0 to 1.8ish, you're building skill. From 1.8 to 3, you're increasing impact. The sad reality of the software industry is that the average programmer never gets much above 1.2. Now this whole article is predicated on the assumption that most programmers don't want to be told they're bricklayers! They want to learn, want to have an impact, and want to see their profession elevated beyond a humble trade. So how does one grow into a skilled adder, and eventual multiplier? The answer is three-fold: a) language choice, b) workplace choice, and c) do something else!
I'll leave a) for Michael. His rants about Java are much more funny than mine. I dropped out after one semester of Java. He endured it. Other people have also discussed this issue in various forms.
I think b) is fairly self-explanatory - if your workplace doesn't need high-skill work, you won't become a highly-skilled programmer. If your workplace serves a tiny niche, or even a huge market automating the profits out of some dying industry, it's unlikely to have a big impact on software engineering in general, and you're thus unlikely to make a big impact yourself.
With c) being the most controversial, let me start by pointing out that I certainly don't mean stop being a programmer. What you need is to do something else too. To grow beyond 'just' a bricklayer, you need to be a something who lays bricks. Let's face it, bricklaying isn't rocket surgery, it's pretty straightforward, and your average something is probably going to be pretty good at it - especially if their something is a related field. Imagine an architect who's a technically proficient bricklayer. Is he the world's best architect? Who knows? But he's likely to be the kind of bricklayer you'd want in your building company because his architectural experience more than compensates for any other technical shortcomings, like a smaller than average beer gut. In fact, it's even possible that you'd prefer the architect to do the bricklaying, because where the bricklayers measure performance in bricks per hour, the architect still thinks in terms of the structural integrity of the building.
Robert Heinlein claimed "specialisation is for insects", but having a specialty and a trade permits a cross-pollination of fields that certainly improves the trade (and probably improves the specialty too, especially if the trade is programming, and you agree with Marc Andreessen's claim that software is eating the world.) From my own experience as a roboticist who programs, I've had many experiences - even in my current role on the backend platform for an e-commerce provider - where knowledge of feedback loops, real-time system dynamics, or signal processing has led to insights or techniques that would otherwise have been missed.
These benefits make an impact on an organisational level, which (if you've picked the right organisation in the first place) helps to get you work that will make more impacts in the future. This positive cycle ups your skills, benefits the organisation, and gets you further along the scale to later having a global impact.
So if you aspire to be more than one of the bricklayers of the computer industry, you need to be more than just a programmer. Specialise and program. Be a something who programs. You might not become the world's best bricklayer, but you'll make a bigger dent in the universe than they ever could.
I'll leave a) for Michael. His rants about Java are much more funny than mine. I dropped out after one semester of Java. He endured it. Other people have also discussed this issue in various forms.
I think b) is fairly self-explanatory - if your workplace doesn't need high-skill work, you won't become a highly-skilled programmer. If your workplace serves a tiny niche, or even a huge market automating the profits out of some dying industry, it's unlikely to have a big impact on software engineering in general, and you're thus unlikely to make a big impact yourself.
With c) being the most controversial, let me start by pointing out that I certainly don't mean stop being a programmer. What you need is to do something else too. To grow beyond 'just' a bricklayer, you need to be a something who lays bricks. Let's face it, bricklaying isn't rocket surgery, it's pretty straightforward, and your average something is probably going to be pretty good at it - especially if their something is a related field. Imagine an architect who's a technically proficient bricklayer. Is he the world's best architect? Who knows? But he's likely to be the kind of bricklayer you'd want in your building company because his architectural experience more than compensates for any other technical shortcomings, like a smaller than average beer gut. In fact, it's even possible that you'd prefer the architect to do the bricklaying, because where the bricklayers measure performance in bricks per hour, the architect still thinks in terms of the structural integrity of the building.
Robert Heinlein claimed "specialisation is for insects", but having a specialty and a trade permits a cross-pollination of fields that certainly improves the trade (and probably improves the specialty too, especially if the trade is programming, and you agree with Marc Andreessen's claim that software is eating the world.) From my own experience as a roboticist who programs, I've had many experiences - even in my current role on the backend platform for an e-commerce provider - where knowledge of feedback loops, real-time system dynamics, or signal processing has led to insights or techniques that would otherwise have been missed.
These benefits make an impact on an organisational level, which (if you've picked the right organisation in the first place) helps to get you work that will make more impacts in the future. This positive cycle ups your skills, benefits the organisation, and gets you further along the scale to later having a global impact.
So if you aspire to be more than one of the bricklayers of the computer industry, you need to be more than just a programmer. Specialise and program. Be a something who programs. You might not become the world's best bricklayer, but you'll make a bigger dent in the universe than they ever could.
RSS Feed