With many writers talking about the factor of “complex code” and it’s effect of making task switching more difficult, doesn’t this imply that less complex code is better/more productive? Not trying to start a Holy War, but score some points for Java here.
I’ll agree that programmers often dive into things and write hacks that paper over whatever software is in place, expanding complexity without much benefit. Over a very little time the layers of hack solidify into the traditional Lava Flow…
An interesting thing is that Managers have similar harmful patterns. Lack of priorities, lack of specification, lack of learning from the past. Sending more emails does not accomplish work if there are more interruptions than communication.
Nobody is saying managers are perfect. The next time I see a co-operative effort where one person involved is not, at least to some degree, at fault will be the first time I see that.
Oh, My. I must suck.
But that’s okay. I don’t mind. Really. I find that I write a LOT of code that requires rewrite. What I find most telling is how long it takes to get it into my head. In my current project, there are a couple of routines that take hours to re-assimilate, and I just dread such work. But it must be done. God help the poor soul that tries to get me to change to something else. They don’t refer to “The Nice Jim” and “The Mean Jim” for nothing.
I don’t mind music, conversation, meetings, etc. when I’m working on something simple, but when I’m working with the more complex routines, “The Mean Jim” is the only one that can accomplish anything. The pointy-haired boss doesn’t like “The Mean Jim”, but he’s the only one who gets anything done.
Task switching among complex tasks costs me loads of productivity. That may be a totally subjective, meaningless, metric, but still a lot.
@Ryan et al: I agree that some task switching is okay. I tend to work best on two tasks at once, with one getting my full attention, and the other simmering on the back burner. When the main task gets stuck or tiresome, I swap tasks. Many intractable tasks become soft and manageable after being simmered for a few hours.
This works to an extent with three tasks, but not nearly as well. More tasks are impossible, unless there’s only 1-2 per day, in which case it’s not as bad.
Are there studies that measure how more productive people are if they work at home + communicate w/ IM and phone with coworkers? I love it! At every opportunity in which my boss whines I’m never in the office, I suggest that all programmers be required to work from home 2-3 days/week, to help speed development
“The Mean Jim” - I like it!
A few months ago, I was at a 30+ people team meeting and we had a huge make-or-break demo the next day. Someone mentioned something pretty early on that was going to break EVERYTHING all to pieces. I flipped open my laptop, put my mean face on and started coding 100 lines a minute. My coworker on the team told me later that there were all sorts of questions that were asked passive agressively to the group in general. Everyone was hoping that I would pick up on them and explain things away, but no one dared address me directly. Not that it mattered; nothing short of a fire alarm was going to make me look up from that screen.
I love this quote “Many intractable tasks become soft and manageable after being simmered for a few hours.”
If it was intractable, it could not have become soft and manageable after a couple of hours of thought.
So, why do I love this quote? Not because it allows me to point out somebody’s illogic but because it goes to the heart of everything I’ve been trying to say about design vs. hacking.
What shavenwarthog (good name by the way) is probably saying is “often a task that seems intractable can be solved by thinking about it, even sub-consciously, for a few hours”. This statement I agree with fully (especially since they are my words attributed to others - like a god shoving thoughts into the heads of my minions)
The problem with hackers is that they run into these seemingly intractable problems and just dive into them, solving them in the first manner that occurs to them - usually the most brute force approach that could be envisioned. Generally, when doing this, they are not building a simple throw away test app or creating new code; no, they are modifying existing code while they do this so the damage their bad, brute force solution causes ripples through the codebase as they tweak things here and there to make the poorly analyzed, poorly considered idea work.
In this case, a context switch to let your sub-conscious work on the problem (remember, it uses 90% of your brain and your conscious uses 10%) instead of your conscious mind allows you to think through the problem which is, after all, step 1 in design. Then all that remains is to record the design so others can comment/review and later learn about what you are proposing. Doing the design is yet one more way of forcing you to think about the problem instead of hacking out the brute force solution.
Now the comment by buggyfunnybunny of “I’ve always been amazed that folks don’t find the existence of the Sequence Diagram in UML just the teeniest bit ironic (well, dumb): a fig leaf to cover the proceduralness of what OO designers are really doing.”.
I promise to think about this one since I’ve never thought of the sequence diagram that way. However, my initial reaction is to disagree. Sequence diagrams that show purely procedural code are lousy - they don’t design anything since you make call “Foo()” to object “Blee” and then it returns. The reader has no idea what went on inside Foo or what effect it had on Blee or the world around Blee. A well done sequence diagram shows how multiple objects, each with its own areas of expertise being exposed by their contract with the world, co-operate to accomplish a common goal. It is, in that sense, OO in its purest form.
I forgot to add:
The flow of a sequence diagram and the flow of procedural code are only similar in that each illustrates actions over time. Time being one of the critical dimensions in my universe (and likely yours). The flow of time is something that every system must address. Without addressing the passage of time and events across time, the system doesn’t really model anything in the real universe.
A few random comments in no particular order (or relevance!)
A) I actually program better with music on than without; really anything that requires deep thought actually. I find it far more difficult to “zone” without music – sometimes even impossible.
B) The company I currently work for is extremely into multitasking in the truest sense of the concept – everyone working on many ongoing project teams across multiple time zones and completely asynchronous schedules, and in all honesty I feel like I am less productive, creative, and produce worse code than at previous jobs that were aligned more along more classic “big projects” where you could focus on one major thing for some period of time.
Between emails, IM barages, phone calls, meetings, and random / unplanned /unexpected distractions and knowledge tapping an entire day can slip away with no real coding or technical work being accomplished.
All to often I find myself having to code in my laughingly referred to personal time in the evening hours just so I can get some freaking work done without distraction. Its just very wrong.
The most frustrating part of it is of course, most of the IM’s emails, phone calls, and meetings didnt REALLY need my input; all to often I’m being roped in to serve as a woobie to make someone else comfortable making general technical decisions, to hold their hand through something that should be a routine part of their job, confirm or refute things they should already know, or just provide general brainpower. Things that have nothing to do with the actual development of software, in other words.
(Who here has ever felt the urge to automate the jobs of their co-workers just so you could get some peace and quiet?)
D) Another problem with the multi-tasked environment is that monolithic blocks of time where all the principles involved in a project focus and hammer things out are practically impossible to accomplish; even suggesting “Hey, shouldnt we actually take some time and figure out a good design for this BEFORE we piecemeal it out and hope it all somehow works” will draw “whose this crazy person?” looks in this sort of environment. No one takes the time to do things correctly and focus on process and design in such an environment; the entire culture of such a setting is founded on a unstructured non-process and its anathema to intelligent focused development.
C) However all that aside, what I find most frustrating and annoying about multitasking is the inevitable fallout that occurs when you leave things half done, do things in a rush between interruptions, or get part of something actually done but have to do a brain dump and spin up on one or two or five different other projects before circling back to develop related components / consuming code, or what have you.
This and other interrupted scenarios causes mistakes, sloppiness, disjointed, and buggy development. Errors, either in concept or execution or both creep in all too often. The product is compromised. And if you are constantly chasing deadlines on most or all of your multiple projects that you are multitasking between…it just gets worse.
I’ve made several mistakes that I know I never should have or would have made if I was able to focus and finish a key piece without distraction or interruption, that were directly attributable to fall out from multitasking.
This is the real bugaboo of multitasking for me, becuase even if you do realize some time saving, and are able to “cover” a majority of tasks that are so routine or subcranial that you can handle them even at 40 or 50%, the mistakes or losses of efficiencies that crop up in those tasks that take 60 or 80 or 110% to get done correctly have costs that are realized later on.
In the end I always recall the saying “Fast, Cheap, Good – Pick Any Two”. Multitasking is Fast and Cheap, but it aint good.
To be completely honest i am a horrible multitasker. Some peaple are awsome multitaskers and other well…well just say that they shouldnt drive while talking on the phone or…well…CRASH!
And whoever mentioned females being better multitaskers was definitly right about one thing but comepletly wrong about how men and women worked in the stoneage…you could use a little history lesson.
I object to the idea of a statement like “women are better multi-taskers than men” unless the poster provides a reference to a critical reference where this was proven in a sound experiment or at least a good “thought experiment”.
Remember the idea here is that people “think” they are effective multi-taskers. This conjecture seems to be more of this type of groupthink that leads to a continued belief that unplanned multi-tasking is laudable rather than wasteful.
i tried to email this post to some of my colleges half way thru reading it because i thought they would be interested… and sent the wrong link
How do people feel about working multiple task while slightly inebriated?
Here’s a website that discusses some of the results of real studies on the differences between men and women’s brains, how they develop, and how they are used in different scenarios (including multi-tasking).
It’s a TED talk about getting in the flow or entering the zone.
When we do that all our sensorial bandwidth is used for that task, so we can’t even process our own body. Like a OS which is using all resources running one process without passing into kernel mode.
@ Robert Kozak You might want to read Crenshaw’s The Myth of Multitasking. He talks about the women-men issue specifically.
Johanna Rothman has talked about this over the years:
It’s often a symptom of trying to manage software development projects as a typical business project - break a big task into a bunch of smaller tasks and assign them out. With that mindset, it seems simple to tell Worker #145 to stop task 5 and work on task 6 a little bit - stop shovelling blurps and start ratcheting vleeps. It comes from treating software development as unskilled labor.
I agree with Rob Conery on this, though. I find that it’s best to have one major project and another side project which is not urgent or complex. It’s good to be able to take a short break from mindbending stuff and crank on something simple. It’s also helpful in the case where the main project is subject to delays for business review, waiting on information from outside sources, etc.