The Artima Developer Community
Sponsored Link

Weblogs Forum
Why it's better to be lazy

16 replies on 2 pages. Most recent reply: Jun 24, 2008 6:11 AM by Vernon Robert

Welcome Guest
  Sign In

Go back to the topic listing  Back to Topic List Click to reply to this topic  Reply to this Topic Click to search messages in this forum  Search Forum Click for a threaded view of the topic  Threaded View   
Previous Topic   Next Topic
Flat View: This topic has 16 replies on 2 pages [ 1 2 | » ]
Jeremy Meyer

Posts: 40
Nickname: jeremy1
Registered: Jan, 2008

Why it's better to be lazy (View in Weblogs)
Posted: Jun 8, 2008 3:22 PM
Reply to this message Reply
Summary
Our parents were wrong when they told us not to be lazy. Laziness is a vital characteristic for success, and something we should strive for.
Advertisement

Classifying People

I have had recent to remember those 4 great classifications of people. Intelligent, Stupid, Active and Lazy.

My father often used to tell me about these classifications which he attributed to the Duke of Wellington. I have since read articles which have attributed them originally to Buddha, or some Buddhist swami, but the most credible source seems to suggest that they are more likely to have come from Helmuth Karl Gernhard Graf von Moltke, a German Military leader and strategist. (see below).

Actually it doesn't matter where they come from, the important thing is that they are an excellent insight into how and why people do things. If you haven't come across them before, they are very simple.

Everyone can be loosely classified into 4 groups, which are permutations of either activeness or laziness and , intelligence or stupidity.

Intelligent Lazy people, as my father would explain, are everyone's favourite. They do things in a smart way in order to expend the least effort. They don't rush into things, taking that little bit of extra time to think and find the shortest, best path. They tend to make what they do repeatable so they don't have to go through it all again. These people usually make good leaders, and they are good to have on teams.

Intelligent Active people are useful, because they are smart, after all, but their intelligence can be slightly diluted or tempered by their activity. Where they don't have a perfect solution, they might act anyway, rather than sitting on their laurels, so useful people but not great leaders, and on a team, they can often put noses out of joint by acting too early and too fast.

Stupid Lazy people have their place too, they are easy to manage, they generally don't act on their own initiative too much and, given tasks that are not beyond them, they will perform in a predictable, consistent manner. Usually they won't cause any harm on teams. Wellington, liked these people as foot soldiers.

Stupid Active people are the dangerous ones. Their default behaviour is to act, and in the absence of skill or thought they can cause all types of trouble.

Anecdotal Evidence

Stupid Active people are definitely good for one thing, though, they make for great anecdotes! They are the exclusive recipients of the Darwin awards, after all. We all know one of two of these, I bet if you think about it right now, you can think of at least one person you work with who you could classify immediately as stupid and active.

My own most recent amusing experience happened whilst on the management team for a large migration project. The team's task was to migrate UML Modelling projects from one version of UML to another, using Borland's Eclipse modelling tool, Together. In SCRUM tradition we had a daily call with our offshore team who were working on a backlog of many hundreds of projects that needed to be migrated. The task was fairly simple. Run the automated import facility, sanity check the project, and make any additional necessary changes to the UML model by hand.

One of the team, let's call him "Fred", reported that his progress was blocked by strange behaviour in his migrated Eclipse project. Diagrams were disappearing and reappearing and something was wrong. I noticed from his screen capture that something was awry with his project icons. I asked him to show me the contents of his Eclipse .project file. It contained the line..

<nature>uml14.uml14_nature</nature>

This is the line in the project file that tells Eclipse what type of project it is, and it told me that his automated import had failed. Clearly it had aborted, unable to convert the project from one type to another, no doubt due to corrupted input. I asked him to clean up the original UML diagrams, and re-try the import.

The following day, Fred reported that his icons were correct, but the project behaviour was still wrong. When I quizzed him on his approach, he explained that he had in fact edited the .project file by hand and changed the line above to:

<nature>uml20.uml20_nature</nature>

