The Doctor is In: Product Manager as Psycho-Analyst
I’ve been in this job a while, a pretty good way over a year. I’ve learned a lot, and have a lot to learn still. I’ve been a long time developer and community member. I’ve been through two rigorous product development cycles, and thus have a little bit of street cred around here. Or at least I hope I do.
One piece of evidence in my favor is the frequency with which R&D guys come into my office for what I like to call "therapy sessions". Now, I work with some smart people. Some seriously smart people. And I totally understand what is going on here. These guys sit in their offices with their brains going about a million miles an hour, writing code and thinking up really amazing things. And doing that can cause a certain amount of brain stress. If you are a developer, you know what I am talking about.
Often, after working on some particular issue or bug or feature or whatever, a guy will come into my office and tell me about it. He will explain the issue, what the solution was (or might be) and what he’s thinking about it. Sometimes he wants to just tell me something cool he discovered or how he plans on solving a particular issue, or a particularly nasty problem that simply needs to be fleshed out.
These are really cool sessions, because I tend to learn a lot. But I have no delusions that these sessions are purely for my benefit. If anything, the opposite is true. Sometimes these guys just need me to be a sounding board. They want to express an idea or thought to someone. They want to work something out, and often the best way to do that is to tell it to someone. They frequently talk with each other in the halls — I’m convinced that more good development happens with two or three folks standing around in the hallways talking – but I think sometimes they want to bounce their thoughts and ideas off a guy that isn’t on the team.
For me, I eat this stuff up. In my secret dreams, I’m an R&D Engineer on the Delphi team, so I love hearing and seeing how these guys work. But in the end, I think I’m really just acting as a therapist for these guys. They just need to talk, and I’m happy to listen.
I guess I should start charging them the five cents, eh? 
While it is true, I think a blog is another good way to "talk" about somebody’s ideas and to get much wider response. And it’s free.
October 31st, 2007 at 1:45 pmHi, Nick.
I dont have anyone who could listen to me and my tech language
I have a boss, but he is businessmen, not an IT member.
Be sure, Nick, that having someone who could listen developer’s genius idea it very important for every developer!
Keep it on, I see increasing quality of Delphi. I think that Delphi is returning. And very important thing is morale of developers!
October 31st, 2007 at 2:49 pmDo the Delphi devs ever do any pair programming (two programmers at one keyboard)? It gives all the benefits you described, but with a much shorter feedback loop — instead of getting up and walking to someone else’s office once every few days, you get feedback instantly and continuously.
October 31st, 2007 at 5:50 pmThings are so easy. Recent surveys say: Win32, no .net. More bug fixes. Reliable and fast Help system, no doc explorer. Win64 and Linux story. More new language features in the compiler. Better VCL (more Graphics formats, …).
November 1st, 2007 at 7:24 amJoe –
No, I dont’ see them doing much "formal" pair programming — that doesn’t seem to be the way folks work.
Nick
November 1st, 2007 at 8:47 amOf course, one of the other benefits (at least, in my experience) is describing a problem to someone, and in the process of describing it, the solution becomes clear in a blinding flash!
Then I have to mumble a quick excuse, and get back to my workstation to test out the theory.
That and having sufficient quiet time in "the smallest room in the house".
November 1st, 2007 at 10:19 amHi Nick,
Regarding "Pair programming" or "Extreme Programing", as a developer I see it as the ultimate technique to achieve the best possible results (ever).
We have a very skilfull team and all of us tackle a problem from a different angle/expertise, however, when we *do* some coding together the solution is often *FAR* better than any of us alone would come up.
Unfortunately, no employee will ever allow it (two salaries to get "one" result).
Of course, there’s all the hidden benefits like almost 0 bugs, best performance, best "style" (does it count?), faster development - but all of this seems secondary when allocating a development budget
Just my two cents.
November 2nd, 2007 at 6:24 amCorrection: "Employee" should clearly be "employer".
Sorry about that, typing in a hurry.
November 2nd, 2007 at 6:26 amJohn said:
"Sorry about that, typing in a hurry"
—
Nice example.
Paired Message Posting would’ve taken care of that typo.
November 4th, 2007 at 7:48 pm