Which of these two programmers is "better", from a managerial standpoint?

The first programmer is Albert. You tell Al to make a system that will pass you the salt at the dinner table. He does it in less than a day. It works fine.

The second programmer is Ben. Ben is told to make a program to pass the salt, and after two days, he's still working on it.

The General Problem

It will save time in the long run...if you need pepper, ketchup, etc. There isn't any clear indication that there will be a need for this, but it's not improbable.

Who's the better programmer to have working under you, as a manager?

  • What about Cane? I don't see his point.
    – Noname
    Apr 14 '12 at 3:47
  • What do you think Cane would say, @Dave? Mind weighing in with a comment/answer?
    – Droogans
    Apr 14 '12 at 3:50
  • possible duplicate of Writing robust code vs. overengineering
    – rwong
    Apr 14 '12 at 4:00
  • I have not quite got the question, speaking of the third guy.
    – Noname
    Apr 14 '12 at 4:21
  • 1
    impossible to answer, unless you paint what will happen after Al is told to also pass pepper, mustard, horseradish and a little can of beer
    – gnat
    Apr 14 '12 at 4:42

The first programmer is better.

YAGNI is in play, and a program that passes arbitrary condiments isn't worth 200% more in the face of requirements that requested a program that passes salt.

  • 1
    Yep. Why does everyone assume that the salt-only solution is bad? Think of the unix model of small simple programs that do one thing on text file/stream input and do it well. Do we blame a fork because it isn't a knife? But we do in programming, people are always trying to make a tool a Swiss army knife (which isn't really good at anything it does).
    – anon
    Apr 15 '12 at 2:33

I would say that it depends entirely on the nature of your business and the type of client relations you have.

Do you or your client have a pressing pressing "salt at the dinner table" need? Do you or your client often need condiments of other sorts? Do you or your client have a history of needing "just this one thing" and then needing that "just one thing" turned into "any of this set of things"?

I'm sure you can see what those questions are pointing to. From a managerial standpoint, or more specifically from a business interest standpoint - the real answer is whichever developer is better for the long term profitability of your company. And there isn't a hard and fast rule for that.

Considering the ambiguities in real-world scenarios like this, I would say the correct answer is "both" - you generally would want to make sure you have people on your team who can "get it done right now" for when "right now" is important. AND you want people who can get it done "right" for when maintainability is important. Rarely, you can find individuals who're capable of both - cherish them.

Developers who are in the extreme (either end of the "right"->"right now" gradient) and put into the opposite need situation generally do horribly. Give a well experienced, abstract thinker a "get it done quick and dirty" job and they'll often flub it. Give a "gets it done with baling wire and scotch tape" developer the role of planning and maintaining a complex product and you often end up with spaghetti tangles of doom.

  • 1
    +1 for stepping back to look at the real problem. And for “spaghetti tangles of doom”; I love that phrase! Apr 14 '12 at 7:26
  • Im glad you noticed the lack of details, but answered anyway. Ill try to remeber to break off 'one fix' code from any sections that 'could go anywhere', and do both when the time calls.
    – Droogans
    Apr 14 '12 at 12:00

It depends.

  • Is the manager a control freak?
  • Is the manager also a programmer?

Programmers working under you, in general, shouldn't take a stroll into uncharted zones without first discussing the matter with you.

Then, you, the manager, could be utterly incompetent and unable to discern the matter at hand, thus pushing your un-managed programmer to do his own core design decisions.

There, your managed programmer is now his own architect, and he's struggling with your made up deadlines, (ASAP isn't a reasonable deadline, you know) and has a lot of burden on him, more than he can probably handle, and this will probably backfire sooner or later.

So, it's never a good symptom. If it starts happening over and over:

  • your programmer could be incredibly naive and/or have very poor communication skills
    • then he should get proper training
  • your manager could be incredibly inept and should be removed from the project
    • the programmer then, could be managing material:
      • he runs late, but does he meets the deadlines?
      • does the codebase makes more sense since he put his paws on it?

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.