
Are Your Programmers Working Hard, Or Are They Lazy? - cryptoz
http://mikehadlow.blogspot.co.uk/2013/12/are-your-programmers-working-hard-or.html
======
ChuckMcM
FWIW, Google tried to avoid this scenario with 'snippets' which everyone was
supposed to do every day. Basically you posted a snippet of what you were
thinking about / working on that day which gave folks evaluating you some idea
of what was going on in your head at any given time. (note that snippets were
world readable)

Unfortunately, when I was there, there wasn't a lot of protection from the
conflict created by your snippets, so if you wrote "tried again to convince
team X to let me fix their code, they brought up objection a, b, c. Still no
clarity from them on what they really want." In your snippet it would make
Team X look bad, and at some point it could come back to them that you were
bitching about them in your snippets (even if you were doing what you were
told to do) and then they would counter-attack in their snippets, and a little
sub-surface adhominem would go on for a while. Moderating your snippets made
you look non-productive. It was an epic failure in leadership.

~~~
tensafefrogs
No, Google uses the OKR (Objectives and Key Results) system to track
performance. You set goals with measurable results, and you grade them every
quarter.

That way you aren't evaluated so much on when/how you work, but on what you
accomplish.

(I should also include a note here about how you are evaluated by your peers
at Google, which has its own set of benefits and downsides, but OKRs are meant
to be a somewhat objective measure of output)

~~~
munificent
Everything about your post is correct except the "No,". Googlers have both
OKRs and snippets.

~~~
tensafefrogs
The "no" was directed at this statement, which I believe to be not very
accurate:

> Google tried to avoid this scenario with 'snippets'

My point is that OKRs are meant to be used for tracking performance (such as
what the article was talking about) and snippets are more for personal use or
casually for information among teammates or other curious people who want to
know what you work on.

------
jxf
> When people are doing a physical task, it’s easy to assess how hard they are
> working. You can see the physical movement, the sweat. You also see the
> result of their work: the brick wall rising, the hole in the ground getting
> bigger. Recognising and rewarding hard work is a pretty fundamental human
> instinct, it is one of the reasons we find endurance sports so fascinating.

We've all heard about the stereotypical manager-perception of "effort invested
will be proportional to results delivered!", like the article laments. But
this analogy breaks down really quickly.

Let's use an example that's not from software to illustrate the point -- in
fact, let's use the author's own example, laying bricks. Who would you rather
hire?

\-- Bricklayer A: Takes 2 weeks to finish a wall, stays late every day to
finish the job, finally builds a brick wall of passable quality.

\-- Bricklayer B: Finishes your wall in two hours because he realizes there's
a better way to lay your bricks, and builds a wall of excellent quality.

I feel like most people, even managers of non-software folks, would rather
hire B. At least, I certainly would.

So I think the premise of the article is wrong. There's something deeper going
on, and dismissing it with "managers want to reward hard work, and creatives
don't look like they're working hard" is an explanation that is "neat, simple,
and wrong" [0].

