Smart Guy Productivity Pitfalls
bookofhook.blogspot.de
bookofhook.blogspot.de
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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 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.
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.
yeah, the link is https://chrome.google.com/webstore/detail/track-your-product...
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.
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.
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).
You should definitely check it out.
Spot on. Been digging out of that hole for decades.
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
esacI'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.
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.
"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.
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.
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.
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.
Now, I have defined "4 hours" of actual productive time as goal of each day.