Chuck Moore was amazing before I even knew how to code (and was a big inspiration for me), so I'm not going to even pretend that I know how to do what he does. However my view of this is that we, as programmers, can't just look at our jobs from a technical perspective. Nobody is given the time to make great solutions. The best programmers know how to work so that they can get the time they need. This is not trivial.
You can't just wander up to management and say, "I need X to make an optimal solution". They will negotiate you down. That's their job -- to negotiate into a position of advantage. When you need protection from the chaos that surrounds the rest of the organisation, you can count your lucky stars when you have an expert negotiator on your team. But when you go up to that expert negotiator and say, "I want X", the first thing that's going to go through their minds is, "I wonder if I can get that cheaper".
So programming has to be a balancing act of constantly delivering functionality while at the same time ruthlessly refining your vision of how it's going to work. If you are delivering quickly, regularly and constantly nobody will touch you for fear of screwing it all up. But knowing how to do that while still marching inevitably closer to simpler and simpler solutions is hard. A normal person needs to practice (and get it wrong) a long time before they get good at it.
Chuck describes a lot of his techniques in his books, but it's fluency that you need -- and it's fluency while things are hitting the proverbial fan that makes all the difference. You need great judgement to look at what you need and to prioritise it appropriately. If I deliver X quickly, I'll show progress. Do I need to show progress now? How fast? Can I refactor Y while I'm here? Is all of this necessary? And so on and so on.
It's tempting to think, "If only I was given lots of time.", "If only I didn't have incompetent coworkers", "If only people would listen to my advice", "If only management could look past tomorrow"... But that's not useful. Anybody can be a great programmer if we remove every problem before they start. The measure of your worth is how many of these complicating factors you can deal with while still producing great code. That's what's rare.
You can't just wander up to management and say, "I need X to make an optimal solution". They will negotiate you down. That's their job -- to negotiate into a position of advantage. When you need protection from the chaos that surrounds the rest of the organisation, you can count your lucky stars when you have an expert negotiator on your team. But when you go up to that expert negotiator and say, "I want X", the first thing that's going to go through their minds is, "I wonder if I can get that cheaper".
So programming has to be a balancing act of constantly delivering functionality while at the same time ruthlessly refining your vision of how it's going to work. If you are delivering quickly, regularly and constantly nobody will touch you for fear of screwing it all up. But knowing how to do that while still marching inevitably closer to simpler and simpler solutions is hard. A normal person needs to practice (and get it wrong) a long time before they get good at it.
Chuck describes a lot of his techniques in his books, but it's fluency that you need -- and it's fluency while things are hitting the proverbial fan that makes all the difference. You need great judgement to look at what you need and to prioritise it appropriately. If I deliver X quickly, I'll show progress. Do I need to show progress now? How fast? Can I refactor Y while I'm here? Is all of this necessary? And so on and so on.
It's tempting to think, "If only I was given lots of time.", "If only I didn't have incompetent coworkers", "If only people would listen to my advice", "If only management could look past tomorrow"... But that's not useful. Anybody can be a great programmer if we remove every problem before they start. The measure of your worth is how many of these complicating factors you can deal with while still producing great code. That's what's rare.