[0]:
[http://en.wikiquote.org/wiki/H._L._Mencken](http://en.wikiquote.org/wiki/H._L._Mencken)

~~~
markkanof
I completely agree with your conclusion that almost everyone would like to
hire Bricklayer B, but I think the disconnect in most work situations comes in
rewarding the value provided by that person. If for example both workers would
charge 5000 dollars to build the wall, people would be much more skeptical of
paying Bricklayer B, because after all, it was only two hours of work.
Basically people still have trouble evaluating the value of the work done vs
the effort expended to do that work.

~~~
Avenger42
It depends - if everyone knew that B would provide a superior wall, in less
time, for the same money, then they'd have a choice to make. Do I care about
the build quality? Do I care about the time?

A better example is if A now comes back and says "yes, my wall's not as good,
and I take longer, but now I'm only going to charge $4000", then you've got a
bigger question - is it worth $1000 to you to get a higher quality wall that's
done quicker? Or would you rather save the money and lose the time and build
quality?

This more easily converts to a software example - do you pay a senior
developer to develop your product quickly and well? Or do you save money by
hiring a developer of lower skill, who will likely take longer and deliver a
lower-quality product?

~~~
deegles
You're making a key assumption that a person is capable of evaluating the
skill of a developer and the quality of the end-result.

What if you have no background in software? If the lower-skill developer
convinces you his work is better (even if it's not) you're going to go with
him.

~~~
zevyoura
Even if you do have a background in software, evaluating talent is difficult;
it's why the interview process can be so convoluted.

------
fotbr
Another point of anecdata:

Once upon a time, early in my career, I spent half a day automating and error-
proofing a 15 minute task. My boss, at the time, was slightly annoyed, and
slightly amused. Fast forward two months from that point, and that same task
needs to be done not once, but several thousand times. My boss wanted to go
get coffee before we got started, so while he was grabbing his wallet, I fired
up my automated process. By the time we got back, the task was done, and the
boss was annoyed at himself for being annoyed earlier, and never again
questioned why I built the systems I did. I, unfortunately, was too young and
too inexperienced to realize that he was an excellent boss, and left a couple
years later for "greener pastures", where I encountered many "productivity is
measured entirely by the time you sit at your desk" bosses.

TL;DR: I work hard to look this lazy, had a boss that recognized it, and was
too dumb to realize how good I had it.

~~~
avalaunch
It could be that you prematurely optimized the task and then got lucky that
the optimization turned out to be necessary later on. Your story reads as if
you are saying that you were correct to automate the task because later you
happened to need the automation, despite not having any reason to believe that
automation would be needed. ie. Buying a lottery ticket was perfectly
reasonable because I happened to win.

That being said, based on the numbers given, the optimization would make sense
as long as you knew the task would be needed to be done at least 16 more
times, which I imagine was the case. That also assumes there wasn't anything
more pressing that needed to be worked on.

~~~
GFischer
There's a cool chart on xkcd estimating the max time you should spend
automating something based on its frequency:

[http://xkcd.com/1205/](http://xkcd.com/1205/)

~~~
dhimes
Optimizing optimization. Terrific! Complete with extra-verbose mouseover text
just to make the point.

Of course, it leaves off a benefits of the particular type of optimizing that
is automation, such as (1) reducing errors in task performance, and,
admittedly a little more abstractly, (2) the ability to produce new
efficiencies you may not have anticipated until you started automating. Kind
of like writing a function only to discover that it's re-usable.

------
Kapura
After reading this story, it's remarkable how much it reminds me of my own
experience. I worked for Amazon.com as an intern for 3 months, then at the end
I wasn't offered the position. They said that I showed "excellent technical
skill," but they didn't feel that I embodied an Amazon.com employee. One
specific criticism was that "For some of the interns, it was difficult to get
them to stop working and go home. Not so for [me]."

I figured out the system mostly independently, because the senior developers
were always under fire due to the over-large workload for our team. So while
other interns would need help for an hour or two every few days, I'd ask
something about the data type of a certain value in a function and be on my
way. My mentor was especially impressed, but he was the only one because
nobody else saw how much code I was writing or its quality. They would just
see me getting up to pace about when the problem was very difficult, or
opening up hn when I needed to give my brain a break.

Long story short, my manager said that they weren't going to hire me full
time, which came as a shock because I thought that producing quality code to
the deadline was the important part. He cited early mistakes in writing
documentation (I'd never written a functional spec before the internship, but
I posit what I eventually produced was of the highest quality) and my
perceived lack of motivation. This despite me working as well and
energetically as I ever had. I decided to look at it through a lens of another
article I'd read on HN: Any company that doesn't want to hire me is a company
I probably don't want to work for.

So while I'm dismayed that this pattern will continue, it's nice to know that
there are some people who know the difference between a good programmer and
one who puts in overlong hours.

~~~
grecy
I'm convinced that "playing the game" and "office politics" are much more
about being seen to be working hard (or the illusion of it) than actually
getting stuff done well.

Even if you can churn out more quality output in 4 hours than your peers can
in 8, you better make sure you're seen to be working hard for those entire 8
hours, and make sure to continually mention to everyone possible just how hard
you are working at all times.

~~~
paul_f
Once you've learned how to "look busy", you've got it made.

~~~
elohesra
This isn't necessary. Just notify your immediate manager every time you hit a
milestone (e.g. complete a piece of assigned work), and notify them every time
you've run out of work.

Part of the issue with the perception of developer effort seems to be the fact
that the developers aren't communicating their success to the manager. The
manager _sees_ the failures (admittedly he fails to recognise them as
failures), because they're working late and looking stressed. The manager
doesn't see the successes, because he fails to understand what success looks
like.

The solution isn't to emulate a failure, the solution is to educate the
manager (through gentle notifications of work done) as to what success looks
like.

------
austenallred
This is, I think, a very relevant case for the "Non-technical co-founders need
to learn to code" argument. There are always problems with judging how much
work is being done in any creative project - heaven knows my best marketing
work comes in spurts that tend to happen at 2 AM. But the larger issue here is
that the guy issuing raises has no idea what is actually happening in the
codebase.

I'm by no means an incredible engineer, but I've spent a couple hours a day
over the past few months building basic Ruby/RoR apps, and it makes an
_enormous_ difference. Of course, I still have a long way to go before I'm
able to really estimate anything, but if nothing else I understand why my co-
founder would just sit there for hours with a whiteboard and model data. I
know that "burnout" is a real thing, especially when you're not overcoming
little bugs you've had for a long time. I know the value of getting a second
pair of eyeballs on some code. etc.

It's just impossible to understand what you don't understand the technical
aspects of what you're trying to do.

~~~
greenyoda
No, you don't need to be able to code to understand that the team that's
working fewer hours is generating the same results. You only have to
understand what the business needs are and how well they're being met per
dollar that you spend. In the article's example, the manager needs to
understand how well his two cable provisioning systems are meeting the needs
of his customers. That has _nothing_ to do with code.

If a manager's only metric about how well his line of business is functioning
is how much overtime his employees work, then learning to code will not make
him any more competent. It's more likely that if the manager learns a little
bit about coding, he'll think that everything his team does is easy (since he
never tried to implement anything complex). Also he'll be more likely to be an
annoying micromanager, since he'll think that he actually understands the
complex issues that his team is grappling with.

~~~
bsirkia
The issue here is that "does it work" isn't a good enough metric for code
quality. If two engineers deliver code that accomplishes the same task, one
might have made it readable, testable, scalable, etc. and the other just
jammed it together to accomplish the desired result, the manager that can't
read code won't know the difference.

Yes, in the long term, the shortcut taking programmer's shortcuts will catch
up to him (code will break, you can't add more people to work on his code,
etc.), but it could be too late for the manager.

~~~
greenyoda
" _the manager that can 't read code won't know the difference_"

The manager that spent a month "learning to code" but never worked on a big
project will _think_ he knows the difference, but probably doesn't either.

~~~
austenallred
You're right. I'm not saying "Hey, I spent a month and now I can tell my co-
founder how it should be done" \- the first couple months is just the
beginning. But I feel like I can relate to/understand 10% of the process when
before I could relate to 0%, and that's a big jump.

I can see how it could get out of hand if I started questioning things I don't
understand, beating my chest and saying "Don't tell me that, I know how to
code," but now at least I can have a discussion with him without _everything_
going over my head. It's difficult to explain how big of a difference that
makes.

------
edw519
There are 2 ways to evaluate something else: with data or with perceptions.
Almost everyone judges by perceptions. Unfortunately this is not limited to
middle school cafeterias, single bars, or amateur hours. Some of the biggest
culprits are the people you would least expect it from: founders, managers,
entrepreneurs, users, and customers.

The is one sure-fire antedote to this: data. And the best data is a precise
project plan, with every detail, and always up to date.

I lost track long ago of the instances someone "important" accused me or
someone on my team of "not working hard enough" or "not appearing to be doing
enough". My response is always the same: whip a current hard copy of the
project plan out of my back pocket, throw it onto the desk, and ask the same
question, "OK, exactly what is the problem?" This shuts them up every time.
They may not like it, but they always STFU.

"Bill not moving fast enough for you? He's responsible for ORP560. 2 weeks
ahead of schedule."

"Sue not here enough? She's in Wichita this week. Just implemented RESERVES.
Already saved us $200,000."

"Don't like how Gary talks to the customer? Here are 14 examples (right here
on the page) where the customer was wrong and Gary straightened them out. How
would you suggest he handles it?"

I can go on and on. Many of us skinny introverted geeks have had to find a way
to counter the slings and arrows of ugly decision-making by perception with a
hacker's solution: maintain the data to counter the perception. It's the best
thing that I've ever found that actually works.

~~~
mattgreenrocks
I've dealt with this in the past.

This is about people trying to throw their weight around to get/maintain
respect, and you're not giving it to them. They may have to STFU in the face
of data, but they will probably resent you for it.

------
dalore
Same thing with system administrators. If you're a bad sysadmin your stuff is
going to break constantly and you will look like your working hard to fix it.
If you're good at it, hardly anything will go wrong and to management it looks
like you sit on your butt all day.

~~~
codeulike
Yeah I saw a case when sysadmins left an exchange database to grow to crazy
size and then it failed, cue days of trying to restore backups which also
failed because disaster recovery practices had never been written or tested.
After about a week I expected everyone to get sacked, instead they got a
literal standing ovation for their ceaseless scrambling around.

~~~
mhurron
If you do your job right, you look lazy and they ask why they are paying you
in the first place.

If you have no idea what you are doing, you run around, look really busy and
that justifies your position.

Shitty companies fire the first guy and keep the second.

~~~
Agathos
"When you do things right, people won't be sure you've done anything at all."

\-- God(?), Futurama

~~~
teddyh
That is from the Daodejing (Tao Te Ching), chapter 17.

[https://en.wikisource.org/wiki/Tao_Te_Ching_%28Wikisource_tr...](https://en.wikisource.org/wiki/Tao_Te_Ching_%28Wikisource_translation%29#Chapter_17_.28.E7.AC.AC.E5.8D.81.E4.B8.83.E7.AB.A0.29)

------
munificent
I've experienced this first-hand on more than one occasion when I was a game
developer at EA. Production consistently rewarded fire-fighters without
realizing they were in fact encouraging arson (though fires were always
through incompetence and not intentional gaming of the system as far as I
know).

If the people who put out fires consistently get the best rewards, don't be
surprised when a lot of things catch on fire.

The challenge is that you want to reward the _most skilled people_. However,
"skill" isn't easily visible to some managers. Instead, they observe that:

    
    
        effort = difficulty / skill
    

They can't measure skill directly, so they note the above and try to solve for
it. But that only works _if you can measure difficulty_. That's no easier to
measure than skill. The mistake they make (as in the post here) is that they
just assume difficulty is a constant.

If you're going to use effort as a metric for skill, you _must have a measure
of the intrinsic difficulty of the task_. If you can't directly measure your
employees' skill _or_ the difficulty of the tasks you've given them, you've
got real problems.

~~~
jlees
_Production consistently rewarded fire-fighters without realizing they were in
fact encouraging arson_

This is delightful phrasing. I'm totally going to steal it. :)

------
auctiontheory
Dan Ariely tells the story of a novice locksmith who discovered that as he got
better (and was able to open locks much more quickly, with less effort), his
customers increasingly resented his fees.

Customers/managers value the perception of hard work, even when the result is
measurably worse for them. In fact, we all do this.

~~~
TeMPOraL
I've read comments here some years ago that told it's common for a locksmith
to fool around the lock for few minutes with lockpicks and only then grab the
gun-like device that does the job 99% of the time - because if they start with
the gun, people don't want to pay for what is essentially a 30-second fix.

~~~
jackgavigan
Or they'll buy their own gun! :-)

------
Edmond
While you can't judge programming and knowledge work in general the way you
judge physical labor, it would help a manager to know when programmers are
likely wasting time and company money. This is especially important for
resource constraint startups.

I guess the question should be, Are your programmers working primarily to
serve your need as a business or are they devoting their effort and time on
work that is more aligned with their own ideology (choice of technology and
approach).

A few months back I was in Philly talking to a startup founder whose company
was at death's door because he kept hiring developers who came in and replaced
whatever the last person did because it wasn't what they preferred. This
phenomenon is a much bigger problem than the question of whether programmers
are working hard or not.

~~~
southpawgirl
It can be really unappealing to deal with an existing codebase which contains
whimsical choices, and ideally a team should have a turnover low enough to
ensure continuity and consistency of coding style. And to overwork people it's
hardly a good strategy to keep people sticking around. The problem you mention
might be connected with the issue of overworking more than it seems, imho.

~~~
Edmond
You are right, working with someone else' code can be quite a task sometimes
but it comes with the territory. It almost always happens that a programmer
attempts to redo work and end up creating the same problems that the original
developer already solved.

I think it really comes down to perspective, once you learn to view
programming as a means to an end, not an end in itself, I think you become
more tolerant of what looks like shabby code.

~~~
UK-AL
Until the shabby code starts making even the simplest changes, take days to
complete.

Keeping code in good condition, delivers a large amount of business value over
the long term. Shabby code delivers business value short term, but reduce it
long term.

~~~
Edmond
short term benefit vs long term value is certainly something to consider...

Going back to my earlier point, the important thing is for managers to know
how to recognize when a developer's effort is aligned with business interest
as opposed to simply allowing developers do what serves their own ideology.

I think once you do that, it becomes easy to discuss/address things like
technical debt.

------
tokenadult
The article kindly submitted here notes, "I would submit that the appearance
of hard work is often an indication of failure. Software development often
isn’t done well in a pressurised, interrupt driven, environment. It’s often
not a good idea to work long hours."

I would submit that this applies to many "professional" occupations. A lawyer
has to produce a draft of a brief or of a contract in time to meet a deadline
set by the client's schedule, so the work output just has to get done. But the
draft brief or draft contract works best to meet the client's needs if it is
developed after _thought,_ and being just-plain-busy isn't the same as
thinking. "There is no expedient to which a man will not go to avoid the labor
of thinking."[1] So, yes, whether you are a manager of programmers, or a
manager of lawyers, or a manager of physicians, or of any other kind of
professional, you have to know the professional's craft well enough to know
what good work looks like, and you have to make sure that the professional has
time to _think,_ and usually time to confer with colleagues to get a reality
check on the thinking. (The article kindly submitted here gives the example of
the author learning from the original coder of a body of code how the code
worked. The code was elegant, but it wasn't easy to see the elegance at first
glance.)

[1]
[https://en.wikiquote.org/wiki/Thomas_Edison#Misattributed](https://en.wikiquote.org/wiki/Thomas_Edison#Misattributed)

~~~
eterm
It sounds like what is needed is a guild of software engineers[0] that can
quality review peers.

Throughout this topic there is a thread of "only [talented] software engineers
can rate software engineers". So what is needed is an association of talented
software engineers.

[0] with apology if you prefer programmer or other term.

~~~
pnathan
Steve McConnell (of Code Complete fame) has posited this idea before. I keep
circling back to it in my head, but I can't mentally untangle what, precisely,
would be the rating. Would knowing GoF design patterns be the criteria? How
about ability to use Monads? What about being able to accurately describe red-
black tree uses? Perhaps a key dividing line would be the ability to spot bugs
in a code review? Basically, what would the minimal body of knowledge be to be
an accredited guild (union, professional org, etc) member?

The IEEE has built what they call a software engineering body of knowledge. I
think it's _mostly_ academic bosh. Am I ignorant for not understanding their
reasoning? Who builds the first criteria for what a body of knowledge should
be? Having read academic SW engineering publications, I'm convinced that
academia does not have the total answer.

I'm convinced that, theoretically, there should be a professional
organization, and an interview should be a conversation about people skills +
a credential check. But I am - today - not sure how to bootstrap such a thing.
If something comes along that I think embodies what is really important (both
industrial and academic rigor), I will likely leap on that bandwagon and chug
the kool-aid.

~~~
brc
These things already exist, and are universally a failure.

The top people don't need to join, because they are well known and have
reputation. The people that do want to join are those who need the trimmings
of an endorsement. So gradually it turns into a grouping of people slightly
below average trying to improve themselves. Plus, the people who are attracted
to this type of thing work in industries where others are bedazzled by
credentialism, like academia and government. A group of people dominated by
academics and public servants telling me how good they are? Thanks, I'll pass.

~~~
pnathan
I don't know that I'd rush to call _all_ unions and professional organizations
a failure. Certainly, say, the AMA or the NSPE has a certain usefulness (if
you disagree with that, I don't think we have a common ground to talk about
this, I am afraid). But I do agree that structural questions about a
credentialing/professional organization do exist and have not been adequately
resolved in the sw development field.

~~~
brc
I was specifically relating to the world of software.

~~~
pnathan
Sorry, I wasn't aware that you had confined your comment to our industry. I am
in quite definite agreement with you that extant credentialing efforts don't
appear to have been successful. I don't think they are intrinsically doomed to
failure, however. Suppose that an organization was constructed by
professionals from industry organizations who buy into the idea of a
credential recognizing competence (as has been done, for instance, in the non-
virtual engineering field in the form of the PE). What specifically would be
the problem there in your eyes?

------
danso
This is not just a problem in the programmer domain, though it may be
exacberated by how divorced much of management and executive types are from
the work of programming. Other domains in which performance is more easily
measured by eyeballing, office politics and plain poor perception can still be
a factor. At one place I was an intern, before I got formally hired, everyone
told me that I was a sure bet to be hired, because everyone thought I worked
so hard...when in reality, and I can say this now, I wasn't as focused back
then as I am now, and so they were basing their perception about how early I
showed up and how late (by late, I mean, maybe 7pm on days when I was really
distracted and didn't do enough work during the actual day) I stayed...but not
on how much I actually produced.

------
j45
This type of question doesn't just apply to programmers.

In IT departments, the ones that seem crazy busy and dealing with all sorts of
fires can hint at a deeper issue of low technical ceilings. The IT departments
where things seem calm, relaxed, and under control can hint at a higher
technical ceiling present.

Similarly, in programming, there are those who are solution based thinkers
(assume they understand what the problem is and off they go coding) and are
easily caught into a perpetual cycle of refactoring much earlier. There are
also developers who take the time to learn the problem from the ground up, by
doing the actual work and finding the things that the user is seeking to solve
but can't express or imply.

This industrial age thinking of being at a desk for x hours or looking busy is
an incredibly poor measuring stick for what is an abstract, and creative
pursuit. I find my time away from the keyboard is as important as the time I
spend at a keyboard solving problems that need to be thought about.

Going for a walk, helping someone else with their problem before my own all
seem to have interesting triggers for creativity -- solving a problem
eloquently enough that it requires deep understanding but little programming
wizardry.

My favourite part of this article was being open to, and appreciating the
value of learning solid processes from someone with more experience of having
a relationship with a code base for more than 1-3 years. There are too many
times where problems are trivialized, and lessons are re-learnt over and over
by new team members, experienced or not.

In the end, I read a quote about the kind of software development environment
that I always want to help enable -- avoid wizardry in code, frameworks and
technology, and instead focus the creativity and magic on architecture
solutions that don't require as much complexity to create the same solution
much simpler in the short term and the long run.

~~~
marktangotango
Can you talk about what you mean by technical ceiling, and high/low technical
ceiling? I've heard the ideas in your last paragraph referred to as the 'rule
of least cleverness', avoiding wizardry always good imo.

~~~
j45
Sure, I share 2 stories I like to explain with:

1) When someone wants to hire a web developer, I say, make sure they don't
just know how to do things limited to a few ways. You will inevitably run into
needing to do things that you did not expect and don't want to be beyond the
technical skills of who you hire, so hiring someone with barely enough skills
to put together a Wordpress site using the admin only will certainly not be
able to code/modify much of anything custom you might need.

If you hire someone with a higher technical ceiling, who has more skills than
what you need at the moment (knows more/knows that they can learn what they
need), they will be better positioned to not only grow with you, but give
insights instead of just saying yes to everything.

2) Let's say there was a time where the only way to do Windows Updates was
manually, by hand on each computer.

Companies would hire someone to come in, once a month, to perform updates on
each computer. Service Providers would spring up, providing windows update
servicing, which could be relatively taught to anyone. They might have a
minimum of technical skills, but they could follow along to a certain point.
The ability of the service provider to grow, now was limited to how many
windows update patchers they could hire, train, and retain, which over time,
meant, hiring less and less technically skilled people to do the work to grow
the business as much as possible.

The result? The IT company's had demand for windows updating, which it wanted
to grow, and now you had to find people who could do this, and keep doing it
reliably so the business could grow. Windows updates become it's low technical
ceiling, and it became integral to their business to keep customers dependant
on hiring them every month to do it because it's about the limit of what most
of their techs could do. Ask those people to solve something else? Too many
will try to fake it till they make it.

A high technical ceiling? The IT company that might do it a few times,
recognize it to be a very bad use of their time, instead offer to teach the
customer how to do it for themselves, and request that they instead invest the
saved money in IT services that might help the business more directly, and be
a part of learning things with them.

The tricky part of all this? Realizing how much more skill than you need to
hire.

------
mcv
I've always been bad at looking busy. Alright, I admit I'm lazy, but that
doesn't mean I suck as a programmer. In my first job, I'd automated pretty
much all of my work. Where others would do stuff by hand, I researched how to
write a script to do it for me. At some point, I had a collection of scrips
and macros that generated most of my code straight out of the functional
design.

So whenever the boss popped in, he saw me leaning back looking at my scripts
doing all my work for me. I was usually the first one to be finished with a
new task. I reduced compile time from many hours down to 30 minutes (which all
the other programmers were extremely happy with). But all my non-programming
boss saw was me leaning back or goofing around, rather than typing really hard
(which is what programming is supposed to look like, right?).

~~~
jroseattle
> I had a collection of scrips and macros that generated most of my code
> straight out of the functional design.

Scripts that generated code? As in, code that would be compiled and executed?

~~~
mcv
Yes. It was Visual C++. Most of it was piles of conditions and generating
texts based on that. It was all specified in excruciating detail in the
functional design, which I received as a word document.

I believe I had a word macro that selected what I needed and did some
formatting or something, and then probably some regexp replaces to turn it
into actual C++ code. It worked very well, and because the project had a
number of iterations where we'd implement yet another kind of insurance based
on the same kind of FD, I could reuse it quite a lot.

But my first project there was euro-proofing some code. I had to dig through
the code and figure out which numbers could represent money amounts. Another
programmer was doing this by hand, but I figured it should be possible to
automate it (there was a lot of code). After unsuccessfully trying to figure
out a regexp to match what I needed, I ended up writing my own not-quite-
finite state engine to parse the code and insert comments near all the
suspicious numbers.

~~~
jroseattle
Interesting. Externally, it sounds like lots of code being generated that's
somewhat a mirror of each other.

Were there cases where a bugfix was needed across code that had already been
generated? How was that handled?

~~~
mcv
I believe there was some typo or deviation of the regular format in the
functional design once or twice, which I fixed by hand. There was also a clear
error in the logic specified in the design, which I was required to implement
anyway. I pointed it out, explained them how it should be, and it took a
remarkable amount of bureaucracy and responsibility dodging to get it fixed,
but it was no problem for my work.

Generally after generating the big amount of code, I still checked everything
manually and added the needed boilerplate. It's just the initial generation of
hundreds of if-then blocks to build texts that I automated.

------
advertising
This reminds me of a lesson I learned working in sales for a big fortune 500
company.

You were given a quota to hit each week. One week I closed a big account and
hit my quota for the week by Monday.

When it came time to review your weekly sales numbers, I got grilled by the
sales manager for not closing double the quota, since I had closed the week's
quota on Monday and had the rest of the week to continue selling.

I was taken aback by this and simply asked, where does that end then? If I
closed a full year's quota in a single day, does that mean I should produce
the same every day? With a capped commission why would I do that when another
rep is producing a 10th of the amount but making the same pay?

It's not about hours worked, it's about production.

------
furyg3
I feel that the situation proposed in the article is a completely false
dichotomy. It's a myth that a good team sits in a meeting room for 4 days and
codes a perfect product in one swoop on Friday. At the same time, paying
someone in KLOCs is probably a guarantee that you'll have a bad time.

This is an issue I struggle with on a regular basis, as we outsource a lot of
our development work. We work on a project basis, but work very closely with
our partners to help them make good estimates, maximize capacity, and minimize
their (and thus our) risk. I don't want people to work overtime, nor do I want
them under-committing.

My experience is that watching someone's commits, even from far away, is
actually a _damn good indicator_ as to how capacity is being managed on a
project. Every project is different, but _coders code_ : if they're not
committing frequently and regularly, it's time to check in.

Human beings normally don't have flat productivity, so activity spikes are
normal. But low activity in a period means there is not enough work and/or
there will be a large spike later, which for me means risk.

~~~
chris_mahan
Even if what they commit does not solve the customer's problem?

I'd rather have a coder spend 3 days thinking and 10 minutes coding with one
commit than spend ten minutes thinking and three days coding with 300 commits.

Coder productivity to me is "is the user of the software more effective in
their job?"

~~~
weixiyen
what if they commit once every 3 days and it's super trivial.

~~~
chris_mahan
Well, if their trivial change in 3 days makes the customers more effective in
their job, then that's fine. Remember: the best code is no code.

~~~
weixiyen
well I suppose that really depends. When there is little to no code and the
feature remains incomplete, then it's pretty bad.

------
RivieraKid
You obviously want both to be productive, work hard (effort) and be clever
(efficiency). A simple model would be:

    
    
        productivity = effort * efficiency
    

On the other hand though, there's probably some unclear connection between
laziness and cleverness. My hypotheses:

1) Some people hate mundane work and crave intellectual stimulation. This has
both positive and negative effects on productivity.

2) Clever people can afford to be lazy in school and they simply stay lazy.

