• (cs) in reply to PSWorx
    PSWorx:
    Angostura:
    He should have fired the people who didn't know when to use 'less' and when to use 'fewer' in a sentence. >cough<

    Vi is much better than Less actually.

    Only for editing. If you just want to view the document, Less loads faster.

  • gnolm (unregistered)

    A year ago, I tried to convince my boss that we dont need a productivity measurement for us developers. Every time he came with an idea how we could do it, I had top show him how it would not work. He kept telling us: "...but the upper management demands this!" He is a bit clueless anyway. But smiling while wearing a suit every day did the trick for him ...

    After 6 month or so he gave up. Mainly because he himself got a new boss, which I had a small talk shortly after we employed him (he had a small chat with most of us. kind of cool). He was smart enough to understand my point of view. And since I attend interviews now, we are not employing any more douchbags that much.

  • (cs)

    indent (or perhaps better, artistic style) is much better at generating diffs that:

    1. doesn't break anything

    and

    1. look like some real code actually changed

    In fact, with astyle, you can easily change the metric to "size of commit" instead of "number of commits," and still come out ahead!

  • (cs) in reply to Ken B
    Ken B:
    PSWorx:
    Angostura:
    He should have fired the people who didn't know when to use 'less' and when to use 'fewer' in a sentence. >cough<
    Vi is much better than Less actually.
    Okay, it's time to shut down my computer and get a good rest.

    After reading the above comment, I wanted to close the TDWTF tab and typed ":wq"

    I only need to use Word very, very occasionally. I cannot say the amount of times I've tried to save a Word document by using the Visual Studio "build" Control+Shift+B.

    Go figure.

  • Unit 73 (unregistered) in reply to PSWorx
    PSWorx:
    Angostura:
    He should have fired the people who didn't know when to use 'less' and when to use 'fewer' in a sentence. >cough<

    Vi is much better than Less actually.

    Wow, you can pipe through vi now? Vim has really bought a lot more power to this editor... <smiley/>

  • (cs) in reply to akatherder
    akatherder:
    Things like this need to be part of a manager's curriculum in college.

    #1 You just realized that your subordinates are checking files in to increase their stats, do you:

    A. Pat yourself on the back for increasing productivity. Report success to superiors. B. Realize the error of your ways and discontinue using check-ins as a productivity metric. C. Get pissed at employees for being dishonest and checking-in needless changes to pad their stats. Discipline follows. D. WHY ARE THEY USING CHECK-INS TO MEASURE PRODUCTIVITY!?

    E. FILE_NOT_FOUND F. ... G. PROFIT

    Two birds with one comment!

  • DirtyCar (unregistered) in reply to real_aardvark
    real_aardvark:
    plus you can download a great film and watch a rather good-looking young lady wash windscreens with interesting parts of her body.

    What is this film that you mention?

  • (cs) in reply to anon
    anon:
    I'd so suck by these measures, I'm lucky to check in something once every couple weeks. It took them a while to finally get me to use svn at all. Some of the people I work with haven't quite gotten to even that point yet.

    I do non-production coding in non-officially by company supported languages, I'm the only one who will ever use any of this code 99.9% and 99% of the time the code won't ever be used in the future. There is already a backup program running on the code and I'm lazy.

    Granted the people who write normal code all use svn and so on.

    There is no non-production code. If in-house developed code used as part of company work processes then it is production code. Period. It does not matter if it is used only once and only by yourself.

    Consider svn a vastly emhanced backup program. Run a daily svn check-in script over all your code created/modified that day and you have your backup even if you dislike manual check-ins.

  • (cs) in reply to akatherder
    akatherder:
    Things like this need to be part of a manager's curriculum in college.

    #1 You just realized that your subordinates are checking files in to increase their stats, do you:

    ... SNIP ... C. Get pissed at employees for being dishonest and checking-in needless changes to pad their stats. Discipline follows. ... SNIP ....

    In what world am I being dishonest by checking in my source code ? I mean, I am not the PHB who decided to do measure a(meaningless) process metric.

    On another note: That PHB is problably planning to skip the company anyway. Just waiting until the end of the year, getting his performance bonus and then skips. After him the Deluge.

  • (cs) in reply to Ken B
    Ken B:
    PSWorx:
    Angostura:
    He should have fired the people who didn't know when to use 'less' and when to use 'fewer' in a sentence. >cough<
    Vi is much better than Less actually.
    Okay, it's time to shut down my computer and get a good rest.

    After reading the above comment, I wanted to close the TDWTF tab and typed ":wq"

    Just "ZZ" - is faster.

  • (cs)

    And the moral of the story is... don't count your checkins before they hatch.

  • (cs) in reply to real_aardvark
    real_aardvark:
    PS Can I just wreck the entire premise of my own comment by pointing out that you can get into vi mode from less by typing "v"?

    No. There is no "vi mode" in less, "v" launches the editor that the VISUAL environment variable is pointing to, or, if it's not set, EDITOR.

    Also, the underlying editor of vi is ex, not ed.

    P.S. ed rules. Did you know GNU ed is under active development?

    P.P.S. ePeen += 10cm;

  • ClaudeSuck.de (unregistered)

    I think I wouldn't stay there for long. With a boss as stupid at that I'd be frustrated all day. I liked especially that one:

    He was wasting a lot of time writing code; time that should be spent checking code in.

  • MooseBrains (unregistered)

    Let me submit a friend-of-a-friend's work colleague's CVS diff. This is one of about 200 commits over several days. And, yes, the comment is:

    "Made more generic/formatting/javadoc/checkstyle"

    http://i25.tinypic.com/dvjaq0.jpg

  • Joel (unregistered)

    Obviously "Milo" either didn't realize or didn't care that SVN gradually gets slower the more commits there are (SVN stores a separate file for each revision in a single directory).

    I hope I never have to work on the same repository as some of the people here who are trying to one-up each other on ways to generate the most commits.

    The real WTF is that Milo didn't muster up a little bit of people skill and explain tactfully why commits are a bad way to measure performance and instead created a system that would slowly cripple the performance of their SVN server and did nothing to disabuse his superior of his misunderstanding of programmer performance. Furthermore, it is a true WTF that he participated in fostering ill will between management and his co-workers when he could have done just the opposite.

  • Ovidiu (unregistered) in reply to real_aardvark
    I'd pick a file nobody else is every likely to use, called something like "Test23_Nov99_Y2K_1234", and write a simple program in perl to add a space to the end of each line (up to 1024 characters -- I'm not greedy, and Subversion might notice), followed by committing it. Then, I'd run it every ten seconds while I got on with my work.
    Yes, but someone might notice the line of empty spaces. A much better (and stealthier) approach would be to add a space, commit, delete the space, commit, add the pace again, commit, and so forth.
  • (cs) in reply to DirtyCar
    DirtyCar:
    What is this film that you mention?
    Cool Hand Luke

    http://www.imdb.com/title/tt0061512/

  • Bruteforce (unregistered) in reply to Ovidiu
    Ovidiu:
    I'd pick a file nobody else is every likely to use, called something like "Test23_Nov99_Y2K_1234", and write a simple program in perl to add a space to the end of each line (up to 1024 characters -- I'm not greedy, and Subversion might notice), followed by committing it. Then, I'd run it every ten seconds while I got on with my work.
    Yes, but someone might notice the line of empty spaces. A much better (and stealthier) approach would be to add a space, commit, delete the space, commit, add the pace again, commit, and so forth.

    Which is as easy to catch with a svn diff as just appending spaces.

  • Douchebag (unregistered) in reply to gnolm
    gnolm:
    A year ago, I tried to convince my boss that we dont need a productivity measurement for us developers. Every time he came with an idea how we could do it, I had top show him how it would not work. He kept telling us: "...but the upper management demands this!" He is a bit clueless anyway. But smiling while wearing a suit every day did the trick for him ...

    After 6 month or so he gave up. Mainly because he himself got a new boss, which I had a small talk shortly after we employed him (he had a small chat with most of us. kind of cool). He was smart enough to understand my point of view. And since I attend interviews now, we are not employing any more douchbags that much.

    Just the one, evidently.

  • Ovidiu (unregistered) in reply to Bruteforce
    Bruteforce:
    Ovidiu:
    I'd pick a file nobody else is every likely to use, called something like "Test23_Nov99_Y2K_1234", and write a simple program in perl to add a space to the end of each line (up to 1024 characters -- I'm not greedy, and Subversion might notice), followed by committing it. Then, I'd run it every ten seconds while I got on with my work.
    Yes, but someone might notice the line of empty spaces. A much better (and stealthier) approach would be to add a space, commit, delete the space, commit, add the pace again, commit, and so forth.

    Which is as easy to catch with a svn diff as just appending spaces.

    True, but at least this way you have an excuse : "I couldn't decide which version looks better, with or without the space ... and we all know that productivity is so much higher when the code you work on looks good." .

    Granted, you'd still have to explain why it took you 20,000 commits to decide. :)

    CATCHPA: damnum . Latin profanity ?

  • Maros (unregistered)

    Why wouldn't this work? Measure the combination of:

    1. Number of check-ins.
    2. Number of new lines of code.
    3. New warnings in static code quality analysis.
    4. RescueTime-like monitoring. Weekly reviews of check-ined code are also possible.
  • Veni (unregistered) in reply to SuperousOxide
    SuperousOxide:
    Too much work. Just add a new file to repository "work.txt", then dump random data to it and check in. Repeat!
    work.txt?? No, you need to chcki-in /dev/random Who knows what could happen if you hadn't versioned the random data used?

    Sadly, it changes fast, so you need a continous check-in process to avoid the versioning having stale data.

  • Dave (unregistered)

    I can appreciate that many managers in the IT industry come from biscuit factories or whereever and have absolutely no understanding of how computers work or how software is developed, but surely Greg's boss could be discretely informed as to how his subordinates are managing his projects.

    CAPTCHA: Uh....huh huh...he said genitus...

  • (cs) in reply to Spectre
    Spectre:
    real_aardvark:
    PS Can I just wreck the entire premise of my own comment by pointing out that you can get into vi mode from less by typing "v"?

    No. There is no "vi mode" in less, "v" launches the editor that the VISUAL environment variable is pointing to, or, if it's not set, EDITOR.

    Also, the underlying editor of vi is ex, not ed.

    P.S. ed rules. Did you know GNU ed is under active development?

    P.P.S. ePeen += 10cm;

    mea culpa, both times.

    On the other hand, if (like me) you avoid environment variables wherever possible, typing v inside less will still launch vi (at least on cygwin here -- somebody may have snuck in VISUAL or EDITOR on my linux/solaris workstations while I wasn't looking). As far as I'm concerned, therefore, the two are identical.

    I wish I'd got the underlying editor correct, though. That would have been much funnier if I'd said, "Trust me, you do not want to talk to Ex."

  • (cs) in reply to Maros
    Maros:
    Why wouldn't this work? Measure the combination of: 1. Number of check-ins. 2. Number of new lines of code. 3. New warnings in static code quality analysis. 4. RescueTime-like monitoring. Weekly reviews of check-ined code are also possible.
    Only if you can check out the checked-in code -- which, with everybody using my method every ten seconds, is highly unlikely.
  • (cs)

    Wow. Your manager actually knows how to use Subversion and inspect commit statistics?

    Do you have an open position at your company?

  • Franz Kafka (unregistered) in reply to anon
    anon:
    I'd so suck by these measures, I'm lucky to check in something once every couple weeks. It took them a while to finally get me to use svn at all. Some of the people I work with haven't quite gotten to even that point yet.

    They don't check stuff in? If they don't check in, the code doesn't exist. If it doesn't exist, then they don't do anything (Assuming software devs).

  • Kuba (unregistered) in reply to Joel
    Joel:
    Obviously "Milo" either didn't realize or didn't care that SVN gradually gets slower the more commits there are (SVN stores a separate file for each revision in a single directory).

    Oh well, just use a filesystem that doesn't suck.

  • zzp (unregistered) in reply to real_aardvark
    I'd pick a file nobody else is every likely to use, called something like "Test23_Nov99_Y2K_1234", and write a simple program in perl to add a space to the end of each line (up to 1024 characters -- I'm not greedy, and Subversion might notice),

    You wrote a Perl script ?! Learn sed dude :)

    $ sed -i -e '1,1024 s,$, ,g' file
  • (cs) in reply to zzp
    zzp:
    I'd pick a file nobody else is every likely to use, called something like "Test23_Nov99_Y2K_1234", and write a simple program in perl to add a space to the end of each line (up to 1024 characters -- I'm not greedy, and Subversion might notice),

    You wrote a Perl script ?! Learn sed dude :)

    $ sed -i -e '1,1024 s,$, ,g' file
    Let me rephrase my solution.

    "... and write a simple program in perl to add a space to the end of a single line (that line being round-robined through the file, and thus different between successive executions of the program) ..."

    Why on earth would anybody choose to add a space to every single line (OK, arbitrarily the first 1024)? Why on earth would anybody assume the presence of sed on all the development machines?

    Bit too complicated for a sed programmer, I suppose.

  • (cs) in reply to Jay
    Jay:
    A company I worked for years ago talked about rating programmers by lines of code. It never happened, which is too bad, because I had all sorts of ideas on how to boost my lines-of-code output.
    1. "x=x+4"? How inefficient. Much beter to write:
    x=x+1;
x=x+1;
x=x+1;
x=x+1;
    I think Lotus Notes was written this way.
  • Man 987876980 (unregistered)

    If you wanted to be productive in terms of check-ins and actual work, some script that automatically checks in a file every time you save it would be handy. You could even couple this with an auto-save mechanism.

    This way, you might manage to be productive AND meet a deadline.

  • Vartan Simonian (unregistered) in reply to real_aardvark

    The problem is you'll never get to the profit, because you keep repeating the first part of your plan.

  • Vartan Simonian (unregistered) in reply to Vartan Simonian

    Meant to reply to the quoted post, sorry about that.

Leave a comment on “Productivity 2.0”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article