Stories
Slash Boxes
Comments

SoylentNews is people

posted by martyb on Monday December 04 2017, @05:18PM   Printer-friendly
from the it's-easier-to-deal-with-computers-than-with-people dept.

The Do's and Don't's of Managing Programmers:

Why are some programmers such jerks?

Too many managers believe the problem lies with [the disgruntled programmer]. If he was a better employee, dedicated worker, or at least cared more, then this wouldn't happen. Right?

Unfortunately, no.

The first suggestions matter a lot
How you handle ideas from new programmers sends an important signal. Good or bad, it sets the stage for what they expect. This determines if they share more ideas in the future... or keep their mouth shut.

Sure, some ideas might not be feasible in your environment. Some might get put on the back burner to be discussed "when we're not busy". Some ideas seem great, but they run against unspoken cultural norms.

No matter what the reason, dismissing or devaluing your programmer's ideas — especially in the first few months — is a bad move.

Damaged by all the naysaying, he'll try a few more times to present his ideas differently, aiming for a successful outcome. If he continues to feel punished, though, he'll realize that the only way to win is not to play.

Which is exactly what you don't want your programmers learning.

He will stop presenting ideas, asking to meet customers, and genuinely trying to understand the business.

Ultimately, it's a lose lose.

If you want programmers to become mere code monkeys, treat them like code monkeys.


Original Submission

 
This discussion has been archived. No new comments can be posted.
Display Options Threshold/Breakthrough Mark All as Read Mark All as Unread
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
  • (Score: 2) by fyngyrz on Monday December 04 2017, @11:13PM (5 children)

    by fyngyrz (6567) on Monday December 04 2017, @11:13PM (#605384) Journal

    Service is the new thing

    I disagree. You know, if you do two things (that you really ought to be doing anyway):

    1. Write clean, non-buggy code that informatively empowers the user
    2. Write good documentation

    Then there's very little – or no – service required.

    "The service economy" usually implies you've blown one of those two goals.

    Basically, if you write good freeware and/or open source, and document it well, most (perhaps all) of the money you'll make will be of the nature of charitable contributions. And there won't be a lot of that, compared to the effort you'll spend, unless your software is crazy popular. I develop a free application that is basically in the top of the heap for what it is, with thousands of current users, been out there in various incarnations since 2011. Total income from contributions has been (as of today) $870.00 from 21 contributors. Luckily, I didn't write it to get income (I wrote it for me, really, I use it every day), but it'd be nice, of course. I do get lots of complements on both the application and the documentation. But you can't eat those.

    TL;DR: "If it's not broken, you won't have to fix it; if you've already answered all the questions, you (or your FAQ) can just point to the answers."

    There are exceptions, particularly when bitrot from Apple or Microsoft or Qt breaks the hell out of things that were fine before. The best way around that is to write your own code instead of depending on them, as much as is possible. Lots of work. Much less support required.

    Starting Score:    1  point
    Karma-Bonus Modifier   +1  

    Total Score:   2  
  • (Score: 1, Insightful) by Anonymous Coward on Monday December 04 2017, @11:35PM (1 child)

    by Anonymous Coward on Monday December 04 2017, @11:35PM (#605398)

    TL;DR: Programmers will starve.

    Thank the blessed Stall-Man.

    • (Score: 2) by c0lo on Tuesday December 05 2017, @08:10AM

      by c0lo (156) Subscriber Badge on Tuesday December 05 2017, @08:10AM (#605544) Journal

      TL;DR: Programmers will starve.
      Thank the blessed Stall-Man.

      Open source has nothing to do with your inability to get a job. Even if no-one would make their source code available, when there are too little jobs for too many code monkeys, some code monkeys will starve.

      Give it a try: write a mobile app and drop it on the appropriate shop. Dont release the sources, see how much money you'll get from it. Good luck.

      --
      https://www.youtube.com/watch?v=aoFiw2jMy-0 https://soylentnews.org/~MichaelDavidCrawford
  • (Score: 2) by TheRaven on Tuesday December 05 2017, @02:23PM (2 children)

    by TheRaven (270) on Tuesday December 05 2017, @02:23PM (#605632) Journal

    That assumes that the software already does everything that the user wants. This is basically only ever true for trivial utilities. Support (at least, the well paid version) doesn't mean helping the user use the software as written, it means adapting the off-the-shelf software that's working well for one use case to another specific to this user. That's what companies like IBM and SAP get paid big money for.

    Think of it this way: software is basically free to duplicate, but a lot of effort to write. Do you think it makes more sense to have an economic model where people write the software for free and then try to make back the cost by selling copies, or one where users pay developers to write the software and can then make and distribute as many copies as they want?

    --
    sudo mod me up
    • (Score: 2) by fyngyrz on Tuesday December 05 2017, @11:11PM

      by fyngyrz (6567) on Tuesday December 05 2017, @11:11PM (#605873) Journal

      Do you think it makes more sense to have an economic model where people write the software for free and then try to make back the cost by selling copies, or one where users pay developers to write the software and can then make and distribute as many copies as they want?

      Personally, I think it makes the most – but different kinds of – sense to write:

      • closed source, fee-for-purchase if you want to earn from it, or...
      • true open source (meaning, completely free, not GPL, which I think is an utter travesty and won't do) if you want to be charitable.

      I think both are perfectly okay (and I do both.) I even think its okay to do GPL or some other restrictive license stuff if that's what you want to do. Whatever floats your boat. But the consequences tend ot be very predictable, because...

      There isn't actually an economic overlap that generally applies.

      If you want to make money, open source is about as likely a means to get you there as being a high paid basketball star or high paid movie star is just because you play basketball or like to act. Yeah, some very few people make it, but the odds very clearly say any particular individual almost certainly won't.

      And as for those moments of fame that recent generations seem to covet so... you can't eat fame. And fans can be really annoying. So to me, it's worthless.

      I can also say that the reason I got to choose to retire at 40 and got to do whatever I wanted since then was because I chose the closed source, for-fee software path, and my company made stuff people wanted to buy.

      This has been my experience. Times do change, and perhaps it's all different now and I am just oblivious... but I'm not really seeing that in the market.

    • (Score: 2) by fyngyrz on Tuesday December 05 2017, @11:16PM

      by fyngyrz (6567) on Tuesday December 05 2017, @11:16PM (#605878) Journal

      That assumes that the software already does everything that the user wants.

      No, it doesn't. That's not support of individuals, that's evolution of the software. If your software doesn't evolve and grow, doesn't matter if it's free or for-fee; it's going to get left beside the road with all the other dead products.

      I add features all the time. Sometimes on a daily basis. I'm careful not to obsolete what's already there, or break it (ya gotta love automated testing), but in my area, sure there are always more features to add. Doesn't mean the new features need support, or that they are support. It's just product growth. If you charge for new features, you might as well charge for old ones. Same thing – just hiding under an excuse.