------
GoldfishCRM
Sorry to say this but a big part of being a developer is to talk about what
you are doing (and how hard it is=). Sadly you can work hard on a backend
problem with performance for months and still the guy changing some css, add
big color full pictures get more attention and credit.

------
brianmcc
This is interesting. And definitely a "real thing". To me it raises an
interesting question about effectively demonstrating value to one's higher
ups.

It's a little sad that pushing for "visibility" is so important, especially in
large corporations, but it helps to put yourself in the boss's shoes - how
will he/she _know_ you're doing good work unless you blow your own trumpet?

Arguments that a good boss "should just know" certainly have merit, but it's
up to each of us to determine whether our own boss fits in that category and
emphasize our accomplishments accordingly if we're to be "performance reviwed"
with bonus etc depending on that perception.

Edit: s/now/know/

~~~
knightofmars
This (as most things are) is far easier said than done. Someone who is in the
business of "putting out fires" can easily cite the numerous times they
tirelessly fixed a production bug or worked a 60 hour work week. Managers
quickly understand those concepts as they see a direct correlation to their
own job or can visualize the impact.

Explaining that you "wrote a unit test suite that has minimized the long-term
impact of bugs" or that you architected an elegant solution to a design issue
that will help foster extensibility and testability in the long-term will also
likely be met with "this guy is blowing smoke up my rear" because there is no
way for the manager to verify those claims.

