Rather than focusing on the IQ remark, I'll mention that the entire point of this post is that programming is not just “sit[ting] down to code something”. A program written in a vacuum when you're sitting in your chair is useful to precisely one person at precisely one point in time: you, right now.
When you're working on teams, under managers, within organizations, you're working to build something that's useful for other people. One of those other people may, coincidentally, be you, but you are not the only such person. Even more importantly, you're working to produce code that can be understood by other people. But that doesn't require an IQ 3 standard deviations above anything, it requires understanding how the people around you think and how you can put your thoughts in a way that they can understand.
Now I'm not saying that there aren't useless meetings in the world, the world is full of them. And your ultimate conclusion is, like Joe Armstrong's, that the difficult isn't in producing stuff the computer can understand; the complexity lies in the fact that it's for people. However, programming without an understanding of the people who will use your program is like a factory worker whose job is putting a screw in the right place on the car. The work is pointless if the end result isn't a car someone wants to use.
If we could specify software as easily as a single model year of a single car, we could factory work that software and you could just code without worrying about people. But we don't seem to be able to do that, because software is so malleable that we can't resist the innate desire to reshape it constantly.
Anyway, back to the point: yes, the difficult part is the people. But it's also the most important part. Here's a suggestion for avoiding the feeling of wasting time: try to embrace the fact that people are important to the process, and challenge your intellect by trying to understand what those people want and how you can match users' expectations while keeping the overhead for developers to a minimum. It's a hard problem, but once you get your head into it it can be as fun to solve as how to architect an application.
This is why, when I see 22-year-old kids in interviews claiming 10 years of programming experience, that's a negative signal for me. Commercial programming is solving problems you didn't choose, in a language that's not your favourite, using existing code you didn't write, for people you would never have met outside the job, in less time than you would like. In most real situations writing the code is the easy part, figuring out what it should actually do is the hard part. Claiming 10 years experience only shows that this candidate doesn't even know what experience is.
Well there's professional experience and non-professional/hobbyist experience. In your interview you should probably clarify that. They're both different but I think there is value to the things teenager might have learned working on some toy project.
Sure, and I value that, it's how I got started myself. But the experience of working on your own projects only translates to a fraction of the work a professional programmer does.
10 years experience would put you at the level of a lead programmer, or an entry-level architect.
Well, sure, and ten years' experience working for some other company with their technologies and in-house legacy code, libraries, design methodologies, and idiosyncratic ways of using even open source tools is not ten years' experience anywhere else.
A 22 year old with ten years of programming experience has ten years of experience doing what he's been doing. He may have built a Mongo-based sports statistics website for his high school. A 32 year old with ten years of corporate dev may have been creating in-house database utilities for MegaCorp's 20 year old Oracle customer database. He's had ten years of corporate database development experience. Is his experience clearly more suited to a Mongo-based startup selling hats to sports fans because his experience was corporate?
Or is it not a matter of corporate vs non-corporate experience but just how much experience doing which of the things we need someone to do?
Regardless of age, I'd much rather take the developer with experience using one or more relational database systems. It's much easier and effective for them to downgrade their knowledge and experience to the MongoDB level than it is for somebody with only MongoDB experience to upgrade to a proper understanding of database systems.
Part of the "corporate experience" is working with teams on existing code under strict deadlines. That's not something you can just learn on your own, unfortunately. I would, hands down, take the 32-year-old in this scenario (all else being equal).
Fair enough. I just felt like that was probably something I was guilty of when younger. If you have no pro experience and you are asked that question then your most likely instinct is provide a number and base it on hobby projects. Later on you realize there are other ways to answer such a question :).
> In most real situations writing the code is the easy part, figuring out what it should actually do is the hard part.
true that. i said more or less the same thing myself shortly after starting work at a big company. just replace "real" with some variation of "business" or "corporate."
not that there's anything wrong with making money or working at large corporations, but just like a 12-year-old might not have any idea what corporate experience is, someone who learned to program at school doesn't know what the experience of mowing lawns in order to buy a compiler is like for kid.
yes try holding together a crufty pile of code that is your companys old billing system.
And when you have your first 1,000,000 month you CTO (who i think reported to vint cerf ) nudges you saying this had better be right or we are both of a job.
Maybe the kid has been contributing to open source projects? It seems like there are a lot of teenagers sending pull requests to prominent Github repos these days.
Wow, the IQ thing really got under peoples skin, but I think his point is that the hard part of being a really good programmer is dealing with all the bullshit that managers invent to keep the mediocre programmers on the straight and narrow.
Problem being, those efforts essentially make one programmer indistinguishable from another by putting shackles on everyone. I admit there's a certain logic to it, building a business that's dependent on one person's talent can be dangerous. Better to make people interchangable.
All the same: Can you imagine John Carmack writing Doom back in the 90s having to deal with what most coders have to deal with nowadays (With all the "agile")? "No sorry John, you can't commit your highly inventive code without a proper story. We're going to need to have a planning meeting on this and size up story points. Please take a defect off the list. We don't need any heroes or cowboy coders."
I have to object that there is seriously more to project management than keeping the "mediocre programmers" in line.
I mean, there are overly ambitious programmers that do have to be reigned in, there are people held back by whatever structure you might and many variations of this.
And code has to be appropriate for it's purpose. I'm sure the code for Doom is great for Doom. If it is "cowboy code", it's probably not what anyone would want for an inventory control program that will be passed to someone else in six months.
But that's kind of the point isn't it: project management, and especially agile, is about making work predictable. There's an undeniable business logic to this that I wouldn't refute.
Yet works of greatness are almost never predictable. You can't reign it into story points or whatever. There's too many false starts, or sudden insights. It certainly takes process and discipline, but not necessarily the kind that can be measured and reported.
That's probably fine for most business, because your inventory control program doesn't need any individual brilliance; but I think it can be frustrating for really good programmers because they do want to create a work of greatness.
Yet works of greatness are almost never predictable.
Actually, most great artists work with a lot of constraints. There are many great realist painters who accept the constraint of realistically representing the world. Any programmer works with the constraints of the machine.
And working in the constraints of project management and multiple-person provides plenty of room for creativity I would say. Yes, you have the constraint of the code working and you have the constraint of the code being understandable. You might even have the constraint of telling the other programmers how to do the difficult thing you can do and they can't. Greatness is possible there given that greatness is possible with code that compiles as opposed to code which is merely unpredictable.
And project managers are always happy to have people finish faster than expected.
When you're working on teams, under managers, within organizations, you're working to build something that's useful for other people. One of those other people may, coincidentally, be you, but you are not the only such person. Even more importantly, you're working to produce code that can be understood by other people. But that doesn't require an IQ 3 standard deviations above anything, it requires understanding how the people around you think and how you can put your thoughts in a way that they can understand.
Now I'm not saying that there aren't useless meetings in the world, the world is full of them. And your ultimate conclusion is, like Joe Armstrong's, that the difficult isn't in producing stuff the computer can understand; the complexity lies in the fact that it's for people. However, programming without an understanding of the people who will use your program is like a factory worker whose job is putting a screw in the right place on the car. The work is pointless if the end result isn't a car someone wants to use.
If we could specify software as easily as a single model year of a single car, we could factory work that software and you could just code without worrying about people. But we don't seem to be able to do that, because software is so malleable that we can't resist the innate desire to reshape it constantly.
Anyway, back to the point: yes, the difficult part is the people. But it's also the most important part. Here's a suggestion for avoiding the feeling of wasting time: try to embrace the fact that people are important to the process, and challenge your intellect by trying to understand what those people want and how you can match users' expectations while keeping the overhead for developers to a minimum. It's a hard problem, but once you get your head into it it can be as fun to solve as how to architect an application.