He had done this, he explained, because he had understood from what I had said that that particular line in the .project file was the problem. After much suppressed mirth, I patiently and politely explained that when changing the meta-model of one project to that of another, there was a great deal of work to be done, which is why it was automated, and why there was an import menu option for it. Manually changing the value of the "nature" tag in the project file didn’t change the nature of the project any more than wearing a baseball cap makes you a baseball player. To my astonishment, Fred defended himself with great verve. He stressed that he had "used his skills" in the best way he knew, to try and solve the problem. He seemed quite put out that I hadn't applauded his initiative. Not only was he actively stupid in his attempt to solve a problem, he was actively stupid in his attempt to justify it! Since he was my responsibility, but not my hire, I couldn't take what would have been my preferred action, firing him on the spot.

Everybody can be Stupid

Before I go on, I should say that Fred might well have been pretty smart in many ways. It has been my experience that you can't apply these classifications to people in general. There must be a context. You might be smart and lazy in your work, but stupid and active in the kitchen. I would like to believe that I am a smart, lazy software developer, but I am a very stupid, active DIY'er. Ask any of my friends who have been party to my crazy projects. My pond building exercise (where I cast my own bricks with moulds I made myself). Or my spontaneous tandoori oven, built from roof tiles at a holiday house in France (we ate cold, semi-raw chicken at 11pm that night). I am sure people do tend towards certain behaviours in all of their undertakings, but I think it is dangerous to apply the classifications generally. It is also hard to work with people whom you honestly believe are stupid in all walks of life. I have faith that there is something, somewhere that Fred does well and with careful consideration, but it certainly doesn't involve working with software tools.

Safety Net for Lemmings

My experience with Fred got me to thinking that when we create frameworks and even languages, we always try to cater for people like him. Some language designers feel this is their responsibility. Sometimes this is kind of helpful, like private methods and properties in a language, for example. Sometimes, it can be overly paternalistic. The old checked exception / unchecked exception debate springs to mind. C++ doesn't enforce the catching of an exception, Java does (with recent compromised made by Runtime exceptions). The question is, can you really defend yourself against active stupidity? Should you really try to defend yourself against it? Isn't it orthogonal to the actual intention of the effort, and just a bit like building safety nets on cliffs in case lemmings want to throw themselves off? (This is a metaphor, for more about the lemming myth, see the links below.) I was reviewing some code that looked like this, the other day:
   public void doStuff (int value) {
      try {
          applyCalculation();
      } catch (Exception e) {
      }
   }

Ah, that old chestnut. A swallowed, unlogged, unreported exception. It was lucky that I picked it up in the code review. This is a fine example of active stupidity in programming. It is actually less work, (less typing, even), and smarter to write:

	public void doStuff (int value) throws Exception {
		applyCalculation();
	}

.. clearly, having checked exceptions in your language is no defence against a developer who is this active.

Should we try and drop all of these types of controls in language and architectures? Of course not, it is just that there is unlikely to be a linguistic construct or design approach which can prevent active stupidity without being so infuriating as to be almost unusable by someone whose approach is more lazy and intelligent. The acknowledgement of that should lead to a happy medium between choking restrictions and complete lack of structure.

If you try to enforce exception handling, there will always be those who find a work-around for the construct. If you create a Singleton connection factory class to ensure a single point of connection there will always be someone who tries to hack their own independent connection to the server. If you try and enforce static type checking and make, say, a type-safe collection, there will always be someone who will explicitly typecast their Objects before they add them to make the code compile.. and so on.

It's People who Write Programs

Ultimately, until technology moves on significantly, it is people who are using programming languages and frameworks. The smart, lazy ones will be looking to reuse what they can and to find neat, idiomatic ways of achieving functionality. The active stupid people will be looking to "use their skills" like Fred did. And get stuff done.. Somehow.

Training, documentation, teamwork, and feedback all help to make people smarter (if not less active) and that is where a great deal of effort needs to be applied.

Too rigorous an amount of control in a language or framework doesn't do as much good as everyone thinks. It can often just create huge time overheads, as in the extra syntactic fluff needed to typecast because of Java's static type checking for example.

Affordance

An architecture or a syntax should provide a good context for creating idioms. It should make writing idiomatic code feel right without feeling that you have to jump through hoops. There should be an inherent affordance of the right thing to do.

This puts a lot of faith in the user of the language/ framework or whatever, but there are very successful examples of this. Languages like Ruby and Python (and of course SmallTalk) which allow parametric polymorphism tend to be scary to Java developers, it is, after all, a bit unbridled and wild being able to send messages to any type, but hey, smart lazy people never seem to get into trouble with it.