Anecdotal case, I worked with an individual who was labeled as a "trouble
maker" who everyone said constantly raised issues that weren't relevant and
that didn't do any real work. The individual ended up quitting because they
got sick of the work environment. Next release cycle, all of the projects they
were a part of began falling apart. The contribution that this person had been
making was identifying shortcomings of the requirements, processes,
implementations, and verification steps. Nobody could see past their own bias
and lack of understanding about what was happening. They just kept getting
frustrated (including management) because from their perspective this
individual was just "creating more work".

~~~
brianmcc
I agree with you, I hate that so many places are like this. It really isn't
right, and rewards the wrong behaviours. From my own perspective I have been
lucky for the most part in having had good managers/team leads even in
organisations where this culture pervades.

It's taught me to be wary though and "manage upwards" until I feel confident
my own direct manager appreciates and recognises my input.

Raising awareness with my manager's manager is harder: still working on that,
I suspect and element of "HELLO HERE I AM FIXING STUFF, IT'S QUITE LATE, BEEN
DOING IT FOR A WHILE NOW, OK THEN GLAD WE'VE CONFIRMED WE ALL KNOW THIS" is
still needed!

------
royjacobs
It's very hard to justify this "laziness" to managers sometimes. But what's
more shocking is that the "lazy" group had a working system and that
apparently was not valued as much as the other group, continually fighting
fires.

