I can also relate to the difference between being junior and being senior. During the years I worked for that company, I had to come up with choices for technology or to come up with a design. With it comes an estimate for development effort.

I had seen many of my colleages, who were loosing a lot of time on something that had been a "quick fix". However, these fixes were meant to be a temporary measure, but years afterwards they still needed regularely to spent time on the problem.

At my first meeting with the owner of the company we were discussing my solution and my estimate.

Owner: "This estimate is for a solid solution, I assume. However, do you think there is a quick fix that will only take a couple of days?"

Me: "There is no quick fix, sir"

Owner: "Sure there is. All your colleagues always have a quick-fix alternative.".

Me: "No, there isn't".

Owner *pissed*: "Ok, we'll discuss this later".

My boss tells me later that he had a hard time convincing the owner to let me keep my job. Although I did a lot of work on many of the projects, it was thought best that I would not attend meetings if the owner would be present. Every communication between me and the owner would go via my boss. The owner and I talked when we met in the hallway, but never discussed anything related to a customer or a project.

Over the years, I learned how to make a "no" sound like a "yes" or to just say "yes" and get away with "no" anyway. That is politics and that difference is what makes someone "senior".

I can understand (now) the situation that Rands is in. When I, as a programmer, make a change, then the result needs to be tested. However, as Rands is not a programmer himself, he probably doesn't understand how the process of modification works (you need to be aware of the program-transformation step of the JSD methodology to begin to understand what I am talking about) and how you can rearrange/restructure code without causing it to produce a different outcome. (thus, the modification process should not need addional testing or I am doing something wrong)

Spaghetti like code can be transformed step-by-step, even if I, as a programmer do not fully understand how the code works and so reorganise source into readable, well documented and highly structured code. After or during restructuring can a programmer choose to fix bugs or add features, but it is better to seperate those tasks. (Even better, since it is a process, a seasoned programmer should be able to do it on "automatic pilot", allowing his brain to soak on other problems. If you really know your tools and your programming language, it is possible to be chatting with colleagues all through that process. To put it differently: you know that you understand a language completely if you can switch your brain off during restructuring of existing code.)

I have trained many in programming, but this "clicks" with only a few. I don't know why, since this has been obvious to me since the first time I had to fix some elses code.

From what Rands write, I get the impression that it is indeed a rare capability. However, restructuring is even important for code I wrote myself to prepare it to add new features. How can anyone be a programmer and not be able to do this blindly?