
Smart Guy Productivity Pitfalls (2013) - andreaorru
http://bookofhook.blogspot.com/2013/03/smart-guy-productivity-pitfalls.html
======
alexandercrohde
I could not disagree more with this article's tactical advice (though the
intention is great). If I could go back in time and tell myself anything when
I first got into engineering it would be "Be sure to take at least 20% of your
day to not code, but rather to think about / engage with / socialize with
others. Do not optimize for personal output, you will help the system most by
improving the system rather than executing 25% more. And you can't improve the
system unless you learn the social graces, speak the lingo, are in a good
mood, appear patient, and aren't counting all the seconds that are 'wasted' by
these interactions"

~~~
onebot
No offense, but compare your GitHub profile to someone who "grinds" like
[https://github.com/bketelsen](https://github.com/bketelsen). There is far too
much confirmation bias in regards to work-life balance and ability to actually
produce. As far as clichés go, I believe that "if you do what you love, then
you don't work a day in your life" == productivity.

~~~
pathseeker
In what world do you live in where you can judge someone's productivity by a
public github profile?

------
trevyn
I think a lot of this comes down to what you want in life.

In my experience, if you’re a reasonably intelligent and experienced software
engineer, and make some smart choices about where to focus your effort, you
don’t _need_ to put in much of that effort to live what most people would
consider an enviable life. So you do that, become envied, get the validation,
and feel generally pretty good about yourself.

But there is this nagging sensation that you could do more.

And it’s true, and that’s what this article talks about.

And underlying that, I think it’s important to look at the tradeoffs, and make
a conscious decision about your life goals. As awesome as Carmack is, I’ll bet
not many have sat down and thought about what it would be like to _be_ Carmack
and not themselves.

Of course, the magic is figuring out how to get as many of the benefits with
as few of the drawbacks.

~~~
nouveaux
To me, the article is more about the delusion of how productive some people
think they are. It's one thing to know that you really put out 2-3 hours of
good code and be satisfied with it. It's another to think I've worked 10 hours
a day while being distracted by Slack and surfing the web.

The best take away for me is to have a good measure of productivity and I
think 'pausing the CD is a great idea.'

~~~
hinkley
There’s another delusion around spending 20 hours on the wrong code and
declaring success. You were efficient but not effective.

------
d--b
I often find myself slacking when I have to write code I am ashamed of.

Writing new stuff from scratch is fun, I have zero problem being motivated to
code things that are hard or challenging. And I can keep focusing for a long
time.

However, if my task is to shoehorn some code that I know to be crap into my
project for x or y reason, oh boy, then I can drag my feet for a looooooooong
time.

~~~
iamcasen
This. 100%! I find whenever I have a career crisis, or lack of motivation, it
is because of this right here.

So much code no matter where you go will be something like this. You'll have
to make something work even though all the code surrounding your feature is a
dumpster fire that is so hard to predict, that you'll pull your hair our
worrying about all the ways your feature will break.

When I get to build a new system from scratch? It's a breeze! I get thousands
of times the amount of work done in the same amount of time.

~~~
JustSomeNobody
So much irony here. Some other poor soul has to come along and procrastinate
fixing your old code because you didn't want to and moved on to some other
company.

~~~
iamcasen
True, but not a decision of my own making. I'm talking about times where I
explicitly recommend a refactor to get things in good working order, but I'm
forced by my manager to not do that, and instead get it done ASAP.

------
kbenson
_I distinctly remember him saying "So if I get up to go to the bathroom, I
pause the player".

You know what's pretty hardcore? Thinking that going to the bathroom is
essentially the same as fucking off._

This seems like it might be one of those times when the person doing the
speaking is being interpreted to say something he didn't mean to say.

The author seems to be coming from the direction of "count the time you
weren't working as unproductive time in the day", while it's unclear from
Carmack's statements (the subset referenced in the article, at least) whether
he was considering that at all.

For an alternative perspective, consider that Carmack might have tracked the
time he actively spent programming, and used that to measure commits or lines
written/changed over time. He may not have minded the occasional interruption
to clear his mind and reset. This changes the tone considerably, from one of
"ruthlessly cut out 'unproductive' time" to something like "track your
productivity when you're working to spot trends", and all it takes is looking
at the situation from the other direction.

~~~
cma
Not likely. Carmack did a write up of a recent vacation:
[https://www.facebook.com/permalink.php?story_fbid=2110408722...](https://www.facebook.com/permalink.php?story_fbid=2110408722526967&id=100006735798590)

------
hesdeadjim
I am continuously grateful that twelve years ago after dropping out of college
with a complete lack of focus I came back a year later and learned how to
_actually_ work hard. Outside of food and bathroom breaks, if a problem
demands it I can work for hours on end without breaking focus (and love it!).
It’s one reason that open office floor plans or a culture of interruption are
absolute hell on my quality of life.

I’ve struggled at times though to figure out how to balance the need for off
the cuff collaboration with teammates with the productivity that comes with
isolation. I settled for what I estimate as a 40% loss at my last gig because
it helped boost my teams’ overall productivity and improved the quality of our
product. Having thought about it recently, I believe my ideal would be some
kind of on/off cycle. Say, two days a week either remote or “quiet time” at
the office, and three days anything goes.

~~~
segmondy
How did you learn to work hard without breaking focus?

~~~
hesdeadjim
I'd say it was an unintentional lesson in the merits of grit. When I went back
to school my attitude towards my non-computer science courses did not change
-- I still very much disliked them. However what did change was that I decided
I was going to graduate no matter what. It didn't matter how I felt or how
much I'd rather do something else, I was going to study and graduate.

And I did. And it was hard as hell. But I graduated and for the first time I
really felt a sense of personal accomplishment. I hadn't finished college
because someone told me I was supposed to, I did it because _I_ wanted to.

Once I left college and I got to work full-time in my field of choice this
lesson paid dividends. When I have a problem I really enjoy trying to solve,
the hours can melt away. When I have a problem I really don't want to solve, I
can still sit down and force my way through it. And don't get me wrong, my
brain still fights against me in those moments ("Hey guy, go check Hacker News
or Reddit!"). But most of the time I am able to recognize when it is happening
and reign it in as necessary.

------
nickjj
I really liked this article and it's eerie at how I had those same
productivity issues and ended up doing things similar to Carmack to track
productivity.

Carmack used the CD player tactic to track his productive time, but a few
years ago I used a schedule. I charted out every minute of my life. Every
single time I context switched, I wrote down what I just did previously and
for how long.

After doing that for a bit you begin to realize just how fucked up you are
when you see a daily recap of "checked HN 25 times, checked email 20 times,
watched 2 hours of Youtube videos unrelated to your field" and you barely
inched forward on whatever you're working towards.

I found real deadlines really helps me. I mean, I had my next video course
idea in my head for almost 1 full year and I kept putting off doing work
towards it because I was getting small wins doing other stuff which prevented
me from even starting something new.

Then someone hired me for freelance work and it just so happens what he wanted
done matched what I wanted to do in my course almost exactly. It took me
literally 20 hours (3 solid "no messing around" work days) to write about 85%
of the material I wanted to do in the course. There's a lot more than just
writing source code to finish a course, but that was something I managed to
put off for an entire year but nearly completed it in a few days.

I don't know why, but when someone pays me to do something I shift from being
a sloth into a hyper focused productivity machine. I haven't found out how to
harness that power without external motivators and I've been at this for about
20 years (I work for myself, so I don't have a boss paying me).

I used to think I was never so stupid to have some type of fear of success but
deep down I'm constantly battling my inner self on the topic so I'm beginning
to think that maybe I have serious issues around that.

~~~
Yahivin
No idea if this will work but an interesting motivational trick could be to
put aside some of your money into a separate account and use it as a budget to
"pay" yourself for tedious yet important tasks you want done.

~~~
nickjj
I never thought of doing that, thanks. Is this something you've done in the
past?

On its own I'm confident that won't work because it's not new money, but
funnily enough I have a deeply rooted scarcity mindset (I constantly think
I'll wake up one day and won't be able to generate another penny), so maybe it
would work in the end if I gave myself a no strings attached "reward fund" for
completing tasks.

Some type of weird permission to spend X amount per month on non-essentials. I
currently live so below my means that it would probably be comical for most
people as an outsider.

------
hguhghuff
I love this post for celebrating hard work.

It feels like so much Silicon Valley culture is focused on giving programmers
distractions at the office that are not work, like foosball tables and ping
pong.

I like the idea that the reward of work is satisgsction with the outcomes
rather than non work recreational perks.

~~~
make3
where I work, we have that kind of entertainment stuff in ludicrous quantity,
but it's literally never used, except for the interns on Fridays evenings.

I see that more as decoration to make the place look cool

------
hacker_9
How to be productive in two steps:

1\. Use the right tool for the job - pen and paper when the idea is new in
order to nail it down, then code later once all the obvious pitfalls have been
ironed out on paper first. It's amazing how going through a few use cases can
drastically speed up development time instead of just diving straight in.

2\. Think about maintenance - write clean code, keep it simple, and write
tests (or at least write testable code).

This article seems to suggest that you should work all day, consider toilet
breaks as non-productive, and skip over exercise if you don't get your work
done. A great plan if you want to work yourself into an early grave.

------
le-mark
_If my coworkers were grinding through stuff that took them 20 hours, I 'd be
all "I work smart, not hard" with accompanying snarky eye roll, and I'd assume
I could bust through an equivalent work load in four hours and still look like
a goddamn superhero.

And sometimes I could, so, hey, validation! _

This was me for a lot of years, then like the author I joined a really high
performing team. Those guys (all men) cranked out a lot of code. I even told
my wife, I wasn't sure if I could keep up. I really had to up my game, but I
did find a lot of their code really wasn't the highest quality and they tended
to write more code than they needed. I learned a lot from the situation, and
every team since has been even more low performing. It makes it really easy to
excel in the typical, Dilbert, Fortune 500 development team.

------
guelo
A lot of people hate it but I actually find the daily standup a good motivator
to help getting shit done. The desire to be able to report something the next
day helps keep me focused.

~~~
mattnewport
I think the accountability is _why_ a lot of people hate it.

~~~
mattmanser
No, it's because you're being treated like a child and it's micro management.
No-one should have to justify their job every single day.

~~~
mattnewport
The daily stand up concept was popularized by Scrum which is pretty opposed to
micro management and treating people like children. Maybe it gets used that
way in some companies practicing cargo cult agile but it's not the purpose.

I've been the person not liking the accountability in the past as I've
struggled with very 'bursty' productivity and so the original article
resonated with me. I've also come to appreciate the accountability as the
parent commenter has.

~~~
mattmanser
SCRUM _is_ micro-management and treating people like children. That's the core
of scrum.

The reality of scrum is so far divorced from its claims it's a joke. Scrum is
anti-agile, the antithesis of every agile principle. It's managers micro-
managing their staff.

Fundamentally it's process and tools over individuals and interactions.

~~~
mattnewport
Scrum doesn't even have managers and doesn't specify any particular tools so
I'm not sure what you're basing these claims on. By "the reality of scrum" do
you mean that the way it's actually practiced in some teams is "far divorced
from its claims" (probably often true) or do you mean that the framework of
scrum is inherently flawed even if practiced as designed? You haven't made a
case for that.

------
bethly
The advice is not all bad. I certainly agree that slicing a problem into
small, concrete steps that can be achieved in less than a day (and then less
than an hour, and then in the next five minutes...) as one of the central
skills a programmer needs to develop.

I think what is missing is the exploration of how thinking of ourselves as
"smart guys" makes us _worse_ at our jobs. Intelligence isn't a substitute for
being a good programmer. Churning out lots of useful, dependable, maintainable
code involves a large body of acquired skills, habits and knowledge. When we
pretend what matters is how "smart" we are, we get defensive when we get
advice that we could do better, because "what, are you calling me dumb!?!!" We
also blame other people's mistakes on their lack of intelligence, instead of
considering how they could learn or how the system could change to better
support them.

Study after study shows that a growth mindset leads to better outcomes:
programming should embrace it.

------
epx
I tend to think all the time in a coding problem, even while eating, going to
loo, sometimes even in dreams. There is no bigger problem solver than a walk
off the cold white screen. So productivity cannot be really measured in
keyboard time.

~~~
iLemming
Oh yeah, Rich Hickey's famous: "hammock time"

~~~
grzm
I think there's a distinction to be made with stepping away from the keyboard
and thinking idly about a problem while doing something else and what Hickey
means by "hammock time", which is a more dedicated application of thought to
the problem domain, analysis, and design. Both can be useful, but I think
they're different.

------
iLemming
I've been writing code for long time. No tool or methodology has helped me to
become more focused, organized, productive and predictable as Org-mode. I do
not start a task without clocking in or starting new org-pomodoro cycle. I
take notes whenever I encounter a problem, get an idea or discover something
new. Every morning I read my notes from the previous day, check how I spent my
time. I'm not the smartest developer in my team nor the most productive.
However, without Emacs and org-mode I don't think I would be even working in
the same team.

~~~
mikekchar
I'll second that. And before anyone asks, it doesn't have to be org mode
(although org mode is the best tool I've used). I have approximated the same
with markdown when I've been trying to show how to do it to people who don't
like emacs.

One thing I'll say is that it might not be for everyone. I attempted to show
several people how I use org mode to organise myself and quite a lot of people
are uncomfortable organising themselves. They seem to get distracted when they
think too much about what they are doing and have trouble maintaining their
concentration. It is actually the opposite for me. If I don't have my notes,
I'm off thinking about what I want to have for dinner, how to save the world,
wondering why you can't make a hard cheese from yogurt, etc, etc. Speaking of
which... time to go to work...

* - In case you were wondering, pizza, you can't but you can do your best to make it a bit better, and you need rennet to split the kappa casein from the casein micelles in order for the casein micelles to stick together using dissolved calcium and phosphate -- yogurt solidifies by reducing the pH to the point where the casein is at it's ioselectric point (pH ~4.6) and it can glob together (but never as tightly as if you remove the kappa casein).

------
jugg1es
Biggest take away here is that working hard pays off. Not a huge surprise, but
it does seem like our industry has forgotten that. The increasing acceptance
of allowing remote work is a contributing factor. Many remote people are
great, but not everyone should be allowed to do it.

~~~
cookiecaper
I've spent almost my whole career as a remote worker. You're definitely right
that not everyone can handle it, but my experience is that most of the time,
unproductive remote workers get cut much faster than their co-located
counterparts.

We all know people who are allowed to coast solely because they're friendly
with a lot of people in the office. Many employees depend heavily on this halo
effect, and expect to be able to wink and nod their way out of what is
sometimes _sickening_ incompetence -- and the kicker is that much of the time,
this works well.

It's psychologically easier for people to trim non-productive remote workers
because there is no physical absence to miss, and the people in the company
are less likely to have a deep personal bond forged over years of lunch breaks
and the like. It's a purer professional context, at least as far as our
profession is concerned.

Declaring yourself a remote worker is a declaration that your work product
stands on its own as a representation of the value you provide, and that you
don't need to depend on niceties like "he tells really funny jokes by the
water cooler" to stay employed.

------
itsdrewmiller
Needs (2013) here. Bookofhook is a really good blog though!

~~~
rb808
I just subscribed to rss, then saw the last post was 2014 so I think is dead.

------
tcfunk
I started running RescueTime in the background on my work machine, and I like
it as a reality check mechanism. It's not enforcing anything or firing off
crazy alerts if I get off task, it just silently records. Then at the end of
the day/week/whatever I can see how much of my time was productive vs
unproductive.

~~~
kerbalspacepro
I've been wondering if there is an open, light alternative to RescueTime for
some time. I don't really need their graphics package- just output an excel
sheet with the data, do only _some_ data crunching and leave the rest up to
me.

------
yters
My productivity hack is to disconnect from the Internet. Being extremely
focused and isolated can mess me up if my work requires external feedback. I
can go way off on the wrong tangent. But, if I know precisely what needs to be
done, disconnecting is the way to go, for me.

------
zemvpferreira
If you're struggling with scrolling on a desktop, use the desktop link:

[http://bookofhook.blogspot.pt/2013/03/smart-guy-
productivity...](http://bookofhook.blogspot.pt/2013/03/smart-guy-productivity-
pitfalls.html)

------
neilwilson
I always work with a picture of my gravestone in front of me engraved with the
immortal words "I wish I'd spent more time at the office"

You are old a long time. Don't waste your youth on stuff that will be
forgotten by the end of next year.

------
elvongray
For anyone who is interested, here is a nice app for productivity boost -
[https://www.rescuetime.com/](https://www.rescuetime.com/)

------
Demiurge
This is a great article, that I think can also be useful from
manager/supervisor point of view.

I think 'mechanical' solutions can also help. I have been lucky that over the
years when I felt like "slacking" instead of news or media, I would read
technically relevant articles, or discussions.

Speaking of which, harray for HN! Billing R&D for this comment.

------
kimikimi
I would be coding now except that I'm travelling in Japan and have not figured
out how to replicate my usual "visit Starbucks" pattern yet - they have cafes
but not with power outlets, generally, so I have gathered that coming to one
tends to mean phone or paper work only.

What I have noticed about my coding habits is that I need a cyclical approach.
For a lot of features the task is in fact smaller than I think and just needs
an initial direct attack. When it isn't, even if I know what has to be done
additionally, I can usually add a stub in the right places and fill it in
iteratively. Stubbing often breaks me out of experiencing friction.

This works up until the relevant code stops fitting in my head. Then
productivity slows to a crawl and I'm far more likely to wander off. I don't
have a direct solution for that. Rewriting the module in question sometimes
works, but it seems to work best after I let the existing code "mature". The
rewrite tries to preserve the inner parts while changing the context to unlock
some more potential.

And there is a hard limit on what I can do before my brain shuts down. There
is an aspect of training to it, and energy conservation too. Familiar problems
are easy to spam out high quality solutions for - pages of code that just work
on the first try. New ones need an R&D phase where the first few attempts
reflect a shaky, uncertain approach. At a higher level of evolution - more
edge cases, synchronization logic, and state to track - the code tends to
require more activation energy, which compounds slowing productivity.

So I currently think explicit iteration might be key: when activation energy
feels high, do maintenance work, and if you can't find low-hanging fruit then
it might be the right time to do an architectural change(not rewriting the
whole program, but changing up the menu of modules and dependencies to reflect
current needs). This is especially true if the overall design goals changed
along the way because it's hard to change course after you built the features.
New designs = new modules.

All of this is a bit different from the work-ethic mode of the article, to
which I would point to physical training as the model: You don't go all-out on
your training every single day, unless you're a pro with trainers and a good
drug regimen that can optimize the recovery time/progression ratio. A more
reasonable goal is once or twice a week to push yourself on something you can
track easily - lift numbers, time/energy, etc. The rest of the time all goes
to recovery or a basic level of maintenance. Distractions during the day
mostly reflect wanting to have recovery time, but not having it instituted in
a fashion that would do so efficiently - nobody teaches brain work as a thing
that needs any kind of rest and recovery period, but the fact of the matter is
that making many precise decisions is tiring, high energy stuff. Lowering the
precision to "only add stub code right now" is both lower latency and helps
conserve energy. Likewise the tendency of code to progress from visual
mockup(feature reports itself as working and maybe surfaces an interface but
doesn't use the "real" data structures) towards an optimized algorithm
reflects an approach of energy conservation.

------
cryoshon
hm, i like a lot of the author's suggestions, but they're missing one big
piece of context.

underachieving is a symptom of work input not correlating to pay output.

why work more if you don't get rewarded for it?

for the joy of work?

sure, but then you are getting taken advantage of because you are putting more
effort in than the company is paying you out. if you notice jobs that rely on
the "joy of work" to get people to do them like science and video game
development, you will find that wages are fucking awful for the effort that is
put in.

and let me share a secret: that is 100% of the time going to be the case no
matter what you do. they don't hire you for your own benefit, they hire you
for their benefit. you get the scraps, even if those scraps seem like a lot of
money to you. do not be naive about this because ignorance is to your immense
detriment.

but let's say someone wants to be promoted. you might have to work hard to get
promoted (assuming your social skills aren't enough -- they're far, far more
important than actual productivity/quality) but you still probably don't have
to be busy 100% of the time. you just need to produce X% more quality or
volume than the next best person. greater values of X might get you noticed
and promoted sooner -- maybe.

that isn't even fully up to you, at the end of the day. hence why
"underachieving" is the norm.

hard work is not correlated to getting paid.