------
Iftheshoefits
What this person describes is basically par for the course in non-IT
businesses, especially large ones with multiple teams.

In these organizations the _visibility_ of a team is at least as important as
what they do. Managers at these places typically are more interested in
playing the political games than attempting to do the "hard" work of managing.
One component of those games is to insure that these managers' managers can
_see_ their teams working, in the tangible, physical sense. The more "work"
being done, the better.

Managers at these places are awful to work for.

------
TulliusCicero
It seems the key issue here is that management can often not tell the
difference between 'fighting fires' because of incompetence, vs doing it
because the problem space is just very, very difficult.

------
collyw
Working for a less experienced team leader than me, I think this is basically
an experience / competence thing. My team leader constantly suggests a quick
hack to fix things, and is always talking about "firefighting", as does the
article. I often resist, or refuse to do things the way he suggests, taking
half a day longer to write a solution that I expect to work a month later.

Looking around for a new job at the moment, it seems hard to convince people
that I am worth double what a junior developer will cost. Half of the
interviews seem to have the programming language trivia questions. Even if
they did ask me more high level design questions, its not the way I work. When
I have to design a database, I don't do it in 20mminutes. I usually come up
with two or three alternative designs, with pros and cons. I probably look
unproductive staring into space, but I take a day or two for big decisions,
and mull over the possible scenarios and which design is better. My code is
better than it was a few year back.

