
Smart Guy Productivity Pitfalls - SoftwarePatent
http://bookofhook.blogspot.de/2013/03/smart-guy-productivity-pitfalls.html
======
ebiester
When I hear people saying, "I can do what takes someone else a day to do..."
they're not thinking that their coworker is also doing it in an hour or two,
and wasting the rest of the day. So everyone thinks they're more productive
than the next person.

And I'll look at that code and go, "You have no tests. You didn't think about
these three things. There are two bugs waiting to happen. This code is messy
and is going to be hard to change later. It took you two hours because you
didn't do the other six hours of work required to get it _really_ done."

This is why I believe pair programming ends up not being a waste. Perhaps for
the most disciplined programmers, they can go 8 hours without stopping, but
most people don't.

It's much harder to slack when you're pairing. However, it's also much slower
when you pair because you keep thinking of things to check, you write more
test code, you write more robust code because two people are trying to attack
it rather than one.

------
svantana
Good post, I just have a little problem with one advice: the "keep at it until
you finish it" part. A lot of times, I set my mind to finishing something
before goind home. It often ends up with me scratching my head until midnight,
going to bed frustrated, and waking up with an obvious solution in my head.
That's where I feel Rich Hickey's Hammock-driven development is a better way
of thinking about productivity.

~~~
unoti
I've observed this as well, and I think both models are valid. Sometimes
banging out code non-stop is where it's at. And sometimes resting and letting
the solutions bubble up into your consciousness is where it's at.

Here's my theory on when they both apply, based on my experience: When you're
in a problem domain that you've mastered thoroughly, then writing code non-
stop is where it's at. When you're in a problem domain that you're newer to
and haven't mastered as thoroughly, then you're going to be banging your head
against the wall more often and find your solutions more often while resting.

This is the big difference between "research" and "development". If it's a
research project, you don't really know what you're doing, or how to do it, so
there is much uncertainty. If it's a pure development project, you pretty much
know what to do and you go bang it out.

I started contemplating this a lot because for about 20 years, I did business
software-- ERP systems-- inventory control, order management, that sort of
thing. I had been doing it so long that every problem that came up, I pretty
much knew exactly how I was going to architect the data, everything just
instantly crystallized in my mind once I'd talked with the stakeholders about
what kinds of problems we needed to solve. I could estimate development
timeframes astonishingly well.

Then I moved into game development a few years ago, and suddenly my ability to
estimate went into the toilet. I started finding that trying to code 15 hours
a day wasn't as effective as it once was. I spent a lot of time being stuck
with problems.

Finally I realized that the reason I was so radically productive and good at
estimating things wasn't because I'm a natural programming badass. It was
because I had 10+ years of experience doing the exact kind of things I was
doing, and developed all kinds of experience, intuition, and tools to rock the
house. Once I changed problem domains and languages and lost my old bags of
tricks, the entire landscape changed.

So I agree with you that sometimes it's all about banging out a ton of code,
and sometimes it's more about relaxing and meditating. Most developers today--
if they're not going obsolete-- are radically changing technology landscapes
every few years. Or should be.

------
tylermauthe
I believe I've seen this article posted before, possibly on HN. In any case, I
re-read it today and all the lessons in it are applicable to me - yet again.
Though I've made improvements in many areas, I have also fallen deeper into
some of these pitfalls.

I was once obsessed with productivity, and for me it came down to an attitude
of 'just do it'. This was filtered out into various micro-level attitudes and
behaviours, many of which are discussed in this article... However, I now
realize that going back to University sapped me of all this yet again: I was
in the world where smart guys reign supreme. This is the reason why the smart
guy pitfalls exist at all: there are artificial worlds where we can somehow
glide by just by being smart.

The real world is real, and it takes real work to stay on top of your shit.