Perhaps a bit of judicious application of the 4 types would give us an idea who we should be looking out for in our designs and make us realise that some people don't need protection and others just can't be protected.

Next week, why it is better to be rich than ugly.

What do you think? Should we consider the importance of peoples' personalities when designing? What is your favourite anecdote of a stupid, active developer?

I hope you enjoy classifying your collegues!

Resources

Bruce Eckel on The Checked Exception Debate:
Checked Exception

..and The Static Typing Debate:
Static Typing

Helmuth Karl Bernhard Graf von Moltke
Creators of the German Empire

The Lemming Mass Suicide Myth
The Lemming Myth


Vincent O'Sullivan

Posts: 724
Nickname: vincent
Registered: Nov, 2002

Re: Why it's better to be lazy Posted: Jun 9, 2008 3:34 AM
Reply to this message Reply
> What do you think?

Well, I read the first third and skimmed the rest and I thought "Why?".

James Watson

Posts: 2024
Nickname: watson
Registered: Sep, 2005

Re: Why it's better to be lazy Posted: Jun 9, 2008 11:55 AM
Reply to this message Reply
> Ah, that old chestnut. A swallowed, unlogged, unreported
> exception. It was lucky that I picked it up in the code
> review. This is a fine example of active stupidity in
> programming. It is actually less work, (less typing,
> even), and smarter to write:
>
> public void doStuff (int value) throws Exception {
> applyCalculation();
> }
>

Smarter? Marginally.

Less work? In that method, yeah, but now every caller has to either catch the exception or re-throw it. If it's called 10 times and re-thrown it's already more work and now you've got to handle it in all calls to those methods.

And that's aside from the fact that methods that throw Exception provide no more information than those that declare no throws.* All methods can throw exceptions.

I would say about 90% of the time I have to deal with a checked exception I do this:

try {
foo.bar()
} catch (SomeException e) {
throw new RuntimeException(e);
}


Because 1. most of the time they are unrecoverable problems. 2. Even if we could recover it's not worth the effort for the number of times it 'should' happen (usually somewhere around 0.) 3. If it ever did happen, it would be the result of a programming error.

Checked exceptions have value, it's the overuse of them that erodes that value. Throwing Eception is not helping.

* I have certain cases where I declare abstract methods to throw Exception. This is because the method will be called by code that will handle all exceptions and it signals that fact to the implementor and allows them to declare which exceptions their particular implementation might throw.

Leo Lipelis

Posts: 111
Nickname: aeoo
Registered: Apr, 2006

Re: Why it's better to be lazy Posted: Jun 9, 2008 7:31 PM
Reply to this message Reply
If we can keep in mind that people cannot be sorted into neat little categories, I agree with the article's classification of behaviors and attitudes for the purpose of providing insight into a desirable way of life.

My anecdotal evidence suggests that stupid and active is, unfortunately, the most common type of an attitude/behavior. The reason for this is simple:

1. Active: this is bread into most children by their parents. "Work hard." "Don't be lazy." Etc.

2. Stupid: this is a natural result of most programmers being in the field solely for the money. As a result, they don't enjoy what they do. As a result, they don't want to learn about something they don't enjoy. As a result, they either take things not seriously enough or they take things way too seriously ("it's a job, dammit! this is serious unfun and unfunny business here"), and so all kinds of stupidity results from that. Taking things too seriously it's easy to become dogmatic about an approach or a piece of code and no taking things seriously enough makes it natural to ignore the learning process.

As a result of these two very common scenarios, this is the most dominant behavior. I hasten to say that a person is not stuck in that modality! It is usually possible to shift the programmer out of the active-stupid mode toward the vastly more desirable stupid-lazy mode. Then, sometimes it's possible to ignore or to reignite the passion and the joy, and shift the programmer toward intelligent-lazy mode.

It's very hard to convince the active-stupid person that lazy-stupid is better. Usually stupid people feel that by being active they can compensate for their lack of knowledge and they may feel inadequate if they are told to slow down.

Even if the programmer is smart, but the coding is performed too quickly, it's easy to write some stupid code. I've seen this happen when certain managers have taken a team of naturally intelligent-lazy people and shifted them toward intelligent-active modality through invoking the fear of repercussions of being "lazy".