------
drblast
Here's a contrary opinion. Understanding that some managers are really
measuring the wrong things, the lesson here shouldn't be "keep your head down
and hope your manager notices how great you are." The "hey, my job is done,
everyone else is stupid, management should see what a unique and beautiful
snowflake I am, haha" attitude is misguided.

Nobody is so smart or so productive that they'll accomplish more on their own
than with an efficient team. If you're the best one on the team and aren't
devoting a significant amount of your time to helping other people succeed,
you're being selfish and entitled.

If you can code more efficiently, then get your work done and find other ways
to help other people be more productive -- without being asked. That's
guaranteed to be noticed by all but the most incompetent managers. And if not,
the reputation you'll gain as the guy-who-is-so-good-the-place-would-fall-
apart-without-him will serve you in good stead in your next job.

------
crazygringo
> _I would submit that the appearance of hard work is often an indication of
> failure._

I think this is really the key sentence. It certainly isn't true in all cases,
but it tends to be true more often than you'd think. If you see a lot of
people struggling to work really hard... it's a big warning sign that things
aren't set up right.

------
vikas5678
God forbid one ends up working for a boss who insists you put in 8 hours of
sitting time in front of a computer, irrespective of productivity. I worked
for one such person in my previous company, I have since quit, working
elsewhere where all they care for are the results.

~~~
toomuchtodo
At a place like that right now. Its unpleasant to say the least..

~~~
vikas5678
I'm productive in the mornings. I wake up at 5 am and usually work a few hours
even before I get to the office. I'm usually ahead of schedule on most tasks.
However, this manager felt I was setting a bad example and still felt I should
keep a strict schedule and put in 8 hours of "face time". His loss.

~~~
eterm
I once worked at a company where they told me that using headphones would "set
a bad example".

Needless to say I don't work there any more and I have a good question for
when interviewers ask for "any questions?"

------
anvarik
"If other people are putting in 40 hour work weeks and you’re putting in 100
hour work weeks, then even if you’re doing the same thing you know that… you
will achieve in 4 months what it takes them a year to achieve."

says Elon Musk

~~~
knightofmars
The exception (Elon Musk) is not the rule. I believe most mortals would burn
out consistently working 100 hour work weeks at their jobs.

~~~
anvarik
My post was just an alternative to the main thread. I do believe in hard work,
and being consistent but Elon Musk's case is definitely extreme.

------
analog31
False dichotomy.

Edit: To be fair, my comment relates more to the title than to the body of the
post.

------
brianmcdonough
Every manager has their on and off days. On their off days, programmers are an
easy target to displace aggression. The unfortunate truth of human nature is
that it is rare where you find a situation where aggression is not displaced.

The pieces of the puzzle that work to set the balance are when developers are
freelancers who can walk away from undesirable situations. It also helps to
catalog and share experiences to "warn" other developers of potential problem
companies.

The optimal situation, I've found, is working remote when the developer is
well-motivated, is being compensated based on weekly milestones they help
create, requirements are based on real and realistic business assumptions, and
bonuses are paid weekly for meeting the milestone with an extra bonus for
exceeding the milestone for that week.

This is how we work at poppup. Everyone seems happy and when we have had
developers who are falling behind regularly, it just means that they are not
the right fit at that time and both parties can move on soon after the
discovery, having learned something valuable in the process. No hard feelings.

By the way, this last bit is an advertisement for this new way of working.
Poppup is looking to hire a remote rails developer right now:
[http://careers.stackoverflow.com/jobs/45288/rails-
developer-...](http://careers.stackoverflow.com/jobs/45288/rails-developer-
with-ember-js-experience-poppup)

------
bayonetz
I've worked in a Dilbert mill or two where managers mistake movement for
progress. The thing is, if you aren't ready to quit, then you must play the
game. And by that I mean play some actual games. Like Call of Duty or Halo or
something. Just come in to the office on some nights and weekends, get your
frags in, yet still look like you are "working hard and sacrificing" like the
bozos who are only there because they can't design/program well. :-)

------
iterable
This is why it is crazy to me when Product Managers (and CEOs at small
companies) don't know how to code. If you don't understand what a developer is
doing, you really can't know if your feature request should take 2 hours or 2
months. And there is no way in hell for you to judge their output or how hard
they are working. This information asymmetry can be super damaging to a
company's progress.

