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.
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.
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.
My interpretation of that rule. I think the author is only asking readers not to goof off or postpone work that can be right away. Like mentioned very often, getting into the right context for a task takes some time. So working till 8.15PM instead of leaving at 8.00PM, but completing the task at hand is better than having to come an hour early the next day. I find that even very incomplete insignificant tasks keeps nagging away in your head until you actually get around to do it.
You're spot on. Archimedes said he could move the world with the right lever. Figuring out the right "angle" or abstraction for a task reduces the effort required and often reduces the complexity of the solution, and that happens more often "offline" for me than it does while staring at the code / problem.
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).
Without realizing it, I've been doing the same "CD trick". I play the Monstercat album mixes (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.
After years of expanding my musical tastes, I came back to my original conclusion from the late 90's: rather trashy techno/electronica/house is the way to go for concentration. I eventually realized that even minor vocals will eat away at my concentration, and I can't get much of anything done listening to acoustic, highly vocal music (Elliot Smith stands out as a fine example).
I wear headphones in order to prevent embarrassment.
Never be embarrassed for the music you listen to. Some of us genuinely enjoy listening to shitty house music outside of work :)
I also recommend death/folk metal. It's very high energy, and while there are lyrics they're generally unintelligible or in another language. Equilibrium or Wintersun are good starts.
I'm of a similar opinion. My 'work' playlist is almost exclusively trance music and black metal. Both are repetitive and don't demand your attention, great for concentration.
Xasthur, Nortt, maybe Blut Aus Nord, and a bit further out in various directions I'll say Portal, Aluk Todolo, Jesu, Vuyvr. Should be something in there for you, and there should be plenty of samples of stuff you haven't already heard of on the youtubes.
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.
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.
Just like with the stock market, watching gains and losses with too fine a granularity will make you tense up and "buy high and sell low."
If you're "going long" on your productivity, collect all the data you like--but have a smoothing function between that input and the resulting metrics. That way, 20 minutes spent to gain 3 hours will look like the slight-dent-and-sharp-rise it is, not a scary better-stop-this plunge.
I also feel like it's a really easy way to fall into the trap of only knowing how to write code, which is not what you're actually paid for. You have to interact with the rest of the business and the industry it's in to get good at creating value for a specific domain.
edit: But it's a good point as a general idea, just shouldn't be thought of as an end-all-be-all I don't think.
I think your commentary on the impact of our peer group is spot on. We tend to only work hard enough to compete against our peers.
My assumption is that for a lot of us, we were able to get through school doing hardly any study, yet still achieving top results. The bad work/productivity habits (and that "overinflated sense of your own abilities") were established during this time.
I'm still working on overcoming these bad habits now that I am among smart AND hard working people.
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.
You're understating the issue - we've got entire industries built on the idea of "do what you love", and they're doing a good job. It feeds in to basic human nature.
There was a HBR article recently on HN regarding procrastination that touched upon this aspect.
If I recall correctly, it was saying that we don't need to feel any certain way about doing a task at hand because our emotions should not dictate our (in)action. Recognizing that your emotional self is blocking you from starting an activity just because it isn't pleasurable (ie: don't feel like it), is crucial for those who suffer from this cognitive dissonance, myself included.
Hell, it got me on the treadmill and now running every morning is more habit/routine than anything. I don't even question exercising the way I did before, now it's only asking myself if I either exercised today or not. Starting up running again was only hard because I was stuck in some sort of negative feedback loop of imagining the physical pain of running and justifying the "time lost" in terms of work productivity.
I wish I internalized this process sooner, it's life changing if you let it be.
Agreed. It's likelier that you'll grow to love what you do than you'll wake up one morning feeling like you want to do something that you love.
My theory is this: People like Steve Jobs, etc say "do what you love" once they're already successful. It's not about giving good advice to others, it's about elevating the advisor. It's a modern day equivalent of God's voice speaking to Joan of Arc. "Listen to your heart" isn't great advice when your heart isn't particularly telling you anything, but it makes the advisor look like she's been bestowed with great purpose.
I recommend Elizabeth Gilbert's talk about genius. You're a lot more likely to be "visited by genius" halfway through the daily slog than you are on any random moment of any random day.
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.
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).
> 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.
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/</</g;
s/>/>/g;
s/&/\&/g;
s/"/\"/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
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.
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.
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.
Measure what you care about. If lines of code produced is your thing, then measure that. One year I decided to measure defects released into production, so I could find root causes. I discovered that bad code wasn't my biggest weakness; it was procedures for getting things into production, and procedures for testing and replicating the production environment. So I ended up spending more time getting that stuff right than I did before.
Different people have different kinds of responsibilities and things that should be important to them, based on what's going on in their business and with the rest of their team. Sometimes "hours spent writing code" is the thing for some people, but keep in mind it isn't always the formula for success for all people.
If one does very intellectual work, 8 hours of solid work are pretty hard to achieve. Hardy said in that "four hours creative work a day is about the limit for a mathematician" in A Mathematicians Apology.
I think for engineering work, one might be able to stretch it a bit further. But factoring in breaks, I don't think it is sustainable to go beyond 7 or 7.5 hours.
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.
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.
but is 8-10 hours of solid work really the goal? Or... condensing down the 2-3 hours of real work in to, say, 3 hours, then using the rest of the time in some other capacity?
To answer you and nextos both, I don't have a hard goal. As the saying goes:
"A good traveler has no fixed plans, and is not intent on arriving."
I'm optimizing and seeing what happens. If I hit a stubborn limit, and nothing works to break it, I'll accept it. But at least I'll know what's going on, and as you say, I may plan better the rest of my day.
One anecdote: I can get up to 6.5 or 7 hours of programming in, but I'm utterly drained at this point. I'm sure others can go higher, but my mental stamina gives out completely.
Mine was the same. After 7 hours of real work with no slacking (eg lunch does not count as work), I find it better to switch to easier tasks (docs, organizational, etc).
What did you the rest of the time? There is difference between writing documentation, design work, attending mandatory meeting and checking facebook or video.
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.