• abcxyzeieio (unregistered)

    On a related topic, I'd just like to identify the practice of "pair programming" as a highly effective knowledge transfer mechanism for getting new people up to speed and maintaining the continuity of productive team cultures - besides such niceties as improving quality and letting your team be very responsive to sudden demands (and having very low turn-around times).

    This investment in human capital is one of the key reasons that it's worth it to assign two people to the same task at once.

  • Anonymous (unregistered)

    You know, I've thought about this for a few days. My first reaction was, "this isn't quite right."

    This is really just one of those attention-whoring blogger stunts to get traffic and attention focused on the person behind the words. This isn't new; I've seen bloggers claim that "goto isn't harmful - Dijkstra was full of it!" for the same effect. The pattern is that the blogger makes some outlandish claim, people respond to it because it is utterly absurd, and the blogger rolls in the attention. I believe this is loosely the definition of trolling. (Which means, I guess, that I'm feeding the troll....meh)

    The major breakdown with this idea is that it focuses all the fault for changes in job satisfaction on the employee. At no point does it mention that management could possibly have anything to do with good developers leaving. Seriously, you get management that forces really bad technical decisions (i.e. outsourcing, skipping QA, bad design, etc) and developers start getting unhappy. Why? Well, who the hell is it that gets to take the call in the middle of the night to fix something that they were forced to half-ass?

    Management's lack of interest in the growth of the employee is also a good reason to leave. Why wouldn't an employer find value in letting employees get educated on new things? It doesn't even mean the employer has to pay for it; all they need to do is support it. Most employers don't do that.

    Cutting benefits/workforce is also a big factor. When the CEO is telling everyone what a record quarter/year the company is doing while giving shit benefits and making everyone do the job of 3 people, developers are going to flee. If you're making so much money, why in the hell don't you spend it on making it so I don't have to work 12 hours a day? How about the fact that I avoid the doctor/dentist because my good benefits were replaced with a bad set of benefits to save money?

    Nice graphs, but loosely referencing a few ideas from academia and then making up some graphs with no references doesn't count. I hope no one takes this crap seriously.

  • Joel (unregistered) in reply to seebs

    I agree. There is a lot to be said for the benefits of having a good team working together for a long period of time.

    Just as there is the generalization that people who stay with a company are the least talented folks writing crap, there is the generalization that those who job hop are disloyal, self serving, egotistical %#&*)^^%s who write crap code and get out before it blows up.

  • me (unregistered)

    whats the wtf?

  • (cs) in reply to me

    There are 2 WTFs here:

    1. that the IASA, a company which purports to be for IT architects, doesn't actually say anywhere that I could find on their homepage, what IASA stands for.

    b) that so many people are giving feedback about the topic 'a culture of quitting' without reading the original article. All kinds of crap about 1 year stints here, and quitting just as soon as you learn to contribute, etc. The original article talks about 3-5 years of usefulness before moving on, unless you are working on moving up (making partner). So yeah, knee-jerk retarded comments.

Leave a comment on “Announcement: A Culture of Quitting, The Webinar”

Log In or post as a guest

Replying to comment #:

« Return to Article