There's a common theme in these posts, along the lines of "OMG I didn't realize paid programming gigs were effectively business roles". Let me address what's intrinsic and what's not.
5. People Interaction
Yup. People skills matter. Programming seems like a great job for asocial people. It's actually the shittiest job imaginable if you have weak people skills, because you get staffed with the crappy maintenance projects that have no upside. (Programming probably has the most variance of any job category; the best projects are a lot of fun, and the worst grind your mind to sawdust and produce nothing.) If no one likes you, no one trusts you, and you'll never get projects where your technical intelligence really matters.
I understand the hate that technical people have for "office politics" but the only approach that works is to adapt. To figure that shit out so you can laugh (silently) at the suckers who don't get it instead of being one of them.
4. Writing Matters
Yes, yes, yes. It really does. My personal opinion is that you're no better a programmer than you are a teacher. We're drowning in technical assets. Most assets are of abysmal quality because the people generating them never took the time to communicate what was being done, how and why, but too little code is not a problem for the software world. We have too much. Too much code and far too much unmanaged complexity.
People who are unwilling or incapable of teaching others how to use the technical assets they've created should not be programmers IMO. That's your job. To solve problems and to teach people how to use those solutions.
Sadly, this is more a consequence of big-program enterprise methodologies. In small-program shops, software can be "done". It can actually be finished. The overarching project continues to expand, but this shouldn't be accomplished by shoving more kLoC into a working program and diverting it away from the original vision.
Large, ambitious projects should be structured as systems and given the respect that a system deserves (such as attention to fault tolerance and communication protocol). There's no excuse for most of these large single-program monoliths that ultimately (Conway's Law) become artifacts of parochial corporate politics rather than elegant, minimalistically simple solutions to mathematical and computational problems.
I'm a fan of the Unix philosophy and small-program methodology. Solve a problem. Do it well. Move on. Come back to it if you need to solve another problem. Not unless. I don't like the big-program methodology, under the guise of "object-oriented programming", that seems to have won in the contemporary Java-shop culture.
2. Few Clever Algorithms
Sad but true. The managers' job is to take cleverness out of our jobs, not because they're assholes or don't trust us (usually not the case) but because if our work relied on our cleverness or creativity, then they wouldn't be doing their jobs, which is to deliver business value reliably. We tend to like the high-expectancy, high-variance, fun and creative work, but there isn't much tolerance for this in the industrial world, which would rather produce the low-expectancy "sure thing". The problem is that Big Software actually isn't "reliable"; it's just that the legacy costs are paid out later after all the decision-makers have had a couple of promotions and are far away from the wreckage.
1. Complexity from Aggregation
Yes. This is exactly why I hate big-program methodologies. They inject so much unplanned, unexpected complexity into everything. People should aim for 500 lines of really clean, usable code instead of 20,000 lines of garbage that barely solves the problem and for which no one really knows what it does.
> The managers' job is to take cleverness out of our jobs, not because they're assholes or don't trust us (usually not the case) but because if our work relied on our cleverness or creativity, then they wouldn't be doing their jobs, which is to deliver business value reliably.
Great point. Or as Daniel Geer et al put it[1] (discussing security, but applicable in general): "The central enemy of reliability is complexity. Complex systems tend to not be entirely understood by anyone. If no one can understand more than a fraction of a complex system, then, no one can predict all the ways that system could be compromised by an attacker. Prevention of insecure operating modes in complex systems is difficult to do well and impossible to do cheaply: The defender has to counter all possible attacks; the attacker only has to find one unblocked means of attack. As complexity grows, it becomes ever more natural to simply assert that a system or a product is secure as it becomes less and less possible to actually provide security in the face of complexity."
Fair point, and I agree, but complexity and creativity are orthogonal.
Managers clamp down on individual creativity and cleverness because they fear complexity, and rightly so, because 95% of software complexity serves no value, and only creates frustration and risk. Their risk-limiting optimization tends to suck all the fun and creativity out of the job, although that's not their intent.
Here's the problem: complexity emerges anyway (Greenspun's Tenth Rule). Force people to use Java instead of high-level languages and they'll invent AbstractFactory patterns and hideous, undocumented DSLs in the name of "object-oriented programming". The problem with software is the same problem that exists in legislation: laws are never unmade. The difference is that no one needs to know or care about horse-carriage requirements from 1730 in Philadelphia, but the legacy complexity in software lives on, making everything unreadable and messy.
Moreover, the end-result of all this unexpected complexity is that most software jobs become a legacy slog, which further reduces the room for creative expression.
An excellent comment. Your point number 2, by the way, applies very well to most legal work done by large law firms. Been there, done that. It never hurts to remind people in early career as they leave formal higher education and go into the for-profit, private-enterprise labor force that domain-specific technical skill as such is just a small part of the skill set someone needs to build a successful career.
>Yup. People skills matter. Programming seems like a great job for asocial people. It's actually the shittiest job imaginable if you have weak people skills, because you get staffed with the crappy maintenance projects that have no upside. (Programming probably has the most variance of any job category; the best projects are a lot of fun, and the worst grind your mind to sawdust and produce nothing.) If no one likes you, no one trusts you, and you'll never get projects where your technical intelligence really matters.
I understand the hate that technical people have for "office politics" but the only approach that works is to adapt. To figure that shit out so you can laugh (silently) at the suckers who don't get it instead of being one of them.
This is why the best programmers are in startups -- I do not believe you can be good at people and computers at the same time. And it is much more profitable to be involved in people, sadly.
> This is why the best programmers are in startups -- I do not believe you can be good at people and computers at the same time. And it is much more profitable to be involved in people, sadly.
Could this also be one of the _biggest_ reasons why startup fails? Lack of people skill and focusing on technical problems for the sake of technical? Not to mention lack of communication to know the intend of the code seems to be the biggest time sink on programmer's productivity.
Of course on the flip side you can always hire the smarter and smarter developers than the previous guy since you kind of need them to navigate the previous legacy code base. This seems to be the pattern in our industry.
I do not believe you can be good at people and computers at the same time.
You can become adequate, and you should. Yes, the monkey-bots running million-year-old legacy code are a pain in the ass (it's annoying being one, too) but you can learn how to deal with them, and you must.
People skills matter more when you're in startups. The business side is all pitch, pitch, pitch, and from a disadvantaged position. If you're technical, you need the people skills to size up a business co-founder, or else you'll end up with a dud, and you need to be good enough with people that he trusts you and takes you seriously.
5. People Interaction
Yup. People skills matter. Programming seems like a great job for asocial people. It's actually the shittiest job imaginable if you have weak people skills, because you get staffed with the crappy maintenance projects that have no upside. (Programming probably has the most variance of any job category; the best projects are a lot of fun, and the worst grind your mind to sawdust and produce nothing.) If no one likes you, no one trusts you, and you'll never get projects where your technical intelligence really matters.
I understand the hate that technical people have for "office politics" but the only approach that works is to adapt. To figure that shit out so you can laugh (silently) at the suckers who don't get it instead of being one of them.
4. Writing Matters
Yes, yes, yes. It really does. My personal opinion is that you're no better a programmer than you are a teacher. We're drowning in technical assets. Most assets are of abysmal quality because the people generating them never took the time to communicate what was being done, how and why, but too little code is not a problem for the software world. We have too much. Too much code and far too much unmanaged complexity.
People who are unwilling or incapable of teaching others how to use the technical assets they've created should not be programmers IMO. That's your job. To solve problems and to teach people how to use those solutions.
3. Software is Never Done
Further reading: http://michaelochurch.wordpress.com/2012/04/13/java-shop-pol...
Sadly, this is more a consequence of big-program enterprise methodologies. In small-program shops, software can be "done". It can actually be finished. The overarching project continues to expand, but this shouldn't be accomplished by shoving more kLoC into a working program and diverting it away from the original vision.
Large, ambitious projects should be structured as systems and given the respect that a system deserves (such as attention to fault tolerance and communication protocol). There's no excuse for most of these large single-program monoliths that ultimately (Conway's Law) become artifacts of parochial corporate politics rather than elegant, minimalistically simple solutions to mathematical and computational problems.
I'm a fan of the Unix philosophy and small-program methodology. Solve a problem. Do it well. Move on. Come back to it if you need to solve another problem. Not unless. I don't like the big-program methodology, under the guise of "object-oriented programming", that seems to have won in the contemporary Java-shop culture.
2. Few Clever Algorithms
Sad but true. The managers' job is to take cleverness out of our jobs, not because they're assholes or don't trust us (usually not the case) but because if our work relied on our cleverness or creativity, then they wouldn't be doing their jobs, which is to deliver business value reliably. We tend to like the high-expectancy, high-variance, fun and creative work, but there isn't much tolerance for this in the industrial world, which would rather produce the low-expectancy "sure thing". The problem is that Big Software actually isn't "reliable"; it's just that the legacy costs are paid out later after all the decision-makers have had a couple of promotions and are far away from the wreckage.
1. Complexity from Aggregation
Yes. This is exactly why I hate big-program methodologies. They inject so much unplanned, unexpected complexity into everything. People should aim for 500 lines of really clean, usable code instead of 20,000 lines of garbage that barely solves the problem and for which no one really knows what it does.