The hardest thing about this is to have trust in people. To allow programmers to work at their best, one would need to have some trust that they are enjoying what they are doing and that these programmers want to create something very good, and thus, don't need to be pushed around (since they are already have a sufficient positive motivation).

I want to stress that intelligent/stupid and active/lazy are attitudes and behaviors and not people. It's not people that are stupid, it is their attitudes and behaviors. A person is not inherently anything. A person who has shown oneself to be smart, can act stupid. A person who has shown oneself to be stupid, can act intelligently, and so on. These qualities are malleable and good leadership can affect these qualities both positively and negatively.

Fred Finkelstein

Posts: 48
Nickname: marsilya
Registered: Jun, 2008

Re: Why it's better to be lazy Posted: Jun 10, 2008 5:19 AM
Reply to this message Reply
I do not think it is ok to try to classify people, because this might also depend of your current mood. Remember that you yourself might not be intelligent or otherwise suited enough to make correct judgements. After all it is a psychological topic and not rational. One should judge software engineers solely according to their output. That's what they are hired for.

But the moral is okay: You should encourage people that they think before they act, and that they make plans and so on. That's the only way you can guarantee that they use their brains. And that's what matters. And not the talk about classifications: That's better left to psychoanalysts, I think.

Patrick Band

Posts: 3
Nickname: bantri
Registered: Jun, 2008

Re: Why it's better to be lazy Posted: Jun 10, 2008 5:58 AM
Reply to this message Reply
There are several other concepts which i consider useful, along with the 1)ALIS concept as judging criteria.

One of these concepts, which i classify "2)Chess Paradigm" or "2)Out of the box" concept, is that, sometimes, in a chess game between A and B, the only subject that sees a good move (for one of the players), is the observer C.

This fact means that, in order to achieve some objective, like winning the match, or to enjoy chess itself, as a game, independently of the result, it´s useful to have the ability to abstract from it, as an outside impartial observer.

One of such cases happened in an easy game of 4x4x4 tic-tac-toe (easier learning curve than chess), that i used to play with Fred, the first objective was only to win the match, but it required some effort thinking for that objective.

Secretly and privately, i decided to take a look at the game itself, to see, if there was some way to get an angle, and discovered, by analysing a very powerful N-Programmable look ahead moves application, that, there was a special situation that allowed me to win in 5 moves.

Then, my objective changed, it was not winning anymore, it was just, setting up the trap for winning in five moves.

Then, my objective changed again, it was not winning in five moves anymore, it was just discovering how many levels Fred was using to play that game, hoping that he was at least using more than five levels, or at least able to discover that trap.

After winning several matches with Fred, without any effort, i got bored, because from that point on, specifically for this game, it was only funny to me, to discover players that were able to deliver me the victory, as soon as got the trap set, without spending any extra thoughts about the remaining moves.

Here´s the java version of Fred:
http://home.earthlink.net/~cmalumphy/3d.html

Bruce Eckel

Posts: 875
Nickname: beckel
Registered: Jun, 2003

Re: Why it's better to be lazy Posted: Jun 10, 2008 10:49 PM
Reply to this message Reply
I find it curious that the two examples you give of your own active stupidity are ones that I personally was witness to. And in the case of the Tandoori oven, I was actually trying to help.

Jeremy Meyer

Posts: 40
Nickname: jeremy1
Registered: Jan, 2008

Re: Why it's better to be lazy Posted: Jun 11, 2008 3:46 AM
Reply to this message Reply
> I find it curious that the two examples you give of your
> own active stupidity are ones that I personally was
> witness to. And in the case of the Tandoori oven, I was
> actually trying to help.

Well, in both cases you were certainly a contributing factor in my appraisal of the acts as actively stupid. (i.e. you actually pointed out that fact). In the latter case, if I remember, you also took photographs. Perhaps this was precautionary, in the face of potential litigation over salmonella poisoning! Either way, it has meant I can't deny the activity.

Richard Cordova

Posts: 1
Nickname: curtindog
Registered: Jun, 2008

Re: Why it's better to be lazy Posted: Jun 11, 2008 4:24 AM
Reply to this message Reply
I love the idea of the lazy programmer. Maximum result for minimum effort is a very appealing equation on many levels. Why then, is that great gift to lazy programmers, the Checked exception, being picked on?

