6 ms·
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 pro
by shadowfiend 13y ago
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.
- gaius 13y agoThis 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.
- eurleif 13y agoHow do you know you're not underestimating what a 12 year old can do?
- Aco- 13y agobecause labor laws. He's talking about work experience and that requires a work environment. Not the semblance of one.
- deleted 13y ago[deleted]
- yogo 13y agoWell 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.
- gaius 13y agoSure, 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.
- yogo 13y agoFair 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 :).
- SiVal 13y agoWell, 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?
- overgard 13y agoWow, 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."
- joe_the_user 13y agoI 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.
- overgard 13y agoBut 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.