Re: Interview

Discussion in 'Java' started by Tom Anderson, Oct 1, 2009.

  1. Tom Anderson

    Tom Anderson Guest

    On Thu, 1 Oct 2009, Ken T. wrote:

    > I had an interview today. It didn't go as well as I would have liked.
    > It didn't go badly but I wasn't familiar with everything my potential
    > employer did.
    >
    > When did it become necessary for a developer to not only know the
    > language used inside out, but also the APIs used, the third party tools
    > used, and basically to have done the same job for the last five years.
    >
    > I thought that the whole point of a good computer science education was
    > that you could apply what you learned to any language or API.


    It is. Most people are idiots, and don't appreciate this. Some of these
    idiots are managers.

    tom

    --
    Most people lose their talent at puberty. I lost mine in my early
    twenties. I began to think of children not as immature adults, but of
    adults as atrophied children. -- Keith Johnstone
     
    Tom Anderson, Oct 1, 2009
    #1
    1. Advertising

  2. Tom Anderson

    Tom Anderson Guest

    On Thu, 1 Oct 2009, Eric Sosman wrote:

    > Tom Anderson wrote:
    >> On Thu, 1 Oct 2009, Ken T. wrote:
    >>
    >>> I had an interview today. It didn't go as well as I would have liked.
    >>> It didn't go badly but I wasn't familiar with everything my potential
    >>> employer did.
    >>>
    >>> When did it become necessary for a developer to not only know the
    >>> language used inside out, but also the APIs used, the third party tools
    >>> used, and basically to have done the same job for the last five years.
    >>>
    >>> I thought that the whole point of a good computer science education was
    >>> that you could apply what you learned to any language or API.

    >>
    >> It is. Most people are idiots, and don't appreciate this. Some of these
    >> idiots are managers.

    >
    > Quick question: Have you ever been a hiring manager?


    No.

    > What hoops did you have to jump through to get budget allocations for
    > the new employee(s)? What promises did you have to make to the people
    > who authorized the money?
    >
    > I have hired people, and I have had to go to the mat to justify the
    > expenditure -- which is not trivial, as the fully-burdened cost of a
    > full-time engineer runs at least 150% of the "face value" salary,
    > sometimes a good deal more. I had to make the case that we needed
    > additional help, and would never have succeeded with "Let's hire
    > somebody just in case; I bet it'll come in handy someday." No, the
    > debate *always* centered on our needs for some project that was already
    > underway, or at least imminent. And if you've justified the position on
    > the grounds that Project Pancake needs help, the person who fills it had
    > better not be a general-issue cook, but someone who really knows
    > griddles.


    The person who *should* fill it should be someone who will get Project
    Pancake back on track as fast as possible. That might be someone who's
    spent the last ten years being a short-order cook, true. But it could well
    be a hotshot sous-chef who can pick up everything there is to know about
    griddles in a couple of weeks.

    Now, you're talking about what you have to do to keep the next layer up
    happy, not what's best for the project. That's the point you're making
    here. But i don't think this is really any different to the situation i
    was implying - there are people making bad decisions who have the power to
    make them stick somewhere in the tree. It might be the person doing the
    hiring, it might be their boss, it might be anyone up to the chairman of
    the board, or indeed your local national legislative body. None of which
    changes the fact that Ken T., who spent four years studying under Gordon
    Ramsay, is going to lose out to some burger-flipping dolt on the strength
    of a few bullet points.

    > I eventually got myself out of the management game, feeling that I
    > wasn't all that good at it and that there were aspects of it that I
    > actively disliked. I especially hated doing annual performance reviews;
    > who was I to be playing Judge, Jury, and Executioner with these people?
    > And on one occasion there was a person I really should have fired, but
    > I lacked the guts. Luckily for me he accepted an offer elsewhere and
    > left under his own power, but I knew I'd lucked out and might not luck
    > out the next time. So I jumped off the management ladder -- I hadn't
    > gotten high enough to suffer injury from the fall -- and have been much
    > happier since, thank you. But I *don't* subscribe to the no-thought
    > Dilbertian dismissal of managers as inherently defective (a position
    > more extreme than the one you've actually taken, I confess, but using
    > words like "idiots" to describe people who face circumstances of which
    > you wot not tends to make me rant a bit).


    I certainly didn't mean to imply that managers are a special breed of
    imbecile. I think most developers are idiots too.

    tom

    --
    [Philosophy] is kind of like being driven behind the sofa by Dr Who -
    scary, but still entertaining. -- itchyfidget
     
    Tom Anderson, Oct 1, 2009
    #2
    1. Advertising

  3. Tom Anderson

    markspace Guest

    Eric Sosman wrote:

    >
    > Okay, enough. Now, where did I put that pill bottle?
    >



    I put mine in the empty beer bottles. ;)
     
    markspace, Oct 1, 2009
    #3
  4. Eric Sosman wrote:
    [ SNIP ]

    > I eventually got myself out of the management game, feeling that I
    > wasn't all that good at it and that there were aspects of it that I
    > actively disliked. I especially hated doing annual performance reviews;
    > who was I to be playing Judge, Jury, and Executioner with these people?
    > And on one occasion there was a person I really should have fired, but
    > I lacked the guts. Luckily for me he accepted an offer elsewhere and
    > left under his own power, but I knew I'd lucked out and might not luck
    > out the next time. So I jumped off the management ladder -- I hadn't
    > gotten high enough to suffer injury from the fall -- and have been much
    > happier since, thank you. But I *don't* subscribe to the no-thought
    > Dilbertian dismissal of managers as inherently defective (a position
    > more extreme than the one you've actually taken, I confess, but using
    > words like "idiots" to describe people who face circumstances of which
    > you wot not tends to make me rant a bit).

    [ SNIP ]

    IMHO an IT organization works best if it has two parallel chains of
    management/supervision just like the military does. In the military, of
    course, you've got the enlisted chain, which reaches all the way up to
    the top, and this is where the technical expertise mostly resides. And
    also in the military, you've got the parallel commissioned chain -
    officers - who lead and "manage". At every level of the management
    food-chain you have a technical advisor - the enlisted person.

    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.

    AHS
     
    Arved Sandstrom, Oct 2, 2009
    #4
  5. Tom Anderson

    EJP Guest

    Arved Sandstrom wrote:
    > IMHO an IT organization works best if it has two parallel chains of
    > management/supervision just like the military does.


    It does but more accurately these consist of the Staff chain where the
    technical expertise is and the field command chain where the moral
    leadership is. You can get to be a staff general without ever having had
    a field command. This of course is resented by the field command chain
    but they know they need the system.

    The bizarre stratification in industry where senior techs report to
    junior managers only seems to happen in Anglo-Saxon countries. In
    Germany and Italy you can get onto the board by virtue of being an engineer.
     
    EJP, Oct 2, 2009
    #5
  6. Tom Anderson

    Eric Sosman Guest

    Arved Sandstrom wrote:
    > [...]
    > 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. [...]


    The Peter Principle takes good programmers and promotes
    them until they're bad managers. (It also turns good doctors
    into bad department heads, good teachers into bad deans, and
    bad actors into worse governors ...)

    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.

    (Alas, not all managers are as good as that one. But then,
    few programmers are as good as they think they are, so it sort
    of evens out.)

    There is no a priori reason to think that a good programmer
    can be a good manager, nor that a good manager must be a good
    programmer.

    --
    Eric Sosman
    lid
     
    Eric Sosman, Oct 2, 2009
    #6
  7. 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.


    --
    martin@ | Martin Gregorie
    gregorie. | Essex, UK
    org |
     
    Martin Gregorie, Oct 2, 2009
    #7
  8. Tom Anderson

    Lew Guest

    Ken T. wrote:
    > I've noticed the money that is being talked about these days seems like
    > it is a decade out of date.


    A decade ago, script kiddies who thought a pointer was something that shone a
    red dot for kitties to play with were asking and getting $85K/yr (US).

    --
    Lew
     
    Lew, Oct 2, 2009
    #8
  9. Tom Anderson

    GArlington Guest

    On 2 Oct, 07:39, "Ken T." <> wrote:
    > On Thu, 01 Oct 2009 23:42:45 +0100, Tom Anderson wrote:
    > > I certainly didn't mean to imply that managers are a special breed of
    > > imbecile. I think most developers are idiots too.

    >
    > I pretty much agree with this statement, but it takes a special breed of
    > idiot to make his/her living by telling other people what to do.
    >
    > BTW, the guy I talked to was a technical guy.  He just wanted me to have
    > experience with exactly the portions of the API that he was using in his
    > project.  Close was no where near good enough.
    >

    I was interviewed by a guy like this too just last month, because of
    his approach I am now working (contract) 150 miles away from home.
    Still, the fact that I AM working gives me some hope...

    > That said, it may be that in this market people can get exactly what they
    > want.  Maybe enough of us are unemployed (or underemployed as in my case)
    > that they can just ask for something and expect to get it.  
    >
    > I've noticed the money that is being talked about these days seems like
    > it is a decade out of date.  
    >
    > --
    > Ken T.
    >
    >   Among the natural rights of the colonists are these: first, a right
    >   to life, secondly to liberty, thirdly to property; together with the
    >   right to defend them in the best manner they can.  -- Samuel Adams
     
    GArlington, Oct 2, 2009
    #9
  10. Tom Anderson

    Eric Sosman Guest

    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).

    --
    Eric Sosman
    lid
     
    Eric Sosman, Oct 2, 2009
    #10
  11. Eric Sosman wrote:
    > Arved Sandstrom wrote:
    >> [...]
    >> 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. [...]

    >
    > The Peter Principle takes good programmers and promotes
    > them until they're bad managers. (It also turns good doctors
    > into bad department heads, good teachers into bad deans, and
    > bad actors into worse governors ...)
    >
    > 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.


    I don't disagree. My argument is simply that any manager, at any level,
    would benefit from occasionally getting input directly from a technical
    person, rather than having it filtered from below through other
    managers. A senior manager, IOW, could have a weekly pow-wow, as a
    sanity check, with a senior technical type, and all the way down the
    chain. This would keep the senior manager from being completely
    disconnected from reality.

    And by "senior technical type" I don't mean CIO or CTO either. I've been
    in situations where no real technical person has ever talked directly
    with the CIO; IOW, the CIO is just another manager who happened to get
    saddled with the IT department.

    [ SNIP ]

    > (Alas, not all managers are as good as that one. But then,
    > few programmers are as good as they think they are, so it sort
    > of evens out.)
    >
    > There is no a priori reason to think that a good programmer
    > can be a good manager, nor that a good manager must be a good
    > programmer.


    I don't think one follows from the other, no, but I believe that the
    traits that make for a good manager can co-exist with the traits that
    make a good programmer. Capable software team leads clearly have to wear
    both hats, and for that matter so do technical architects from time to time.

    AHS
     
    Arved Sandstrom, Oct 2, 2009
    #11
  12. Tom Anderson

    Lew Guest

    Ken T. wrote:
    > Maybe I'm asking for too much money. Honestly I'm willing to work fairly
    > cheap, but I don't want to price myself too low for fear of losing the
    > job opportunity. "Why is this guy only asking $XXX?"


    I've heard of both artists and perfumers that if their products don't sell
    well the first month, they double the price, and again after the second month.
    Reputedly they always sell out by the third month.

    Professional sales training is a real boon to software developers. One
    strategy is to make yourself so apparently valuable to the potential employer
    that they have a powerful emotional and rational desire to hire you. This
    cannot be done by manipulation of price. Its success rests on effective
    communication of value.

    Today's labor market is naturally extremely competitive. Few engineering
    types ever learn effective salesmanship to help them get over on the
    competition. That gives those that do an even better edge.

    Value selling is more effective than price selling. On the other side, value
    purchasing is more satisfying than price purchasing.

    As pointed out elsethread, employers have a preconceived notion of what they
    want, and a limited budget. There are jobs in the upper income ranges, but of
    course your competition for those is even fiercer. A skill set broad and
    deep, and an engaging presentation are /de rigueur/. You have to understand
    the employer's limitations. If they cannot offer enough money for you to
    accept, don't apply for that job. If they can come close, pay careful
    attention to intangibles, like whether they'll even permit you to excel.

    We have another edge. Most software projects have a large number of
    underqualified and/or undermotivated developers. This is a natural outgrowth
    of the workers' perception that software development is good work, and
    employers' perception that low cost and high buzzword compliance will produce
    good software. A good programmer with solid fundamentals can seem like an
    outright genius and coding machine by comparison. Just don't piss the peons
    off or they'll sabotage you politically. Buy them doughnuts.

    --
    Lew
     
    Lew, Oct 3, 2009
    #12
  13. Tom Anderson

    Dave Searles Guest

    Lew wrote:
    > Today's labor market is naturally extremely competitive. Few
    > engineering types ever learn effective salesmanship to help them get
    > over on the competition. That gives those that do an even better edge.


    That is a problem. An engineer should be able to focus on engineering,
    and should not have to develop an irrelevant (and itself challenging)
    skill-set like salesmanship. Some people exist that have a high aptitude
    only for the former, and will be wasted in Lew's World. Those with some
    aptitude for both would still make better engineers if not distracted by
    having to devote x% of their time to developing
    irrelevant-to-engineering skills.

    > We have another edge. Most software projects have a large number of
    > underqualified and/or undermotivated developers. This is a natural
    > outgrowth of the workers' perception that software development is good
    > work, and employers' perception that low cost and high buzzword
    > compliance will produce good software.


    This latter perception is erroneous. Any employer actually competent to
    hire programmers should be aware of its being erroneous. Who is hiring
    so many incompetent employers, and why?

    > A good programmer with solid fundamentals can seem like an outright
    > genius and coding machine by comparison. Just don't piss the peons
    > off or they'll sabotage you politically.


    Politics is another skill that should not be demanded of an engineer.
     
    Dave Searles, Oct 3, 2009
    #13
  14. Dave Searles wrote:
    > Lew wrote:

    [ SNIP ]

    >> A good programmer with solid fundamentals can seem like an outright
    >> genius and coding machine by comparison. Just don't piss the peons
    >> off or they'll sabotage you politically.

    >
    > Politics is another skill that should not be demanded of an engineer.


    You'd best have some skill at politics if you wish to enjoy a successful
    career. Leaving aside software consultants, who absolutely must have
    skill at politics, and focusing on employees, consider the real-world
    case of trying to sell your manager (or a whole chain of managers) on an
    approach to accomplishing something.

    Let's say for example that you're a technical recommender, and you've
    determined that there are 3 ways of doing X: A, B and C. A is the best,
    technically, and C is the worst. You've put a lot of effort into
    assessing all three approaches, and there's no question but that A is
    absolutely the best way of solving the problem. So at the next meeting
    when you present your findings you are dumbfounded and angry when A is
    dismissed out of hand for reasons you never considered, and in a tight
    battle between supporters of B and supporters of C, C wins.

    Sound like an unlikely scenario? Well, it's not, and I'm guessing you
    know that. A technical person who has found themselves in such an
    imbroglio has failed politically on several counts - they didn't do
    their homework on what the approvers and real decision-makers think, and
    they didn't prepare a strategy to take all that into account.

    I've seen proposals postponed or cancelled for almost every political
    (or emotional) reason in the book. In one case an influential approver
    was antagonistic to open-source software (and we also couldn't be seen
    to piss off a vendor). In another case a manager detected that a
    proposal would have made serious inroads on his little fiefdom. In yet
    another, a bad approach had already been sold to the people way up the
    food chain, and to now propose a better and completely different
    approach would have meant an admission of error...so the decision was to
    band-aid the bad implementation. And so forth.

    In all of these cases there were nuances as well. In the first case the
    vendor officially supported over three-quarters of our installed
    software. If we had replaced the small piece that was flawed with an
    open-source implementation, the argument was that the vendor would have
    refused to deal with any problems related to the entire stack. Not
    inconceivable. That's political, but it's also a decent argument.

    In the other two cases I mention there were actually larger project
    issues involved - possible retraining of internal staff, or hiring more
    external people, extending deadlines etc. And trying to sell all of that
    to the people holding the purse strings. That's political too, but it's
    real. *You*, the technical person, may be sold on the merits of
    re-implementing application Y in technology Z, but good luck on selling
    that in a typical bureaucratic environment.

    This is all political stuff. And unless you're a software developer on
    the bottom rung (and maybe not even then) you'll have a happier career
    if you learn how to take it into account. You certainly don't have to,
    but you'll end up frustrated and bitter if you don't. IMHO.

    AHS
     
    Arved Sandstrom, Oct 3, 2009
    #14
  15. Tom Anderson

    Lew Guest

    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.


    A good busboy makes the waiter more money, which they share with the busboy.
    Busboys are part of the sales team.

    - from /Everything I Need to Know as a Software Developer I Learned as a
    Busboy/, by Lew Bloch.

    --
    Lew
     
    Lew, Oct 3, 2009
    #15
  16. Patricia Shanahan wrote:
    > Arved Sandstrom wrote:
    >> Dave Searles wrote:
    >>> Lew wrote:

    >> [ SNIP ]
    >>
    >>>> A good programmer with solid fundamentals can seem like an outright
    >>>> genius and coding machine by comparison. Just don't piss the peons
    >>>> off or they'll sabotage you politically.
    >>>
    >>> Politics is another skill that should not be demanded of an engineer.

    >>
    >> You'd best have some skill at politics if you wish to enjoy a
    >> successful career. Leaving aside software consultants, who absolutely
    >> must have skill at politics, and focusing on employees, consider the
    >> real-world case of trying to sell your manager (or a whole chain of
    >> managers) on an approach to accomplishing something.

    > ...
    >
    > More generally, anything other than the most trivial software
    > development is a social activity, requiring multiple people working
    > together. Multiple people allocating and sharing resources means politics.
    >
    > The very simplest political strategy for a skilled software developer
    > with weak political skills is to identify a very competent manager, and
    > finagle a job with that person as supervisor. That step may require a
    > little political skill, but enough technical skill may lead to the
    > manager also working the politics, with the same objective and a lot
    > more skill.

    [ SNIP useful example of how this coalition could work ]

    > 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.
    >
    > Patricia


    I fully agree. In fact the strategy you highlight is good for any
    developer, not just the ones with weak political skills.

    In connection with the particular example we've been using here, another
    useful political strategy is to advertise all the technical approaches
    under consideration as soon as you can. Talk about them, email about
    them, make sure everyone hears about them. Just don't make any
    recommendations...don't even reveal any hint of bias. Soon enough you'll
    hear about the possible objections and can take those into account -
    ideally with the help of "your" manager.

    AHS
     
    Arved Sandstrom, Oct 3, 2009
    #16
  17. Tom Anderson

    Dave Searles Guest

    Arved Sandstrom wrote:
    > Dave Searles wrote:
    >> Lew wrote:

    > [ SNIP ]
    >
    >>> A good programmer with solid fundamentals can seem like an outright
    >>> genius and coding machine by comparison. Just don't piss the peons
    >>> off or they'll sabotage you politically.

    >>
    >> Politics is another skill that should not be demanded of an engineer.

    >
    > You'd best have some skill at politics if you wish to enjoy a successful
    > career.


    Is that a threat?

    > Leaving aside software consultants, who absolutely must have
    > skill at politics, and focusing on employees, consider the real-world
    > case of trying to sell your manager (or a whole chain of managers) on an
    > approach to accomplishing something.


    Wouldn't it be better to just focus on actually accomplishing something,
    and have someone else (team leader, or whatever immediate boss) handle
    that sort of nonsense?

    > Let's say for example that you're a technical recommender, and you've
    > determined that there are 3 ways of doing X: A, B and C. A is the best,
    > technically, and C is the worst. You've put a lot of effort into
    > assessing all three approaches, and there's no question but that A is
    > absolutely the best way of solving the problem. So at the next meeting
    > when you present your findings you are dumbfounded and angry when A is
    > dismissed out of hand for reasons you never considered, and in a tight
    > battle between supporters of B and supporters of C, C wins.
    >
    > Sound like an unlikely scenario? Well, it's not, and I'm guessing you
    > know that.


    That kind of stupidity is precisely why so many projects fail or end up
    way behind schedule and over budget. Pick your favorite piece of
    vaporware -- maybe HL2:EP3, maybe that fancy new filesystem Vista was
    supposed to ship with but didn't, whatever. Probably this sort of idiocy
    is the reason for it.

    > A technical person who has found themselves in such an imbroglio has
    > failed


    The one thing they failed to do was get hired by somebody sane.

    > politically on several counts - they didn't do
    > their homework on what the approvers and real decision-makers think


    The approvers and real decision-makers should defer technical judgments
    to the people they hired for their technical expertise. When they
    micromanage, it hurts everyone, ultimately including the entire company
    they work for and everyone who works for it.

    > I've seen proposals postponed or cancelled for almost every political
    > (or emotional) reason in the book.


    By idiots. Smart businessmen make decisions for rational,
    what-will-bring-in-more-revenue reasons, not for emotional ones or to
    spite people or similar such stupidity.

    Stupid businessmen, on the other hand, might be susceptible to political
    tricks and other such nonsense, but which would you rather work for, a
    smart businessman that lets you do your job to the best of your ability,
    or a stupid one who wastes your time with this political nonsense, will
    screw you over if you are bad at it, and will eventually screw you over
    anyway because his stupid decisions will kill your project, bollix up
    the whole department, and ultimately sink the entire company? Working
    for a stupid businessman means being one recession (or zero) away from
    being back on the unemployment lines. I'd consider such a job
    effectively a temporary one.

    > In one case an influential approver was antagonistic to open-source
    > software


    Emotional, irrational decisions. Why would anyone want to work at a
    company that bases important technical decisions on irrational methods?
    The company's got exactly the same prospects for survival as one that
    based technical decisions on the results of reading tea leaves or pig
    entrails or consulting an astrologer or a Ouija board. If you choose to
    work for such a moron, you might as well choose to work at a job where
    every morning when you arrive you have to shake a Magic 8-Ball that's
    been modified so that one of the messages that can show up is "you're
    fired", and if it does, you're fired.

    > In another case a manager detected that a proposal would have made
    > serious inroads on his little fiefdom.


    His little fiefdom will not survive the bankruptcy of the company he
    works for, which will probably come quite soon after his stupidity sinks
    or cripples a key product in development and the competition begins to
    eat the company alive. He'll be lucky to get off with a "mere"
    restructuring of his department.

    > In all of these cases there were nuances as well. In the first case the
    > vendor officially supported over three-quarters of our installed
    > software. If we had replaced the small piece that was flawed with an
    > open-source implementation, the argument was that the vendor would have
    > refused to deal with any problems related to the entire stack. Not
    > inconceivable. That's political, but it's also a decent argument.


    The correct way to deal with that is to tell the vendor all about the
    flaws in the small piece, and if the vendor wouldn't do anything about
    that, go with the open source replacement for that component. And of
    course what the vendor doesn't know won't hurt it; no need to specify
    that that component was replaced. Just tell the vendor if some other
    component has problems what the inputs to it were and what the incorrect
    output was. If the output was clearly not what should have resulted from
    the inputs, the vendor can't very well argue, regardless of where those
    inputs actually came from.

    Unless the vendor is irrational, of course, in which case the vendor is
    going to turn into an anchor tied to your foot and drag you down sooner
    or later. Get one that isn't crazy, ASAP, or go open source for the
    whole stack, and then you can fix things yourself using in-house
    expertise or using a company like Red Hat that sells support services
    for open source systems.

    > In the other two cases I mention there were actually larger project
    > issues involved - possible retraining of internal staff, or hiring more
    > external people, extending deadlines etc.


    That seems to me to depend on what was being done. For example, with
    retraining of internal staff, the problem would be that some user
    interface was being changed. If the product being contemplated was well
    designed, the UI and the engine would be decoupled enough that the UI
    could be replaced or reconfigured so retraining wouldn't be needed
    (except maybe all those workarounds for annoying known bugs could be
    happily forgotten about). If the product being contemplated was not well
    designed, then it fails on the merits anyway.

    In the case of extending deadlines, it might be a case that the product
    could either be delivered on time and be seriously shoddy, or could be
    made very good but would be a few weeks late. Which is the better
    outcome? And what's the lesson to be learned? Pad all time estimates and
    never make a promise you can't keep.

    > And trying to sell all of that
    > to the people holding the purse strings. That's political too, but it's
    > real. *You*, the technical person, may be sold on the merits of
    > re-implementing application Y in technology Z, but good luck on selling
    > that in a typical bureaucratic environment.


    You shouldn't have to. The whole point in hiring the technical person is
    so that they have someone who actually knows that stuff to make
    technical decisions. Why hire a technical person and then make decisions
    about technology on the basis of politics and *emotion*? It's
    disrespectful to the technical person and a waste of their talents to
    hire them if you have no intention of actually using their expertise to
    help your organization.

    > This is all political stuff. And unless you're a software developer on
    > the bottom rung (and maybe not even then) you'll have a happier career
    > if you learn how to take it into account. You certainly don't have to,
    > but you'll end up frustrated and bitter if you don't.


    If you don't, AND work for the wrong sorts of people, perhaps.
     
    Dave Searles, Oct 3, 2009
    #17
  18. Tom Anderson

    Dave Searles Guest

    Patricia Shanahan wrote:
    > The very simplest political strategy for a skilled software developer
    > with weak political skills is to identify a very competent manager, and
    > finagle a job with that person as supervisor. That step may require a
    > little political skill, but enough technical skill may lead to the
    > manager also working the politics, with the same objective and a lot
    > more skill.


    That's what *should* go on *always* -- the technical people do the
    technical stuff and their immediate boss does the political stuff on
    behalf of that whole group, technical people included.

    The really annoying thing is seeing useless turf wars evolve within a
    company. That's a sure sign the end is nigh. A company exists to sell
    products and/or services and turn a profit; internally everything should
    be oriented to that goal. Any internal bickering or hoarding that
    benefits one department at the expense of the organization as a whole is
    parasitism; worse, it's cancer. Cancer kills. A company that wastes
    resources on internal fights, or on appeasing internal
    king-shits-of-turd-hill to avoid them, is ripe to be outcompeted by a
    company that does the same job more efficiently by avoiding that nonsense.

    This is probably why old companies tend to be consistently outmaneuvered
    by upstarts past a certain point: they develop internal cancers like
    these, internal managers or departments that feel entitled to the status
    quo or to special treatment of some sort. Then the company as a whole
    cannot compete and falls back on legalistic strategies -- lawsuits,
    lobbying the government, trying to get monopolies and/or bailouts etc.

    Part of the problem is the "golden parachute". Managers with one of
    these have much less reason to care if the company implodes and their
    job disappears behind its forming event horizon. They also feel
    entitled. And the company will often be willing to pay some small amount
    (perhaps in lost productivity rather than in money) to appease such a
    manager rather than pay the larger amount the parachute is worth to get
    rid of him and replace him with someone competent. The problem being
    that they will do this repeatedly, even when the cumulative amount
    keeping him costs the company exceeds the one-time cost of paying his
    severance.

    If I started a company tomorrow one policy would be "no golden
    parachutes". Honesty would be a key criterion in hiring people to do
    management-type stuff. Those that did well would be rewarded with a good
    salary and job security. Those that did poorly would wind up on the
    unemployment rolls exactly as if they were doing a bad job in the mail
    room or on the factory floor. Of course having had a manager's salary
    until then they'd probably have more socked away for a rainy day, and
    possibly stock options, but that's it. (And the stock options would of
    course become worthless if the company went into a nosedive on their
    watch. And if they bailed and cashed in the options and shares just
    before, and knowing one was coming, I'd sic the SEC on them for insider
    trading. See how you enjoy your "golden parachute" in jail, motherfucker!)

    Society may need to make some changes to how corporations are treated,
    legally, in the longer term to fix some of these ills. Right now,
    corporations are "virtual people" in a sense, but with only a subset of
    the rights and obligations of real people. These "virtual people" should
    probably be directly answerable to the courts -- companies currently can
    be sued, but they should probably also be susceptible to being charged
    as criminals. Sentences could include capital punishment: the company is
    disbanded by government and all trade marks, patents, and copyrights it
    held revert to the public domain; its other assets are sold at public
    auction and the government pockets however much of the proceeds are not
    needed to pay severance to everyone who worked there. All its documents
    such as memos become public knowledge (not just known to the government,
    but actually published) and lawsuits and indictments against individual
    people high up in the company can ensue. If the company is "executed"
    while involved in lawsuits, it automatically loses all of those as well.

    Lesser punishments would include fines or enforced disclosure of
    documents or "trade secrets", and perhaps loss of trademarks and
    similarly (say, if a trademark is persistently used in misleading
    advertisements, it can be forfeit).

    After such rules were instituted, there'd probably be exactly one more
    Enron-like scandal, and after the demonstration thus resulting,
    businesses would keep their business practises squeaky-clean.

    > In a manager-developer coalition, it's the manager's job to know the
    > non-technical objections to A, and either work out a way to counter
    > them, or decided they are unsurmountable.


    Is there ever a non-technical objection to a technical decision that
    truly matters? (Not to some management hack -- to the actual product
    being developed.)

    > Even if A has a chance, the developer should have been warned of the
    > risk of rejection of A, as well as the nature of the anti-A arguments,
    > and been fully prepared for the B vs. C discussion.


    Or better yet, the developer has a manager that he works *with*, not
    against. That manager gets the developer's input: A is way better than
    B, and B is better than C. That manager then goes to this meeting and
    pushes A over B and B over C, and strongly bats for A. If A is still
    rejected, then strongly bats for B.

    > 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.
     
    Dave Searles, Oct 3, 2009
    #18
  19. Dave Searles wrote:
    > Arved Sandstrom wrote:
    >> Dave Searles wrote:
    >>> Lew wrote:

    >> [ SNIP ]
    >>
    >>>> A good programmer with solid fundamentals can seem like an outright
    >>>> genius and coding machine by comparison. Just don't piss the peons
    >>>> off or they'll sabotage you politically.
    >>>
    >>> Politics is another skill that should not be demanded of an engineer.

    >>
    >> You'd best have some skill at politics if you wish to enjoy a
    >> successful career.

    >
    > Is that a threat?


    No, it's an English expression using the extremely common indefinite or
    general "you". As for the sentiments expressed, it's an observation as
    to the facts of life, idealistic thinking aside.

    [ SNIP ]
    >
    >> In all of these cases there were nuances as well. In the first case
    >> the vendor officially supported over three-quarters of our installed
    >> software. If we had replaced the small piece that was flawed with an
    >> open-source implementation, the argument was that the vendor would
    >> have refused to deal with any problems related to the entire stack.
    >> Not inconceivable. That's political, but it's also a decent argument.

    >
    > The correct way to deal with that is to tell the vendor all about the
    > flaws in the small piece, and if the vendor wouldn't do anything about
    > that, go with the open source replacement for that component. And of
    > course what the vendor doesn't know won't hurt it; no need to specify
    > that that component was replaced. Just tell the vendor if some other
    > component has problems what the inputs to it were and what the incorrect
    > output was. If the output was clearly not what should have resulted from
    > the inputs, the vendor can't very well argue, regardless of where those
    > inputs actually came from.


    Depends on the vendor involved. This particular vendor happens to be in
    the Top 5 of global IT companies by annual revenue, so if they intimate
    that support for problems with your installation of their software stack
    is contingent on not screwing around with that installation, including
    swapping out pieces for third-party software, it's probably a good idea
    to listen to 'em.

    > Unless the vendor is irrational, of course, in which case the vendor is
    > going to turn into an anchor tied to your foot and drag you down sooner
    > or later. Get one that isn't crazy, ASAP, or go open source for the
    > whole stack, and then you can fix things yourself using in-house
    > expertise or using a company like Red Hat that sells support services
    > for open source systems.


    As to the latter, a vendor like Red Hat sells support for _their_
    systems, OSS or otherwise. You'll get no further with them if you start
    monkeying around with what they recommend as stable configurations.

    As to using in-house expertise for fixing problems with your OSS, most
    organizations hire developers to tackle their business problems, not to
    spend time fixing defects in other peoples' programs. If it's a
    superficial problem, sure, go ahead and fix it. But if it's serious, how
    much time do you want one of your developers to divert from what they
    are really paid to do? IOW, you don't generally select a piece of
    third-party software because it's open-source, you select it because
    it's the best software for the job.

    >> In the other two cases I mention there were actually larger project
    >> issues involved - possible retraining of internal staff, or hiring
    >> more external people, extending deadlines etc.

    >
    > That seems to me to depend on what was being done. For example, with
    > retraining of internal staff, the problem would be that some user
    > interface was being changed. If the product being contemplated was well
    > designed, the UI and the engine would be decoupled enough that the UI
    > could be replaced or reconfigured so retraining wouldn't be needed
    > (except maybe all those workarounds for annoying known bugs could be
    > happily forgotten about). If the product being contemplated was not well
    > designed, then it fails on the merits anyway.
    >

    [ SNIP ]

    In this case there would have been technology changes involved. The
    internal staff would have been programmers and operations support. You
    don't lightly propose changing technologies, even if the target
    technology is a much better solution for the problem, without taking
    those kinds of resource issues into account.

    >> This is all political stuff. And unless you're a software developer on
    >> the bottom rung (and maybe not even then) you'll have a happier career
    >> if you learn how to take it into account. You certainly don't have to,
    >> but you'll end up frustrated and bitter if you don't.

    >
    > If you don't, AND work for the wrong sorts of people, perhaps.


    You'll never work for a company that has no politics.

    AHS
     
    Arved Sandstrom, Oct 3, 2009
    #19
  20. Tom Anderson

    Dave Searles Guest

    Arved Sandstrom wrote:
    > Dave Searles wrote:
    >> Arved Sandstrom wrote:
    >>> In all of these cases there were nuances as well. In the first case
    >>> the vendor officially supported over three-quarters of our installed
    >>> software. If we had replaced the small piece that was flawed with an
    >>> open-source implementation, the argument was that the vendor would
    >>> have refused to deal with any problems related to the entire stack.
    >>> Not inconceivable. That's political, but it's also a decent argument.

    >>
    >> The correct way to deal with that is to tell the vendor all about the
    >> flaws in the small piece, and if the vendor wouldn't do anything about
    >> that, go with the open source replacement for that component. And of
    >> course what the vendor doesn't know won't hurt it; no need to specify
    >> that that component was replaced. Just tell the vendor if some other
    >> component has problems what the inputs to it were and what the
    >> incorrect output was. If the output was clearly not what should have
    >> resulted from the inputs, the vendor can't very well argue, regardless
    >> of where those inputs actually came from.

    >
    > Depends on the vendor involved. This particular vendor happens to be in
    > the Top 5 of global IT companies by annual revenue, so if they intimate
    > that support for problems with your installation of their software stack
    > is contingent on not screwing around with that installation, including
    > swapping out pieces for third-party software, it's probably a good idea
    > to listen to 'em.


    In other words, they use a near-monopoly power to bully their customers
    around and make life difficult for them if they have a component acting
    wonky? This vendor's name wouldn't happen to be nine letters long and
    starting with an M, would it?

    >> Unless the vendor is irrational, of course, in which case the vendor
    >> is going to turn into an anchor tied to your foot and drag you down
    >> sooner or later. Get one that isn't crazy, ASAP, or go open source for
    >> the whole stack, and then you can fix things yourself using in-house
    >> expertise or using a company like Red Hat that sells support services
    >> for open source systems.

    >
    > As to the latter, a vendor like Red Hat sells support for _their_
    > systems, OSS or otherwise.


    The point being, you can use OSS and still be using something the vendor
    supports in this case.

    > IOW, you don't generally select a piece of
    > third-party software because it's open-source, you select it because
    > it's the best software for the job.


    But what is "the job"? It might include making it easier for you to
    self-support if you have to. Or it might not. It depends on what is
    meant by "the job" in a particular case.

    >>> In the other two cases I mention there were actually larger project
    >>> issues involved - possible retraining of internal staff, or hiring
    >>> more external people, extending deadlines etc.

    >>
    >> That seems to me to depend on what was being done. For example, with
    >> retraining of internal staff, the problem would be that some user
    >> interface was being changed. If the product being contemplated was
    >> well designed, the UI and the engine would be decoupled enough that
    >> the UI could be replaced or reconfigured so retraining wouldn't be
    >> needed (except maybe all those workarounds for annoying known bugs
    >> could be happily forgotten about). If the product being contemplated
    >> was not well designed, then it fails on the merits anyway.

    >
    > In this case there would have been technology changes involved. The
    > internal staff would have been programmers and operations support. You
    > don't lightly propose changing technologies, even if the target
    > technology is a much better solution for the problem, without taking
    > those kinds of resource issues into account.


    Then you may be sunk, stuck in a quagmire from having backed the wrong
    horse at some point. Maybe you backed Eiffel back in the day and then
    Java's what took off, for instance.

    >>> This is all political stuff. And unless you're a software developer
    >>> on the bottom rung (and maybe not even then) you'll have a happier
    >>> career if you learn how to take it into account. You certainly don't
    >>> have to, but you'll end up frustrated and bitter if you don't.

    >>
    >> If you don't, AND work for the wrong sorts of people, perhaps.

    >
    > You'll never work for a company that has no politics.


    I would think that a company that minimizes politics, or at least
    minimizes the collision of politics with the technical hires, will be
    able to outcompete any companies that don't. So if what you say is true,
    it is also probably an unstable state of affairs that will not last
    indefinitely. Like an excited quantum state or a stock market bubble,
    the bottom will drop out from under such a system eventually.
     
    Dave Searles, Oct 3, 2009
    #20
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Vishal Pandey

    Interview Questions

    Vishal Pandey, Nov 24, 2003, in forum: ASP .Net
    Replies:
    0
    Views:
    631
    Vishal Pandey
    Nov 24, 2003
  2. Namratha Shah \(Nasha\)
    Replies:
    0
    Views:
    2,679
    Namratha Shah \(Nasha\)
    Nov 4, 2004
  3. vpcs

    Interview in Perl

    vpcs, Aug 17, 2004, in forum: Perl
    Replies:
    0
    Views:
    600
  4. Jobs
    Replies:
    0
    Views:
    1,031
  5. reema
    Replies:
    0
    Views:
    301
    reema
    Aug 26, 2008
Loading...

Share This Page