A thing I tell junior programmers is that their job isn't so much to solve problems, as to help figure out what the problem really is, and solve that. When somebody asks for a thing, don't go silent and go and build precisely that thing, and then come back weeks (or, heaven help us, months) later with that thing. Rather, talk to them! Hardly anybody knows what they want! Your job isn't to do precisely what they say they want, it's to help them figure out what they want! Iterate!
So, in that vein, both the solution *and the problem* are fair game for attack.
There is a wonderful, wonderful short essay by Michael Jackson (the other one) called "Brilliance" in his book "Software Requirements and Specifications". It is poignant, even painful, in the way that the the TV shows Silicon Valley or The Office are exquisitely painful. It is, alas, impossible to find unless you know exactly what you are looking for, but...
*Brilliance*, by Michael Jackson (from "Software Requirements and Specifications")
Some time ago I spent a week giving an in-house program design course at a manufacturing company in the mid-west of the United States. On the Friday afternoon it was all over. The DP Manager, who had arranged the course and was paying for it out of his budget, asked me into his office.
"What do you think?" he asked. He was asking me to tell him my impressions of his operation and his staff. "Pretty good," I said. "You've got some good people there." Program design courses are hard work; I was very tired; and staff evaluation consultancy is charged extra. Anyway, I knew he really wanted to tell me his own thoughts.
"What did you think of Fred?" he asked. "We all think Fred's brilliant." "He's very clever," I said. "He's not very enthusiastic about methods, but he knows a lot about programming." "Yes," said the DP Manager. He swiveled round in his chair to face a huge flowchart stuck to the wall: about five large sheets of line printer paper, maybe two hundred symbols, hundreds of connecting lines. "Fred did that. It's the build-up of gross pay for our weekly payroll. No one else except Fred understands it." His voice dropped to a reverent hush. "Fred tells me that he's not sure he understands it himself."
"Terrific," I mumbled respectfully. I go the picture clearly. Fred as Frankenstein, Fred the brilliant creator of the uncontrollable monster flowchart. That matched my own impression of Fred very well. "But what about Jane?" I said. "I thought Jane was very good. She picked up the program design ideas very fast."
"Yes," said the DP Manager. "Jane came to us with a great reputation. We thought she was going to be as brilliant as Fred. But she hasn't really proved herself yet. We've given her a few problems that we thought were going to be really tough, but when she finished it turned out they weren't really tough at all. Most of them turned out pretty simple. She hasn't really proved herself yet - if you see what I mean?"
So, in that vein, both the solution *and the problem* are fair game for attack.
There is a wonderful, wonderful short essay by Michael Jackson (the other one) called "Brilliance" in his book "Software Requirements and Specifications". It is poignant, even painful, in the way that the the TV shows Silicon Valley or The Office are exquisitely painful. It is, alas, impossible to find unless you know exactly what you are looking for, but...
*Brilliance*, by Michael Jackson (from "Software Requirements and Specifications")
Some time ago I spent a week giving an in-house program design course at a manufacturing company in the mid-west of the United States. On the Friday afternoon it was all over. The DP Manager, who had arranged the course and was paying for it out of his budget, asked me into his office.
"What do you think?" he asked. He was asking me to tell him my impressions of his operation and his staff. "Pretty good," I said. "You've got some good people there." Program design courses are hard work; I was very tired; and staff evaluation consultancy is charged extra. Anyway, I knew he really wanted to tell me his own thoughts.
"What did you think of Fred?" he asked. "We all think Fred's brilliant." "He's very clever," I said. "He's not very enthusiastic about methods, but he knows a lot about programming." "Yes," said the DP Manager. He swiveled round in his chair to face a huge flowchart stuck to the wall: about five large sheets of line printer paper, maybe two hundred symbols, hundreds of connecting lines. "Fred did that. It's the build-up of gross pay for our weekly payroll. No one else except Fred understands it." His voice dropped to a reverent hush. "Fred tells me that he's not sure he understands it himself."
"Terrific," I mumbled respectfully. I go the picture clearly. Fred as Frankenstein, Fred the brilliant creator of the uncontrollable monster flowchart. That matched my own impression of Fred very well. "But what about Jane?" I said. "I thought Jane was very good. She picked up the program design ideas very fast."
"Yes," said the DP Manager. "Jane came to us with a great reputation. We thought she was going to be as brilliant as Fred. But she hasn't really proved herself yet. We've given her a few problems that we thought were going to be really tough, but when she finished it turned out they weren't really tough at all. Most of them turned out pretty simple. She hasn't really proved herself yet - if you see what I mean?"
I saw what he meant.