Some things I used to do that I will start doing much more again:

    
    
      - Write everything down
      - Make todo lists
      - Try to actually measure productivity (http://www.rescuetime.com)
      - Be realistic and conservative with estimates of how long things can take.
        --Not really knowing how long something will take should be scary.
        --Do a quantifiable percent of a task, time it, extrapolate.
      - Stop borrowing time (and money).

------
GuiA
Awesome write up.

Without realizing it, I've been doing the same "CD trick". I play the
Monstercat album mixes
([https://www.youtube.com/user/MonstercatMedia](https://www.youtube.com/user/MonstercatMedia)
\- dubstep, which , regardless of its musical merits, I find conducive to
focusing and not trailing off) and see how many I go through in the day. I
also like albums because they're about an hour long, which I use as one-hour
long pomodoro timers. 20 minutes is just way too short for me to truly focus.

I also really like the attitude that if you're not touching code, you're not
doing real work. Sure, project managers etc. will say that your job is not
solely to write code, and that responding to emails, participating in meetings
with your teammates, etc. are as much part of your job. But I like the
simplicity of "if you're not writing code, you're fucking off" and how easy it
makes it to answer the question "Did I work today?".

The other points are spot on. I suspect a lot of engineers are of the ADHD-
type personality (the fact that "yak shaving" is a thing in our jargon is a
good sign of that IMO), and a key part of addressing it is to learn how to
spot when you go off track (zoning off and going on Twitter when the bug is
getting a bit too hard to track down, stopping what you're doing because a
random question popped into your head and you just have to read the related
Wikipedia article, etc.) so that you can correct yourself. Don't feel bad
about it- just learn how to catch it early, and stop doing it.

I heard a talk a while back where the speaker was driving home the fact that
we need to get used to the fact that we should do things regardless of whether
we feel like doing them or not. It sounds super dumb and like the ultimate
first world problem, but thinking about it hard made me realized how skewed my
perspective was. I feel like our culture at large really leads us to believe
that we should only do things we like and enjoy; "I don't feel like doing it"
is definitely a sentence I hear regularly among my peers.

Finally, surrounding yourself with smart, hard working people is the ultimate
productivity hack to me. In college, the quality of my work changed
drastically depending on whether I sat at the front of the class with the math
nerds or at the back of the class with the anime nerds. I realized that while
I can be self-driven when it comes to things that _really_ matter to me, a lot
of the time I will follow the general tendencies of whatever group I am in. I
suspect this is why all the smart, talented people in the industry are friends
in some capacity - because they recognize how tremendously powerful it is to
be in an environment where the average is very, very high. This leads to
situations where you have companies who seem to be always in the spotlight,
always have the best people, etc. (i.e. Valve, Oculus, iD Software, to stay in
the gaming register that the article has), and then the other 99%.

If you feel like your workplace isn't encouraging you to be the best you can
be on that front, that's an extremely compelling reason to find another place.

~~~
sillysaurus3
_I also really like the attitude that if you 're not touching code, you're not
doing real work. Sure, project managers etc. will say that your job is not
solely to write code, and that responding to emails, participating in meetings
with your teammates, etc. are as much part of your job. But I like the
simplicity of "if you're not writing code, you're fucking off" and how easy it
makes it to answer the question "Did I work today?"._

On the other hand, programming all day is sometimes a recipe for not learning.
It might be better to spend 20 minutes learning an elegant solution rather
than 5 minutes implementing a hack. But those 20 minutes are mostly spent
reading rather than writing.

~~~
lostcolony
I view thinking about the problem, researching the problem, etc, as being
indivisible from the coding aspect.

Really, it's telling how -I- feel after a day spent in meetings. It feels
wasted. I'm grumpy that I achieved nothing.

Whereas a day without any meetings, where it's head bent down, writing code,
even when it involves research or looking up API docs, or going to ask
questions of domain experts when interacting with other systems...feels
productive. Even when some of it changes because the customer comes back and
says "No no no, it should work like (X)".

Honestly, it feels more productive when the customer can instantly tell me
what is wrong after the fact, than if I spend an hour up front trying to pick
their brains, to then code it, and to -still- find out it's wrong. Per another
thread we had here, people find it much easier to tell you what is wrong than
to tell you out of the air what is right.

------
domdelimar
"Oh man, I have to make a snarky response, but first I have to Google for that
XKCD comic that totally makes my point for me..."

Not only can I see myself in that vividly, I was thinking there should be an
easier way to filter XKCD comics by (life) situations. And I've found
[http://www.explainxkcd.com/wiki/index.php/Category:Comics_by...](http://www.explainxkcd.com/wiki/index.php/Category:Comics_by_topic)
that's close to what I was looking for.

------
LordHumungous
I think I'm a pretty hard worker, I definitely feel the need to be productive,
but every few weeks or so I have a moment where I say to myself, "You know,
its just a friggin computer program, who cares?" And then for a day or two I
coast a little bit, and try to get away from my laptop as much as possible. I
guess this means I'll never be as good as John Carmack. Oh well, its worth it
for me if I get to slow down and enjoy life every once in a while.

------
ixmatus
Definitely one of the better articles I've read on productivity that can be
applied in many more areas than just programming.

I've found my own sense of entitlement and superiority inflated then promptly
deflated by smarter and more productive people; I think the hardest and most
important part of the experience though (that the author touched on) is to
move through the feelings of depression or unworthiness when you are deflated
into an appreciation for _what you can become_ and allow those people to
inspire you to something better.

I've accepted that I'm not a bad ass and I'm hyper aware now of what I want to
improve upon in knowledge, craft, and self-efficacy (focusing and applying
myself).

------
db42
If anybody wants to try this approach to track productive time, I have built a
chrome extension exactly for this purpose (couldn't find any tool doing this)
- [https://chrome.google.com/webstore/detail/track-your-
product...](https://chrome.google.com/webstore/detail/track-your-
productivity/onnkllhiaannegcomgbogohfpeegdnnf)

You should definitely check it out.

------
joemaller1
> my generation of programmers who were raised with the vile "work smart, not
> hard" mantra, coupled with the sense that we were somehow significantly
> brighter than most of our peers.

Spot on. Been digging out of that hole for decades.

------
gwu78
Everytime I have to read one of these "blogspot" blogs, I find myself
rewriting my "one-off" solution again so I can read the blogger blog posts
without Javascript.

For the 1 or 2 people out there reading who like to use a text-based browser
and find gratuitous Javascript annoying, I have pasted this solution for you
below.

Note: Some blogspot blogs do not have feeds enabled and will give a 404. Some
of these appear not to require Javascript; in that case, this script becomes
unneccessary.

    
    
      # fetch a blogger.com blog ...
      # without the gratuitous javascript
      # usage: 
      # nameofthisfile nameofblog > htmlfile
      # yourfavoritebrowser htmlfile
    
      # requirements:
      # netcat
      # openssl
      # sed
      # optional: strings
      # optional: addcr
    
      type strings 2>&1 >&- ||
      strings(){ sed ;}
      type addcr 2>&1 >&- ||
      addcr(){ sed ;}
    
      case $1 in
      0) # get HTML
      case $# in
      2)
      shift
      {
      printf "GET / HTTP/1.0\r\n"; 
      printf "Host: $1.blogspot.com\r\n";
      printf "Connection: Close\r\n";
      printf "\r\n";
      } \
      |nc -vv www.blogger.com 80
      ;;
      *)
      echo usage: $0 $1 nameofblog
      esac
      ;;
      1) # filter for BlogID
      sed '
      s/\\046/\&/g;
      s/\\46/\&/g;
      s/\\075/=/g;
      s/\\75/=/g;
      /targetBlogID/!d;
      s/.*targetBlogID=//;
      s/&.*//;
      ' |sed 1q
      ;;
      2) # convert BlogID to HTTP
      while read a
      do
      {
      printf "%b" "GET /feeds/$a/posts/default HTTP/1.1\r\n"; 
      printf "Host: www.blogger.com\r\n";
      printf "Connection: Close\r\n";
      printf "\r\n";
      } 
      done
      ;;
      3) # s_client www.blogger.com  
      openssl s_client -ign_eof -connect \
      www.blogger.com:443 -verify 9 \
      |addcr
      ;;
      4) # filter for reading
      {
      echo
      sed '
      s/&lt;/</g;
      s/&gt;/>/g;
      s/&amp;/\&/g;
      s/&quot;/\"/g;
      1i\
      <br><br>
    
      s/<name>/<br><br>name &/g;
      s/<uri>/<br>uri &/g;
      s/<generator>/<br>generator &/g;
      s/Blogger//;
      s/<id>/<br>id &/g;
      s/<published>/<br>published &/g;
      s/<email>/<br>email &/g;
      s/<title type=.text.>/<br><br>&/g;
      s/<openSearch:totalResults>/<br>total results &/g;
      s/<openSearch:startIndex>/<br>start index &/g;
      s/<openSearch:itemsPerPage>/<br>items per page &/g;
      s/<updated>/<br>updated &/g;
      s/<thr:total>/<br>thr:total &/g;
      s/<\/feed>/&<br><br><br>/;
    
      s/^M*/<br>/;
      '  \
      |strings
      }
      ;;
      5) # all of the above
      case $# in
      2)
      shift
      $0 0 $1 \
      |$0 1 \
      |$0 2 \
      |$0 3 \
      |$0 4
      ;;
      *) 
      echo usage $0 $1 nameofblog
      esac
      ;;
      *)
      a=$(type $0|sed 's/.* //')
      sed '/[)] *#/!d' $a
      esac