~~~
thirdtruck
Not just ignorance of coding, in general, but of the specifics of the system.

It's one thing to add a new feature to a brand-new project, especially in
terms of how soon you get visible results.

It's another thing to do it with a legacy system. You run up against all
manner of edge cases within just the internal ecosystem, never mind the larger
one.

------
alashley
I work at a startup and when I started the job, my boss was concerned with the
rate of progress. I'm the sole developer at the company and the only technical
person besides the CTO. My boss said that normally when he asks someone to dig
a hole for him, he can see visible progress being made. He felt like that
wasn't the case with my work.

We took a service-oriented approach to building the software, so in the early
days, my boss thought that no progress was being made because he couldn't
"see" anything. He also wanted me to work between 40 and 60 hours a week,
which I was doing until my overtime pay was taken away for "equity."

I've gone off on a bit of a tangent here, but I'm of the opinion that non-
technical founders should learn a thing or two about architecture and the
current state of web/mobile development before hiring resources. Otherwise, we
end up with silly analogies where people think programming is like typing up a
short story in MS Word.

------
simonholroyd
If there really is a substantial difference in the quality of two software
developers then that should play out in the amount of value delivered. The
article lost me at:

> Conversely, what about the guy sitting in the corner who works 9 to 5, and
> seems to spend a lot of time reading the internet? Is he just very
> proficient at writing stable reliable code, or is his job just easier than
> everyone else’s? To the casual observer, the first chap is working really
> hard, the second one isn’t. Hard work is good, laziness is bad, surely?

If the brilliant developer is spending a lot of time reading the internet,
never staying late, and producing the same output (minus bugs) as the weaker
team, then maybe he's not providing quite as much comparative value as he
thinks he is.

Note: Some discussion on here regarding sys admins. I agree the situation is
different in the maintain-working-systems roles vs. the create-new-products
roles.

------
jroseattle
About the only issue I take with this article is the reference to "lazy". I
know it's the colloquial reference with good intentions, but the implication
is still negative.

In the systems I've architected, well-structured code, proper tests, good
docs, operational goodness -- all that came about through spending time and
energy understanding how to do that well. It's come through watching others,
learning how others have solved the same problem I've solved, trying new
things, keeping my skills current, returning to sharpen skills that may have
dulled. I just happen to do it outside the guise of a living, breathing,
production system.

I know the article implies this as well, but I just wanted to highlight it in
depth. What the article references to laziness, I ascribe to competent and
responsible engineering.

------
eldude
There is currently a great deal of potential for disruption of engineering
business organization hierarchy. At the heart of the problem is how to
cohesively address the limited distribution of control, freedom, money,
stability and reward.

A good example of one aspect of this is LinkedIn's technical career track.
Beyond sole contributor status, you can be promoted to either a Manager or a
Staff Engineer. Managers have direct reports, while Staff Engineers lead teams
with a technical responsibility, each with their own progression: Manager < Sr
Manager < Director < Sr Director < VP < Sr VP and Staff Engineer < Sr Staff <
Principal < Distinguished < Fellow. The Engineering track is more of an
accreditation system focusing on freedom as opposed to control (control of
things vs people).

Most Silicon Valley companies struggle with retention, because they internally
cannot simultaneously offer a "fair" career progression/compensation and
compete with the raw efficient risk/reward of the free market (e.g.,
poaching). In other words, you can't promote engineers with potential over
engineers with good track records without consequently discouraging hard work.
On the other hand, you absolutely don't want engineers with potential to leave
because of an inability to offer opportunity equal to what they can find
elsewhere.

Companies will ultimately need to offer choice to engineers: higher vs lower
risk/reward. One possibility is a commission based engineering track.
Engineers would choose between the stability of traditional progression/salary
and a higher reward commission based system with a small base salary. The
commission system would require results-based quantitative systems like OKRs
(Objectives and Key Results) to quantify both the value of the proposal to the
company beforehand, and a quantitative measurement of its success. Switching
between tracks could occur each quarter allowing engineers to tap temporary
motivation increases. Mixing and matching traditional and commissioned
engineers would result in unique balances of high motivation and stability
(since the team lead is not their manager), which would highly align with
stable vs high risk/growing aspects/departments of the company.

The increasing competition faced from engineers starting their own companies
will require companies to adapt new compensation models to more efficiently
allocate resources (e.g., autonomy, cash, responsibility, recognition,
etc...). I think a commission based system holds a lot of promise for those of
greater capability.

------
grecy
This exact thing just happened to me during my end-of year performance review
last week. I got very low marks for "accountability" because during the
Remembrance Day long weekend I was out of the country. A system was upgraded
and went badly, and 5ish tech people came in for the entire weekend (6am to
3am days Sunday and Monday) in an attempt to fix it. They couldn't figure it
out, and it was up to me to diagnose and fix it Tuesday/Wednesday/Thursday
when I worked long hours.

Because I wasn't seen to be busting my gut on Sunday/Monday with the others,
my managers say I wasn't pulling my weight and therefore scored me very low.

If getting high scores means working Sunday/Monday on a long weekend, I don't
want high scores.

------
squozzer
used to go mammoth hunting with my bros but it wuz too much dangerous work so
i thot about how to catch lots of smaller critters instead. then i dug holes
with stakes in them and set big tree branches to fall down and kill critters.
that was hard work too, but not so dangerous as poking mammoth over and over
until it falls down. now my female calls me lazy because i stay at cave more
often and only go outside to chek these things i call traps. guess i'll leave
cave at old times but instead go to urgz place he has this stuff he calls beer
and it tastes kinda bad but after a few i don't care.

------
sherr
A while back, I briefly worked for IBM at their R&D office in Winchester, UK.
IBM did were building parallel programming tools and programs (transputers),
3D computer visualisations (constructive solid geometry) etc. Proper research.
I remember one of the senior engineers (big office) complaining that the new
MD of the center didn't think he was "working" if he was sitting back in his
chair with his feet up on the table (i.e. thinking). Typing = working!

------
gweinberg
It actually should be possible to evaluate the relative performance of two
teams without assigning them both the same project. Take two projects, ask
both teams to estimate the time required for both projects. Assign eah project
to the team which thought it would be relatively easy, and rate each team
against its own estimate, and the other team's estimate. You probably have to
do this with more than one project to be confident, but the general idea
should be sound.

