3 ms·
When people discuss “knowledge work”, they often slip into imagining an “idealized” knowledge worker: one who is very engaged, and doing “big” meaningful things
by svat 8y ago
When people discuss “knowledge work”, they often slip into imagining an “idealized” knowledge worker: one who is very engaged, and doing “big” meaningful things one at a time.
In reality, (1) we are all distracted, (2) our work usually consists of a large number of small chunks that are spread over time (3) we all have a large pile of undone work (both “job” and “personal”) that we're always feeling guilty about.
What do we do about this difference between the ideal and reality? We could just give up on the ideal and resign to the reality — or even make it worse. Or we could try to fight it superficially, and fail (there's a reason things are the way they are). Or we could start from accepting the reality (instead of ignoring it), but try to move towards the ideal, e.g: (1) reduce whatever it is that makes us seek distractions (very different from blocking distractions), (2) make it easier to get back on track (e.g. keep track of the task being done).
In coming up with this problem statement, the author believes he's diverged from the usual problems being imagined: things like trying to block distractions, trying to maximize efficiency, “collaboration”.
[That just restated the post, so I don't know if it helps :)]
- lifeisstillgood 8y agoA brilliant précis that is actually better than the original article (sorry Mr Bicking)
- TuringTest 8y agoI have an idea for your (2), which is a tool for interrupting you when you are procrastinating, and showing something interesting to do from your TO DO list, adequate to the current moment and place. This could use all the addictiveness techniques of current "engagement+advertising" platforms and turn it to good use.
- commandlinefan 8y ago> who is very engaged, and doing “big” meaningful things one at a time. And one who knows exactly what steps are going to be involved and how long each one is going to take, weeks or even months in advance. The fact that I approach every new programming problem with: "ok, how the hell do I figure this one out?" made me feel really nervous early on in my career, since there seemed to be this default expectation that not just good, not even just adequate, but even mediocre programmers could blurt out a list of the tasks involved in solving a problem, "estimate" (meaning predict with +/- 5% accuracy) the hours associated with each and then robotically plow through each of them. This was back in the 90's, before somebody named this "agile" and built a set of Orwellian tools and "coaching strategies" around it, but after a few years I couldn't help but notice that, in spite of being an abject failure at accurately predicting how long each bug fix was going to take before I even really knew what it entailed, I was also one of the most sought after developers in every organization I worked at.