~~~
mkartic
thanks! Will check it out. I use noscript, which is a slightly easier option
in this case than a text based browser. :) But having a very strict
whitelisting policy, I have to allow 3-4 sites to run JS temporarily everytime
I decide to read something on blogger.

------
thinkersilver
Being productive is pure execution of an implementation or an idea. Anything
else like planning, thinking through your problem is not deliverable or
visible in the final output. Yet these things are necessary. Deciding when and
how much to plan and think about your problem becomes a strategic decision.
You want to spend the minimum effort required for the most effective solution
within your time frame.

I'm almost certain that I have an undiagnosed ADHD, but living in London it is
something that is not recognized. Whether this condition exists or not, my
attention span is well below that of my peers at work. This lead me to
actually find out what the optimal period of time I can concentrate doing
something without my mind wandering. I took a timer and over a period of a
week I experimented with blocks of time, starting from 25 minutes , I
gradually reduced the block by 5 minutes until I found that sweet spot. I
expected it'd be about 15 minutes, but to my dismay it was only 5. WTH!

I accepted the results and started each task with the expectation that any
task I complete should finish in less than 5 minutes. If it doesn't then I'm
either being inefficient because I'm

1) disorganised - spending time looking for artefacts required to do the piece
of work 2) unskilled - spending most of that 5 minutes not executing but
thinking about how to do it.