------
kelvin0
So what is to be learned here? Well, make the core of your application VERY
robust (with good design principles) and have the 'peripheral' modules
designed as as 'balls of mud'. That way you have a good foundation on top
which with a front end that is weak which will leave you sweating just enough
for management to think you're working hard, all the while the core
functionality is never undermined ... !

------
bsirkia
I would argue that you can be productive for more than 8 hours a day, so the
programmer I want (obviously) is one that works nights and weekends but gets
shit done the whole time.

Do you think that if you worked nights and weekends (say another 20 hours a
week) your total productivity would be diminished vs. your normal week because
those extra hours aren't productive?

~~~
nilkn
Some oil & gas companies, like Chevron, believe so much that over-working your
employees leads to an overall loss in absolute productivity and work quality
that they give many engineers every other Friday off.

Of course, you could rightfully question whether this is actually increasing
the company's productivity or whether they are just so flushed with billions
of oil dollars that they can afford to pay their engineers full-time salaries
for slightly less than full-time hours.

~~~
conjecTech
That's...not entirely true. They work what are called 9-80s, so they put in 80
hours over the course of the 9 days every two weeks that they do work. So they
actually end up working more than 8 hours on the days they do work.

Source: I worked for one of the majors w/ this policy.

~~~
nilkn
Well, my roommate is on this schedule and most certainly does not work more
than 8 hours per full working-day on average. He might work 8 hours including
the time driving to and from work. And on the Fridays he doesn't have off, he
only works until noon or so.

Maybe his case is not normal?

Edit: Granted, I think another reason for this is that, based on his
descriptions, there's a remarkable amount of bureaucracy involved in the oil
companies. It's a very, very complex industry, and while it moves quite fast
on a global scale, it moves very slowly for most individuals involved in it.
His training program alone lasts a few years, so he won't really be a highly
productive member of the company for quite some time.

------
elwell
Just a thought: would it be a good idea or a really bad idea to pay employees
per bug fix/enhancement? (and allowing employee to choose which task to
accept; perhaps even a bidding system (a very inflexible one; maybe "the more
employees interested in a task the lower the price"; not an actual bid-amount
system))

~~~
ratsbane
Probably a bad idea:
[http://en.wikipedia.org/wiki/Cobra_effect](http://en.wikipedia.org/wiki/Cobra_effect)

Also, there's a fine line sometimes between bug fixes and enhancements.
Sometimes it just depends on where you're standing.

------
CodeCube
I've almost literally lived this exact scenario. Complete with "the other"
team that based their product on biztalk, and crowded around desks
firefighting production issues. Our team on the other hand almost never had to
field off-hours support calls, and we all left at reasonable hours :)

------
vjvj
Agree with the gist of the article but ultimately if I were to see a co-worker
leaving at 5.30 prompt each day as well as spending time doing unrelated
things on the internet, I would be of the impression that he/she wasn't
working hard.

------
jonahx
GEORGE: When you look annoyed all the time, people think that you're busy...

[http://www.youtube.com/watch?v=yd9ma2UVLHM&t=17s](http://www.youtube.com/watch?v=yd9ma2UVLHM&t=17s)

------
vorg
The corporate IT shop development model is broken. "Average" programmers have
this protocol for ganging up against "10x" and even "2x" programmers, thus
protecting their jobs.

------
yuhong
I remember suggesting that closed and open allocation can be mixed. For
example, Intel can use closed allocation for the fabs and open allocation for
the actual engineering.

------
AshFurrow
Work smart, not hard.

~~~
avelis
Sometimes it's both. So the statement doesn't always apply although I do push
for it.

------
lutorm
Curious, is this less of a problem on teams that work remotely where the only
thing you _can_ evaluate are the results?

------
minusSeven
This basically boils down to You can't measure productivity for programmers.
Hope some managers are reading this !

~~~
collyw
You can surely tell some produce better (more maintainable reliable, readable)
code. I can when I look at some of my colleagues work.

------
umsm
this reminds me of a story my father once told me about a visit to a mental
hospital:

To keep the patients busy, they would have 2 groups: One group would be
responsible for unloading something from the back of a truck while another
group would be responsible for loading it back into the front of the truck.

All of the people appeared to be working.

------
c0ur7n3y
I often make the cynical observation that, "If you're not typing, you're not
working."

~~~
twistedpair
Must be reading HN

------
etanazir
Maybe you should just not judge a programmer unless you are a programmer who
has followed their code.

------
sidcool
"Your Programmers", I find it a bit, you know, old times.

------
mml
yes. they are lazy. that's why they are good programmers.

------
EGreg
Peter Molyneux could be the M Night Shyamalan of games

------
lanbird
damn working really really hard and after lazy

------
dschiptsov
Oh, yeah, this story is as old as the world.)

Straight-forward, brute-force approach sometimes works for easy tasks, it
seems, while to came up with some optimization or innovative idea one must
master hows and whys, which takes long time. But in the long run, of course,
those who invests in understanding and knowing of how things works and why,
would ultimately win.

The classic story is that people with understanding and knowledge of hows and
whys, so-called "mappers", could even design and implement a whole new
language based on proper concepts, while so-called "packers" are continuing
struggling and sweating with their packing. Never heard of Scala?)

Another nice point is about [re-]structuring the code. Keeping functions small
(and interfaces standard and simple) pays in any language, but to know that
one needs to learn the fundamental ideas in CS, not "recipes" from some crappy
book that end with "in Java".

Putting it another way, studying classic CS (algorithms, data structures,
programming paradigms and language design) takes long time, but eventually you
will outperform "hard working guys" because you will waste much less time on
ignorant guesswork searching in darkness and repeating all the naive old
errors.

Only one with knowledge could afford to be lazy, since knowledge is power. It
is not actually laziness, it is efficiency in movements.) Choosing appropriate
paradigm, right data-structure (and corresponding algorithm) could save man-
months, if not man-years.

------
amerika_blog
"Working hard" is confusing the tool for the objective.

Are they working effectively?

That last word is the important one. It implies a connection between the work
and reality.

Otherwise, people gladly work hard... on irrelevant bullshit that makes them
look good but doesn't advance the company.

------
wissler
The deeper problem here is the perverse incentive system built into the way
our economy works.

As just one example: Ideally a person creating great code would benefit from
it over the longer term, he wouldn't just put his heart and soul into
something that gets handed over to someone who doesn't really appreciate it.
And under that approach, he wouldn't stop working just because his assigned
task was finished, he'd work on other things, since those too would reap him
benefits.

------
asima123
I'm the lazy guy