Without checked exceptions one needs to know if the code one is calling is going to die horribly. There's no avoiding it. This may require one or more of: looking at the code, trying to remember how/why you wrote the code, or (gasp!) reading some form of documentation.

This is in direct contradiction to the lazy programmers goal of knowing as little as possible in order to get the job done. Yes, Checked exceptions can lead to dangerous coding practices, but as you yourself point out: should the rest of us be punished for the actions of the few?

Giancarlo Frison

Posts: 3
Nickname: giancarlo
Registered: Feb, 2007

Re: Why it's better to be lazy Posted: Jun 11, 2008 8:48 AM
Reply to this message Reply
Laziness may turn easly to unawareness. I guess it is a luxury to allow us the power of being lazy(intelligent), and becomimg as those without losing the job require a lot of commitment on the matters.
So maybe you have to study to become lazy, you do not born as such, did you?

Jeremy Meyer

Posts: 40
Nickname: jeremy1
Registered: Jan, 2008

Re: Why it's better to be lazy Posted: Jun 11, 2008 10:05 AM
Reply to this message Reply
> levels. Why then, is that great gift to lazy programmers,
> the Checked exception, being picked on?

"Checked Exception Debates considered harmful!"

Whoa! I am not really picking on Checked Exceptions per se, and exceptions or type checking isn't the focus of this discussion. My point is merely that a linguistic construct was born of the need to prevent people doing silly things (like swallowing and ignoring exceptions) but in fact, stupid active people are "immune" to these constructs. I am appealing for a whiff of psychology in our design approach. Possibly dangerous and contentious.

In another forum you might easily convince me that a checked exception actually allows a lazier approach, to which effect I apologise for an imperfect exemplar.

Jeremy Meyer

Posts: 40
Nickname: jeremy1
Registered: Jan, 2008

Re: Why it's better to be lazy Posted: Jun 11, 2008 10:09 AM
Reply to this message Reply
> So maybe you have to study to become lazy, you do not born
> as such, did you?

Well, I guess there is a certain degree of laziness which comes with age, isn't there? Mostly we prefer to call it wisdom, or intuition, because those terms have a more positive slant, but it definitely seems to involve asking "why" before we do something.

Gregor Zeitlinger

Posts: 108
Nickname: gregor
Registered: Aug, 2005

Re: Why it's better to be lazy Posted: Jun 11, 2008 2:08 PM
Reply to this message Reply
> My point is merely that a linguistic
> construct was born of the need to prevent people doing
> silly things (like swallowing and ignoring exceptions)
No, checked exceptions introduced the problem of swallowed exceptions (which is one of their disadvantages).

Therefore, the example does not fit at all.

Lou Marco

Posts: 8
Nickname: loumarco
Registered: Nov, 2007

Re: Why it's better to be lazy Posted: Jun 12, 2008 3:52 PM
Reply to this message Reply
Jeez - I thought the article would be about lazy evaluation.

Anyway - remember that hard work may pay off in the future but being lazy pays off now.

James Watson

Posts: 2024
Nickname: watson
Registered: Sep, 2005

Re: Why it's better to be lazy Posted: Jun 13, 2008 1:06 PM
Reply to this message Reply
> One should judge
> software engineers solely according to their output.
> That's what they are hired for.

These judgements can and should be made from the output of the engineer. I've worked with stupid active developers. I made this judgment based on the reams of insipid bullshit that they coded to solve the most trivial tasks. Intelligent active developers are the ones that try to build designs that will support all possible future outcomes. I have been in that group and still have to fight the urge sometimes.

This topic is something managers should understand because it really is about what kind of developer output they should value. A lot of managers think the active developers are the 'hard workers' when really these developers are working against what should be the ultimate goal, to increase the results/code ratio.

Flat View: This topic has 16 replies on 2 pages [ 1  2 | » ]
Topic: Why it's better to be lazy Previous Topic   Next Topic Topic: Diagrams in UML: A Survey


Sponsored Links



Google
  Web Artima.com   

Copyright © 1996-2014 Artima, Inc. All Rights Reserved. - Privacy Policy - Terms of Use - Advertise with Us