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.
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 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.
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.
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?
What did you the rest of the time? There is difference between writing documentation, design work, attending mandatory meeting and checking facebook or video.
[+] [-] ebiester|12 years ago|reply
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|12 years ago|reply
[+] [-] unoti|12 years ago|reply
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.
[+] [-] mkartic|12 years ago|reply
[+] [-] xsmasher|12 years ago|reply
[+] [-] tylermauthe|12 years ago|reply
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:
[+] [-] GuiA|12 years ago|reply
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.
[+] [-] was_hellbanned|12 years ago|reply
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.
[+] [-] sillysaurus3|12 years ago|reply
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.
[+] [-] squintychino|12 years ago|reply
[+] [-] Frqy3|12 years ago|reply
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.
[+] [-] db42|12 years ago|reply
Along with the time, I found it useful to keep track of what I got done today. I have defined "4 hours" of actual productive time as goal of each day.
[+] [-] mgkimsal|12 years ago|reply
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.
[+] [-] seivan|12 years ago|reply
[+] [-] superpatosainz|12 years ago|reply
[+] [-] domdelimar|12 years ago|reply
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... that's close to what I was looking for.
[+] [-] LordHumungous|12 years ago|reply
[+] [-] ixmatus|12 years ago|reply
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).
[+] [-] unknown|12 years ago|reply
[deleted]
[+] [-] db42|12 years ago|reply
You should definitely check it out.
[+] [-] joemaller1|12 years ago|reply
Spot on. Been digging out of that hole for decades.
[+] [-] gwu78|12 years ago|reply
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.
[+] [-] mkartic|12 years ago|reply
[+] [-] unknown|12 years ago|reply
[deleted]
[+] [-] thinkersilver|12 years ago|reply
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|12 years ago|reply
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.
[+] [-] unoti|12 years ago|reply
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.
[+] [-] nextos|12 years ago|reply
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.
[+] [-] thinkersilver|12 years ago|reply
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.
[+] [-] db42|12 years ago|reply
Now, I have defined "4 hours" of actual productive time as goal of each day.
[+] [-] mgkimsal|12 years ago|reply
[+] [-] watwut|12 years ago|reply