At the end of the box of time. I'd document what category my inability to
complete the task fell into and then I'd note it somewhere so that at the end
of the day I could either spend time getting that area more organized, looking
for opportunity for automation or learning so that I become a bit more
skilled. Dealing with my disarray and unskilledness at the end of the day
helped me work smarter. Intraday, I'd not have the time to do this, this is
where the grind comes in, where you plough through a piece of work knowing
that it might not be the best way of doing it but you need get it out the
door. The time management system is unnaturally granular. You can quickly put
a stop to an unproductive avenues. This has gradually made me a more organized
and skilled programmer over the last 3 months. More importantly more
productive. It's also given me detailed metrics on my productivity. I can
measure my level of distraction, unpreparedness and so on. The odd effect of
all of this is that I can work much longer hours without moving from my seat (
I do force myself to get up for breaks)

All this is possible because of where technology is now, without it the
process is far too granular and unwieldly to be practical.

From my experience I agree with what the author said in points 7,8. This is
vital.

* Haven't an objective productivity metric - how do you measure your productivity. * Accept that the grind part of the job

I think everything else can either fall into the categorys of managing
procrastination, motivation and being a bit more organized which can vary
widely depending on individual.

------
mantrax
This guy is very right. I wrote myself a simple time tracker (I tried a bunch
of other ones, but I was unhappy), to track my daily activities. Like John
Carmack, I'd turn the timer off any second I'm not spending doing real work,
even if I go to the bathroom.

I found out that during a "8-10 hours workday" I'm actually working, as in
coding, getting shit done - maybe for about 2, tops 3 hours...

That's not just an interesting observation, I was FUCKING HORRIFIED. I'm
pissing my limited lifetime away!

The first step is awareness. Always. Then comes improvement. I kept tracking
myself, now being very aware of what interrupts my work, and limiting my
distractions. I have yet to claim 8-10 hours of solid work in a day, but it's
getting better.

~~~
thinkersilver
This was my experience too. I found that I was productive 2 hours each day.
The time tracker helped bring this up to 4 hours in an 8 hour day. I would
play a game where I would try and beat yesterdays score.

Unless you have your own office, or at home or coworkers are forbidden to talk
to you on pain of death and torture, I find it extremely difficult to be more
productive than 4-4.5 hours in a 7-8 hour block of office time.

~~~
Frqy3
I get around 30-40% of my weekly work done on the single day a week I work
from home. Sitting in the office, even with headphones on, I can hear the
conversations of about 5 people sitting near me, and I inevitably end up
joining in to add my $0.02.

