Interview
in [Java Help]
|
From: Arved Sandstrom on 3 Oct 2009 19:37 Dave Searles wrote: > Patricia Shanahan wrote: >> Dave Searles wrote: >>> Patricia Shanahan wrote: >> ... >>>> In order for a manager-developer coalition to work well, each has to >>>> believe the the other has valuable skills and knowledge, and that both >>>> will do better work, and get more pay increases etc., if they listen >>>> respectfully to each other and use each other's knowledge. >>> >>> This is certainly true. It's a shame that many managers apparently >>> don't realize this, and hire technical people and then expect them to >>> just grind away in a dark room somewhere while being kept in the dark >>> and fed bullshit, their own input on technical matters either ignored >>> or even actively discouraged/avoided. >> >> I've seen it go wrong the other way round just as often. The developer >> does not listen when the manager says, before the meeting "I believe you >> when you say option A is technically best, but it is not on the table >> because of business issues X, Y, and Z." The developer goes on trying to >> push A, wasting everyone's time and the developer's credibility. > > Is it a waste of time? Perhaps the developer is convinced that issues X, > Y, and Z are outweighed by how much better A is than B. What is he > supposed to do then, NOT give his honest opinion? THAT would undermine > his credibility. Lying would undermine his credibility. In the current example, the developer has done his best by giving their honest opinion to that manager. That's how he keeps his credibility. Nobody is asking him to say that A is the best *technical* solution - it's not. What people would expect is that the developer acknowledge that A is not on the table for other reasons, and technically compare the remaining choices, B and C. In fact, when the developer delivers his recommendation, there is no harm done in including a blurb that says that A is technically superior, but is not under consideration for specified other reasons - that's also how he can keep his credibility. But the developer will absolutely lose respect and credibility if he keeps on pushing A. >> An effective manager-developer coalition depends on each participant >> respecting and learning from the other's judgment in their areas of >> expertise, not just the manager listening to the developer. > > When it comes to a technical decision, though, the area of expertise in > question is the developer's. Managers have no business deciding whether > to use mergesort or a hybrid insertion sort for the edge-sorting in the > polygon engine. Let me give you another example. You are tasked with fixing a defect in an application, and investigation reveals that while you could apply a bandaid in just one area, and a shaky bandaid at that, the technically superior solution is to fix a core class. A bunch of other areas in the application use this core class, and while those other areas have not yet exhibited the defect, they could. Here's the rub: doing the bandaid requires no further approval. It's what you were specifically tasked to do. Testing and deploying the fix is no big deal. But if you go with the technically superior approach, QA is going to have to arrange for several days of testing involving a number of people diverted from other tasks. If you don't seek managerial approval, and do this technically superior fix under the radar, fur will fly. Especially if it sneaks into a production build. A lot of technical decisions do require managerial approval. AHS
From: Arne Vajhøj on 3 Oct 2009 20:51 Arved Sandstrom wrote: > A lot of IT organizations are layered exactly opposite - they have a > bottom layer, somewhat stratified, of technical people, and on top of > that is the management layer. There may be a little bit of mixing in > between, but that general picture holds true. So what ends up happening > is, the junior technical folks talk up to the senior technical folks, > who in turn talk up to the junior managers, who in turn talk up to the > senior managers. The bigger and/or more formal the organization is, the > worse this situation is. > > There's no mystery here as to why things don't work well. I've > encountered few IT managers over my career who had any real software > development experience. I don't even pretend to know what their academic > credentials have been; I just know they haven't been programmers. So > these people start out as junior managers, and generally with little > background have to present the condensed input of the entire technical > team under them to _their_ manager, who usually started out the same > way...as a non-programmer. No wonder things don't translate all too well. > > It's not that the managers themselves - as people - are defective. It's > the system that's defective. Next time you get a chance look at your > organization or one that you have dealings with. If the structure is one > of top-level non-technical managers supervising intermediate-level > non-technical managers, who in turn supervise bottom-level non-technical > managers, who in turn supervise technical people, you've got a problem. Manager may not know about writing code, but they should know about managing. Since their job is to manage not to write code. First level management actually do benefit a lot from understanding what the work is all about. But higher up the food chain it is all budgets, ressource planning, strategy etc.. Arne
From: Arne Vajhøj on 3 Oct 2009 20:53 Eric Sosman wrote: > The issues that programmers and managers struggle with are > different. Yes, they need to be able to communicate about > technical topics in technical jargon, but the programmer does > not participate in the fights over budget allocations and the > manager does not spend his days ferreting out race conditions. > The skill sets are not the same, not at all, not even when the > two work toward a common goal. > > In a long-ago job it suddenly occurred to me that I was > under the care of a good manager. What caused this revelation? > Was it his skill with the debugger? No. His ability to squeeze > half a microsecond out of an inner loop? No. His beautifully > clear, idiomatic source code? No. The realization hit me when > I was chatting idly with someone else whose project was stalled > yet again while the ordering process for a piece of equipment > ground ponderously along -- and it suddenly dawned on me that > for upwards of a year I had *never* had to wait for new gear to > arrive: It had somehow always been budgeted for, ordered in > advance, allocated lab space, and so on. My manager would seem > to do nothing, yet somehow the equipment always showed up when > it was needed and I got to move smoothly from one project to the > next without down-time. I claim that my then manager was doing > a superb job of managing the resources, and I further claim that > his activities had nothing whatsoever to do with programming, and > I still further claim that neither I nor the most talented programmer > in our company was equipped by training, experience, or skill set > to accomplish what my manager did. So true. Arne
From: Arne Vajhøj on 3 Oct 2009 20:55 Martin Gregorie wrote: > On Thu, 01 Oct 2009 23:46:51 -0400, Eric Sosman wrote: >> In a long-ago job it suddenly occurred to me that I was >> under the care of a good manager. >> > I've been fortunate enough to work for several managers and project > managers that fit Eric's definition and yes, they ARE worth their weight > in gold. I've also worked for donkeys, but haven't we all? > > However, there's another menace that hasn't been touched on in this > thread - system designers without programming experience. These people > can screw up projects big time, whether its by designing unworkable and > unmaintainable systems, systems that can't and won't perform or by > refusing to open the design to review by the implementers. IME they can > be worse to work with than a poor manager. In general people that does not have the skills to do their job creates disasters. PPT architects are just another example of that. Arne
From: Arne Vajhøj on 3 Oct 2009 20:57
Eric Sosman wrote: > Martin Gregorie wrote: >> On Thu, 01 Oct 2009 23:46:51 -0400, Eric Sosman wrote: >>> In a long-ago job it suddenly occurred to me that I was >>> under the care of a good manager. >>> >> I've been fortunate enough to work for several managers and project >> managers that fit Eric's definition and yes, they ARE worth their >> weight in gold. I've also worked for donkeys, but haven't we all? >> >> However, there's another menace that hasn't been touched on in this >> thread - system designers without programming experience. These people >> can screw up projects big time, whether its by designing unworkable >> and unmaintainable systems, systems that can't and won't perform or by >> refusing to open the design to review by the implementers. IME they >> can be worse to work with than a poor manager. > > Yes, indeed! A good clue to watch for is the word "elegant:" > A designer who uses "elegant" a lot is probably a candidate for > hanging (on a tastefully-decorated gallows, of course). I will suggest looking out for lines with no text between boxes in drawings. The support for telepathy is pretty poor in most programming languages and technologies. Arne |