Posted by
CowboyNeal
on from the diary-of-a-madman dept.
bsadler writes "There is a pretty interesting article on the psychology of a programmer over at devx. It includes some suggestions that a manager might take into account when dealing with programmers. Maybe my boss will finally give me my own office."
Space/time to walk (at least for me a lot of my ideas come when I'm walking, and walking help me to decide on alternatives)
Music (not so good to makes one want to hear the music instead of working, neither something so bad that breaks concentration)
Re:Other ideas
by
grungie
·
· Score: 2, Interesting
Yes walking and breathing fresh air are also very important to me and usually bring me the best ideas.
One thing that seemed strange to me in the article is the author claiming that pair-programming does not break the creativity flow. While this may be true per se to a large extent, eXtreme Programming (the most popular pair-programming methodology out there) is about pair-programming in open offices, where nothing stands in the way and you have no privacy. Not quite what he is advocating... Have you ever worked in a place where programmers are mixed with customer support and paperwork people spending somewhere between five and eight hours on the phone every day and hailing from one corner to the other while you're trying to concentrate and produce some meaningful code? If something breaks my concentration span, it is noise. Definitely.
There are many different types programmers out there with different strengths which are definently related to their personalities. I agree with the article about how creative programmers can enter a state where they can see the problem from a holistic viewpoint and then code just starts to flow from them. I have experienced this state several times, where I space out and my fingers just start bashing away on the keyboard producing code with suprising compiles that first time, bug free, and does exactly what was needed. When this happens, according to what my friends say, I don't respond at all to them, what they say goes in one ear and out the other. This also happens to me when I play my guitar, when I get going on a groove I just zone out until I have finished. When I do get forcefully interupted there is hell to pay, it is extremely annoying to having someone force me out of such states.
This state of mind reinforces to notion that creative people make good programmers, possibly better than less-creative people. The odd thing with this is that I did horribly in the non-science courses in school. I got 75% in english while the majority of the class got 85%. But then again I did really try, I never paid any attention really although he was a really good teacher.
Another interesting thing is that in a project I was working I never commented any of my 7000 lines of code yet when I came back to the code half a year later, despite from what most people say, I could still clearly remember what each line did.
In further explanation of my persona and why it makes me a good programmer is that despite being a complete geek I am also into extreme sports, downhill biking, windsurfing and so on. These are my outlits for taking a break.
Is anyone else like this?
Re:Please forward to our foreign compatriots...
by
Anonymous Coward
·
· Score: 2, Interesting
I manage a team of programmers in a foreign country and I can tell you, it isn't worth it.
We pay them $10/hour but the work they do normally has to be redone 2 or 3 times before they get it right, and even then, the code is awful: Variable names like x and z, C when they are supposed to be using C++ and lots and lots of access violation errors that destroy all the hard work that I do.
I would rather pay a good programmer $50/hour.
At first I thought, for $10/hour how can you lose? But in retrospect I'd say the problems just about outweigh the benefits.
what's with the feminine pronouns ??
by
Anonymous Coward
·
· Score: 1, Interesting
"When creative people work on making something new, they often enter a mental state where things just flow. This is a highly desirable state, both for the programmer herself and for the organization that profits by her labors."
what's w/ this recent trend towards using feminine pronouns where they're totally inappropriate. I don't think that I've met more than three female programmers in the decade that I've worked in this area. There are a sizeable minority of female sysadmins , but very very very few women programmers. Is cousin fester trying to be PC , or is he just totally oblivious to the fact that for all intents and purposes there are no female programmers.
In general this article is queer , frankly most of what proports to be psychology is bunk. Programmers are actually alot like engineers. I think this guy has a very shallow understanding of what engineers do. Programmers certainly aren't like most of the artists I've met. It's nice that he recognizes that development entails a creative process , but that's only one aspect. The rest is pretty clearly engineering.
He doesn't understand Scientists
by
AlecC
·
· Score: 4, Interesting
Contrary to popular belief, programmers more frequently resemble artists than scientists. If you want to maximize the creative potential on your development team, you've got to start thinking about the psychology of the programmer and be willing to back it up with management policy.
Which shows that this guy doesn't know scientists. Scientists - true scientists, not technicians - are very like this guy (correctly) describes programmers. Both programming and scientific research are creative skills which, as the man says, require you to be "in the groove". He is not wrong about programmers - he is wrong about scientists. Techicians, to some extent, have less need to be "in the groove" - though much of what he says applies to any human being, with only the time constants varying.
OTOH. 3. Accommodate Reasonable Special Requests. When I get really stuck on a design problem, I go for a walk in some very beautiful woods about three miles from my office. An hours walk in the woods has about an 80% chance of delivering a solution to the problem. Even, curiously, if I don't spend much time conscioulsy thinking about the problem. In fact, I sometimes feel that by subconscious is telling my conscious to let go that problem and leave it to me. Dropping a problem for an hour or day and then coming back to it can be remarkably constuctive.
In fact, I sometimes feel embarasssed that the conscious "me" claims credit for the bundle of mad scientist, lechers, random thought generators, and idiots who inhabit my subconscious and do all the work.
-- Consciousness is an illusion caused by an excess of self consciousness.
No longer true
by
Bugmaster
·
· Score: 3, Interesting
The article says,
you should stop treating them as pluggable units, each with similar capabilities.
I no longer believe this is true. Most programming tasks nowadays involve picking up some toolkit, an IDE, and an office chair, and then dragging icons around to combine parts of the toolkit into some working product. Visual Basic especially is a good example of this, but Java/.Net, plain old Windows GUI programming, Web scripting etc. are also way past the point where creativity matters. There are well-known solutions (f.ex. design patterns) for most problems, and CS students in today's colleges are only taught how to apply them. They are no more creative than assembly line workers.
That is not to say that our education system is evil (well, it is, but that's not the point) or that people today are stupid. The reason for this programmer pluggability is that the market evolved to the point where creativity simply is not neccessary, since most common problems have been solved and codified -- and there is no demand for uncommon tasks.
The only two places right now (IMO) where creativity and real intelligence are needed are the embedded coding and theoretical CS research. Theoretical CS research requires creativity because it's, well, research. Embedded design requires creativity because the resources are so limited, and a pre-designed solution simply will not work in your PIC16 microprocessor with 4Kb of RAM, and so you must be really tricky to make your program fit into the limited space and time constraints.
Outside of these two niches, programming has truly become similar to construction work: a few engineers design the building, and then 100 grunts carry bricks around and hammer nails until it's done.
-- >|<*:=
Re:No longer true
by
Dixie_Flatline
·
· Score: 4, Interesting
I agree with this, and I don't.
I'm sure most programming in big business environments has become very sterile. In a Dilbert-esque setting, I can see where you're coming from.
Where I program, I'm not sure that holds true (though I'm well aware that the kind of programming that I do is somewhat atypical). There's an overall design, but programmers are given subsystems to implement. They're told what it has to do, but not necessaily HOW it has to be done. Each programmer at the company could complete the task, but I'm sure no two solutions would never be the same.
As for CS students learning things by rote: I was going to say that you're wrong, but then I thought about it and decided that you're partly correct again. I saw a lot of people with no love for computing get through computing science because they test really well. Me, I test like crap on a stick, so I had to actually learn the lessons of algorithmics and creative thinking that are the subtext in those classes. I think the majority of people that go through CS and never once think about any sort of research career path are the kind of boilerplate programmers that you're talking about. Someone that has some desire to discover something new will make a perfectly creative programmer in the real world, and it may happen more than you think.
I think the article has an interesting perspective, and I totally understand the "in the zone" argument. Sometimes you have it, sometimes you don't, and sometimes an interruption really is just soooo irritating.
However, I'm not sure the suggestions are really the way forward. In particular, such research as I've seen (sorry, can't cite a link off the top of my head) suggested that actually, a small team of programmers was much more productive in their own open-plan-like "team space". There are several logical explanations for this, not least the fact that if you do get stuck with a mental block, help is just a question away. You also get interaction with conversations other members of the team have, and either learn something yourself or offer them a solution neither of them knew about but you did.
Sure, you need to have a team who get on, and realise when someone is really going for it so they don't interrupt at just the wrong moment. But all that really takes is having a little consideration for your team-mates, and a willingness to say "Can I get back to you in half an hour?" without being distracted, neither of which is hard to do. No-one really sits in the zone all day, it's more like a few minutes when the germ of an idea comes to you and you want to flesh it out, and that's the time when it's bad to be interrupted.
Other than that, I find it's much more helpful to have the interaction for the remaining 90% of the day, so you don't get "programmer's block" and just sit there thinking about a problem but not really getting anywhere. I guess this is one of the major advantages of "pair programming", too, if you've got people who are happy working together that closely.
I agree that programmer comforts are generally a smart move: where I work we have a decent flexitime system, concern over things like chairs and lighting, headphones so people can listen to CDs while they work and, yes, even a shower. These are all good things, appreciated by the developers, and so the developer productivity and loyalty is very high. But we still work in an open plan office, even if everyone does have "their space" in it.:-)
-- If you disagree, post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like.
As a 'Brit' I too find this very odd. Consider this small chunk of text:
When creative people work on making something new, they often enter a mental state where things just flow. This is a highly desirable state, both for the programmer herself and for the organization that profits by her labors.
If written by someone from the UK (and probably AU or NZ) this would be written like this:
When creative people work on making something new, they often enter a mental state where things just flow. This is a highly desirable state, both for the programmer themself and for the organisation that profits by their labors.
No use of gender, and perfectly correct English too.
-- Blaming GW Bush for the Iraq war is like blaming Ronald McDonald for the poor quality of food.
Re:Please forward to our foreign compatriots...
by
goosman
·
· Score: 2, Interesting
I was wondering how much of this 'psychology' is cultural. Do these programmer 'sweat shops' in non US (or non Western) locales suffer the same problems of distraction that as their US counterparts apparently do? I feel I'm lucky that I'm in a situation where distractions are kept to a minimum (well, really it's that I control my distractions myself) but if I were to be thrust into a more distractive environment my creativity would certainly suffer. Does the guy in Elbonia feel the same way, or does he work in an active environment with no loss of creativity.
My experiences of programmers
by
Anonymous Coward
·
· Score: 3, Interesting
After 8 years of software testing and QA, here are my experiences of programmers. No it's not flame bait - but mark it down as you wish
1. They do not know the meaning of deadlines! How many times, I've been working late because some dim wit of a developer didn't see the importance of actualy meting the deadline he proposed himself. Working late evenings, working weekends because the programmer didn't see why he should put the extra time in to catch up. Sounds familiar?
2. They do not know the meaning of quality. How many times have I sat there with a program or package from development that simply will not work / start-up / compile. All this despite development's assurances that they do actualy unit test. I once had to test a program that did nothing, ie it was called from another program, but all it should do is close itself down - it was a stub. How difficult is that to program and how difficult is that for the programmer to test themselves? It took SEVEN attempts to get it right!
3. Keep it simple stupid! How many times have I had to sit there wondering if I was looking at the correct Buisness Requirements and Functional Spec. Final designes seem to be as complcated as posible rather than simple. Functionality slippage is common - lets put this bit in as well.
4. Yes, but programmers are artists. Bollocks! If you look at almost any system, you will see that the basic number of functions is very limited. Given any average office system, you could probably find public domain code to do 90% of what you need. Yes it will need changing and tweaking, but this idea that you sit there creating is simply rubbish. Perhaps if you stopped creating and started engineering things would be better.
5. The Prima Donna syndrome. Programming used to be a black art. Well it isn't any more. However, some developers seem to think they should still be treated differently as this article demonstrates. If any other professional argued that they needed a kip durring the day, they would probably be booted out. You want a kip, have it at lunch time! Not having a much time at lunch - welcome to the real world.
I know this is going to be marked down as flame bate, but it has to be said it is about time that programmers came back into the real world. With comments like If a programmer's flow is interrupted it can take a large amount of time for her to regain the state, sometimes up to an hour. do you realy wonder why people question programmers professionalism? Everyone else has to work hard for a living, and creativity comes into most jobs, but most just get on with it.
I felt like I just visited a shrink
by
wordisms
·
· Score: 5, Interesting
I've got to say that article was quite the ego booster.
First, programming is most definitely an art as it is a blending of layout, design, creativity, and tasteful hacking to derive a solution.
The section about programmer's concentration was interesting, and I definitely fall into that category. It is nothing for me to sit down to go through the process of designing, coding, debugging, and repeat for 8 hours, without realize it at all. It only speaks of my passion for my work, and my enjoyment in solving challenging problems.
Poster here who have noted about treating programmers more like people than equipment hit the nail right on the head. In my school, our proffessors warn us to avoid jobs that look as though the employers treat programmers as "code monkeys" (if you sat enough monkeys at computers typing C, how long would it take until you get MS Office?). At some of my best internships, and the job I have gone back full-time to, my section leader encourages his team to take regular breaks (which often involve heading back to an ongoing game of RISK), schedules frequent offsites/classes/excursions to get us out of the cubicles, and overall creates one of the healthiest work environments I've ever been in.
All that said, I shouldn't be to programmer biased. Not all programmers are great programmers who have mastered that mystical "flow". I could see a manager reading this article, trying all these things, and getting really burnt.
It's all a game of balance that definitely begins with treating employees like people, not equipment.
Re:I felt like I just visited a shrink
by
jkczyz
·
· Score: 2, Interesting
Designing software is an art. Programming is not an art, it is a craft. The people that design software get paid much more than the company's programmers do. Programming is entry level for a reason. With a good design the actual time spent programming accounts for only a small amount of the total time a project takes to be completed.
Lockheed, for instance, does not hire people to program anymore. They contract out, but handle the project design themselves. They are also a CMM Level V company (at least one of their division is). Of course, with most companies being at Level I, the whole concecpt of design often gets thrown out the window.
Re:I felt like I just visited a shrink
by
renehollan
·
· Score: 4, Interesting
Designing software is an art. Programming is not an art, it is a craft.
Oh, I take exception with this!
You can't program anything of significance if you can't design, and you can't design if you don't understand how the design is to be programmed. Put more bluntly: pseudo code ain't gonna compile.
Now, it is fair that some of us spend the bulk of our time designing sytems, and others implementing them, stressing the creative or crafty aspects of our skills. But woe unto the programmer who is not aware of the intended (i.e. designed) interaction of components: such a person debug, can't (oops, forgot the </yoda>).
I've been coding for over 20 years. Under my belt I have significant design contributions to:
1. Dataradio synchronous full duplex repeaters and mobile radio modems (mid 80's Z80 code);
2. Nortel's ADAS+ employing speech recognition in the telephone network for directory assistance (T1 A/B bit signalling and parallelization of Viterbi decoding over multiple TMS320 DSPs under pSOS, with a smattering of assembler, and clever allocation of data to memory with various access latencies as appropriate);
3. Teradyne's RMU75x telco loop diagnostic units (TCP/IP and steams-like protocol stacks under MQS on TMS320C30.
4. Chiaro's Optical Router project (automated, distributed test tools, with C++ on FreeBSD, and custom marshelling schemes; as well as porting Gigabit Ethernet device Drivers (C on FreeBSD).
While hapily mentoring less-skilled developers (I actually like the title "Software Engineer" since it reflects the combination of creative design, tempered with proved implementation methods) and even distributing development work, I refuse to ever accept promotion into a primarily management, or even "design" role: creative design often needs to leverage advanced programming techniques -- ever notice how the complex parts of programming languages, like templates, overloading, partial template specialization, and template template parameters, to use C++ as an example language are there to support design patterns and principles?). I have been, and always will be, a programmer: even when designing Emacs is my canvas, and I expect C-x C-c to be engraved on my tombstone.
Those who see programming as only an entry-level path to eventual design and perhaps management roles are taking an extremely narrow view. Career progression should more closely follow at of carpenter: apprentice, journyman, master. A master carpenter remains a carpenter, nevertheless. Even if he takes on architectural roles, they will be enhanced by his knowlege of the craft of carpentry.
Painting is an art. Playing a musical instrument is an art. Programming, like everything else explicitly constructed by man, has distinct rules to it that allow one to do well, and can be objectively deconstructed to what makes it good or bad. Calling programming an "art" is just self-congratulatory tripe that people spew to fool themselves into thinking that they have a human side.
--
--sdem
Re:what's suggested in article is the best way
by
Anonymous Coward
·
· Score: 1, Interesting
Yeah I work that way as well - I need to explain the problem to someone else sometimes before I come up with the solution.
A good manager of programmers treats the coders as professionals. If someone wants to lock themselves in a silent room, go for it. If someone wants to do pair programming outside on the front lawn of the building, go for that too.
My best projects have come out when doing team programming, we'd sit next to eachother and talk back and forth about the problem.
The best way to manage this is by good office design. Having centralized offices, but with a shared space in the middle with cubes, really helps. The people who want silence can close their doors, the Pair Programmers can plop down in the cubes with their coworkers and go at it.
Re:Please forward to our foreign compatriots...
by
Anonymous Coward
·
· Score: 1, Interesting
You know it has to be said that programming, really good programming, comes about through a passion and enjoyment of your work. Achieving goals, pushing the envelope, competing with other programmers, learning new tech - its all exciting stuff. But pay me $4 a day working on some brain number of a project I dont give a shit about and you know what kind of code you're going to get back? Crap.
I've had jobs as a "web developer" where idiot VB coders would frown on me, giving me the script kiddy jibes (which is fresh considering the use VB). It amuses me however, I got into web design to learn new tech like XML and web services. I used to write games, I've hacked ASM on a variety of processors- was using C back on the Amiga. But anyway I digress- that environment did nothing for me, the management sucked, the didnt understand creativity (I could stare at a screen for hours putting connections together in my head) but if code wasnt being written I was a slacker. Shame really, I left to go it alone.
If they bothered to pay attention to my previous employer where I got soooo wrapped in my own AI app that I would work 24hrs at a pop they would see what a resource they lost.
Programmers are different. They are not productio line workers churning out pre-formed shit. They love what they do, care about it (I love prettifying my code as I near completion), each app for me at least is a work of art and no-matter how these foreign programmers are touted as being hot shit, I just know they wont care as much as I do, and the results will reflect that.
Sorry for the rant- people will come around eventually. You want great software? Pay the price, this isnt factory work.
Re:It's not really psychology
by
Snork+Asaurus
·
· Score: 4, Interesting
I'd like to LART some managers who come by every 10 or 15 minutes while I'm working on a project with a very tight deadline, and ask 'Is it done yet?
Under a very tight deadline, I once told a manager quite forcefully:
"Look, each of us has an obligation to the other here. Your obligation is to do everything you reasonably can to empower me and enable me to meet the deadline. My obligation is to do everything that I reasonably can to meet my commitment on this deadline and to inform you when there are things that you can do to improve my chances. Therefore, as part of my obligation, I have to inform you that by constantly interrupting me to ask me how it's going, you are breaking the concentration that I have spent several hours building and reducing my chances of meeting the deadline in the order of 2 or more hours* per interruption."**
He looked quite shocked at first but then seemed to summon his memories of his days in the trenches, apologized and backed off. We had a new understanding from that point on.
----
* 1/2 hour to cool off + 1 hour to re-build my mental state + 1/2 hour fudge ('cause we always gotta fudge;)
**(This is what I said IIRC. It was some years ago and legends tend acquire new dimensions over time. It's also possible that I said something more concise like "quit f---ing bugging me, so I can get this done". I can't remember exactly now.)
-- Sigs are bad for your health.
Software as an Art Form
by
rodney+dill
·
· Score: 2, Interesting
I don't know if I can agree with the statement anymore that programming is an art form instead of a science. I certainly recognized the creative component when I was programming, and at that time there not much engineering discipline applied.
In the last ten years there has been a lot of movement to add discipline to the software engineering process. The Software Engineering Institute/Capability Maturity Model (SEI/CMM) may be the chief among these, as its creation was originally sponsored by the US Department of Defense. This model does take a lot of the fun out of programming, but it does provide the business benefits of a disciplined approach, which is chiefly a reduction in defects.
I think there is a mechanism in physical engineering that does not carry across well into software engineering organizations that follow SEI/CMM or other programming methodologies. In building construction you have the architect who applies both functional as well as creative/artistic qualities to the work. Then you have the (civil or other ) engineers that apply more of their discipline to make sure that the building works and does not fall down and meets other requirements. This is oversimplified as there is a necessity for creativity at all points of constructions, but I don't think this analogy carries well to software organizations. Maybe it does in web development groups, but those are outside my area of experience.
--
Use your head, can't you, use your head,
You're on earth, there's no cure for that - S. Beckett
Good Interruptions
by
SpaceRook
·
· Score: 2, Interesting
Sometimes it is good for a programmer to be interrupted.
Some author - maybe it was Hemingway - said that when he was done writing for the day, he'd always stop while he was still "into" it. This gave him something to look forward to the next day. It gave him a place to start.
I think a similar technique is useful for programmers. For example, say you are writing a really fun function but only have 10 minutes of work left. I say, stop writing! Spend the rest of your time on the net reading some tech articles, or improve your code's documentation (if you think documentation is boring, maybe you aren't doing it right. When you document, pretend your talking to another programmer about your program).
When you come in the next morning, you'll have an easy way to start the flow again. You won't be hacking around trying to figure out what to do next.
Hacker Employment FAQ
by
malachid69
·
· Score: 2, Interesting
Personally, I have always planned on making the Hacker Employment FAQ part of the management handbook when I start my own company.
Malachi
-- http://www.google.com/profiles/malachid
Cubicles KILL productivity!.
by
LibertineR
·
· Score: 2, Interesting
Most companies can increase programmer productivity and efficiency by not being so fucking cheap, and getting rid of cubicles. I was a programmer for 4 years prior to coming to Microsoft, and in my first year in my own office, I wrote more code and BETTER code then I did in 4 years in my cube at Lotus.
I hated being in the building, not wanting to hear who was porking whom from a three cubes down(you know who you are, Bitch!)or the personal problems of a bunch people who hated management, hated the products they were working on, and hated life in general.
Once I got my office, or more importantly, ONCE I GOT MY OFFICE DOOR, I could shutout the bullshit, crank up the tunes, and get down to business. Microsoft lets you decorate your office however you want, so over time my office became my favorite place to be. People joke about how people at Microsoft would rather send email to someone in the office next door, rather than get up and ask a question face to face, but nobody likes to be interrupted from a programming train of thought.
I would never, EVER again work as a programmer, if it meant going back to a cubicle. In a cube, you are nothing but a faceless, nameless pod person, waiting to be replaced by some other pod who wants to work for less than you do.
What we have here is a classic case of "telling programmers what they want to hear". I wonder if this guy is selling something?
--
--sdem
Peopleware on Music and Programming
by
prankster
·
· Score: 3, Interesting
Music (not so good to makes one want to hear the music instead of working, neither something so bad that breaks concentration)
In Peopleware DeMarco and Lister writes about a series of test at Cornell on the effects of working with music in the 1960s:
The result was that groups with and without music performed about the same in speed and accuracy of programming.
However, the output data was to be manipulated about a dozen times. The net effect of the operations left output number equal to its input number.
The overwhelming majority of people who figured it out came from the group working without music.
If the right brain is busy listening to music the opportunity for a crative leap is lost.
So if programming is a crative art do not listen to music.
Re:It's not really psychology
by
SN74S181
·
· Score: 2, Interesting
It doesn't matter how much 'wonderful' code you were producing. If you weren't there at the same time as the other people working on your team and/or the people who define the requirements, you weren't working cooperatively. You can spin algorhythms into the night to scratch your own itch. That isn't what you're paid for.
Dealing with interruptions
by
hlh_nospam
·
· Score: 3, Interesting
I had a problem with my management along those lines. I started getting up and making a tally mark on the whiteboard in my cubicle every time I got interrupted. About the fourth time my manager came in and saw me do that, he asked me what the marks were for, and I explained to him that he could multiply the number of marks by 15 to get the amount of productive time I lost due to interruptions since I arrived at work that morning. Turned out that the number was roughly equal to the time I had been at work that day. I had a copy of "Flow" with me, and I loaned it to him.
He actually got the message. Not only did he quit bugging me, but he actually started running interference for me. Unfortunately, I haven't had many managers who were that bright.
Re:It's not really psychology
by
archen
·
· Score: 2, Interesting
It's sort of puzzling that many of us can understand the interruption problem, but many who are our MANAGERS do not. A (part time) professor at college told me about how he was a manager and how the place he worked for endlessly harassed the programmers. Eventually he set up a system so that you had to go through a secretary and then it was determined if it was absolutely critical, otherwise you just got dumped to a voice mail box. It sounded like a good idea to me, and now that I work for a place that interrupts me every 10 minutes for a "just reboot your computer" answer, I appreciate it a lot more.
Software bees
by
UncleSocks
·
· Score: 5, Interesting
Whenever I read useful articles such as this, I'm reminded of Orson Scott Card's "How software companies die":
Software - How Software Companies Die
By: Orson Scott Card
The environment that nutures creative programmers kills management
and marketing types - and vice versa. Programming is the Great Game.
It consumes you, body and soul. When you're caught up in it, nothing
else matters. When you emerge into daylight, you might well discover
that you're a hundred pounds overweight, your underwear is older than
the average first grader, and judging from the number of pizza boxes
lying around, it must be spring already. But you don't care, because
your program runs, and the code is fast and clever and tight. You won.
You're aware that some people think you're a nerd. So what? They're
not players. They've never jousted with Windows or gone hand to hand
with DOS. To them C++ is a decent grade, almost a B - not a language.
They barely exist. Like soldiers or artists, you don't care about the
opinions of civilians. You're building something intricate and fine.
They'll never understand it.
BEEKEEPING
Here's the secret that every successful software company is based on:
You can domesticate programmers the way beekeepers tame bees. You
can't exactly communicate with them, but you can get them to swarm in
one place and when they're not looking, you can carry off the honey.
You keep these bees from stinging by paying them money. More money
than they know what to do with. But that's less than you might think.
You see, all these programmers keep hearing their parents' voices in
their heads saying "When are you going to join the real world?" All
you have to pay them is enough money that they can answer (also in
their heads) "Geez, Dad, I'm making more than you." On average, this
is cheap. And you get them to stay in the hive by giving them other
coders to swarm with. The only person whose praise matters is another
programmer. Less-talented programmers will idolize them; evenly
matched ones will challenge and goad one another; and if you want to
get a good swarm, you make sure that you have at least one certified
genius coder that they can all look up to, even if he glances at other
people's code only long enough to sneer at it. He's a Player, thinks
the junior programmer. He looked at my code. That is enough. If a
software company provides such a hive, the coders will give up sleep,
love, health, and clean laundry, while the company keeps the bulk of
the money.
OUT OF CONTROL
Here's the problem that ends up killing company after company. All
successful software companies had, as their dominant personality, a
leader who nurtured programmers. But no company can keep such a leader
forever. Either he cashes out, or he brings in management types who end
up driving him out, or he changes and becomes a management type himself.
One way or another, marketers get control. But...control of what?
Instead of finding assembly lines of productive workers, they quickly
discover that their product is produced by utterly unpredictable,
uncooperative, disobedient, and worst of all, unattractive people who
resist all attempts at management. Put them on a time clock, dress
them in suits, and they become sullen and start sabotaging the product.
Worst of all, you can sense that they are making fun of you with every
word they say.
SMOKED OUT
The shock is greater for the coder, though. He suddenly finds that
alien creatures control his life. Meetings, Schedules, Reports. And
now someone demands that he PLAN all his programming and then stick to
the plan, never improving, never tweaking, and never, never touching
some other team's code. The lousy young programmer who once worshiped
him is now his tyrannical boss, a position he got because he played
golf with some sphincter in a suit. The hive has been ruined. The best
coders leave. And the marketers, comfortable now because they're
surrounded by power neckties and they have things under control, are
baffled that each new iteration of their software loses market share
as the code bloats and the bugs proliferate. Got to get some better
packaging. Yeah, that's it.
A programmer's ability to focus on a single task for long periods to the exclusion of all else has led some people to comment on similar behavior in autistics (Asperger's Disorder), and to wonder whether most programmers are mildly autistic. I would be surprised if most programmers were autistic--our concentration is too easily broken.
As someone who is a programmer and autistic I felt the need to jump in. I am diagnosed with both Asperger Syndrome and ADD. Although I have many of the classic autistic symptoms (nonverbal language deficits, sensory integration issues, near-photographic memory, obsessive interests, etc.)
My concentration is interesting. While it is normally quite short, I have the ability to hyperfocus for hours on anything I am obsessing on. This is usually code, so that works out just fine, tyvm.
As far as working accomodations, to get what I really needed, I had to jump off the deep end and become self-employed. My home office has extensive soundproofing and other "accoustical management" stuff, most of it was pretty easy/cheap.
For the first time in my life, I have all of the people I need to be in contact with to do mainly via IM. If I'm lucky, one of these days I can cancel my phone, but for now, I will just settle for turning the ringer off (it flashes, too).
Not limited to programmers
by
Selanit
·
· Score: 4, Interesting
It seems to me that the "flow" the article discusses is not limited to programmers or artists; it can happen to anyone who is truly involved in a task that they love, in any area of endeavor.
I code. Admittedly, it's just PHP, a language of limited utility for anything but web-oriented tasks, but nonetheless a real programming language. I have felt that "flow" when working with PHP: you code fast, overcome obstacles fairly quickly, and it all just flies out of your head and into being. Then you blink and realize that it's been 10 hours since you sat down, and you haven't had anything to eat or drink since breakfast. It's glorious.
But PHP is just a hobby. I'm a medieval literature postgrad; I write papers analyzing tales written over a thousand years ago (my specialty is Old English). And I can tell you that when I really get going on a paper, I reach the same mental state as I described above: I sit, I type, and it flows. The thoughts I've been tumbling around coalesce miraculously into a full paper. Sometimes the flow lasts even into the "debug" stage where I have to go through and check to make sure that all of the footnotes are there, and that every comma, semicolon, and punctuation mark is in place, from the first sentence to the end of the bibliography.
For this reason, I believe that "flow" happens to anyone who is capable of becoming absorbed in a task. The type of task is probably important, though. I feel a bit flow-ish writing this post, because the topic is interesting and requires thought. But if you set me out as a lifeguard, say, over a pool full of people, I would never, ever achieve "flow". "Zoned out" maybe, but not "flowing" (which is bad news for the drowning guy in the deep end). On the other hand, repetitive physical labor -- setting bricks, knitting, making chain mail armor -- can be mentally liberating (in proper amounts).
Re:It's not really psychology
by
error0x100
·
· Score: 2, Interesting
I have to add another "me too" agreement here. The thing that annoys me most at my current job is that I am being interrupted very often throughout almost any given day. Sometimes, my interruptions are further interrupted by other people, and those interruptions also get interrupted, with sometimes up to four people on this "stack" of interruptions. I have to handle each one, and still try to remember all the things I *was* doing at the bottom of the stack when I first got interrupted, which itself can occupy several "stack" layers when you're programming. It not only breaks my concentration, which can take very long to get back on track (*easily* an hour, as the article mentions), but I find it also very draining: it seriously tires me out, and also drains my motivation, morale, and kills my job enjoyment. And those interruptions can also very directly be the cause of bugs. Often, at time of interruption, I may already have a 'mental stack' of the five or ten things I need to do next. Occasionally, when interrupted, I will forget one or more of them: I have several times now found bugs months later in code that were caused because I left something half-finished after being interrupted.
Person after person seem to come into my office, and they always seem to claim to have "just a quick question". Some days I think, 'if one more person asks me a "quick question" I'm going to quit'. I can really echo your "leave me the hell alone, dammit!":)
My boss is aware of it though and has been trying to help the situation.
Slashdot Mirror
There are many different types programmers out there with different strengths which are definently related to their personalities. I agree with the article about how creative programmers can enter a state where they can see the problem from a holistic viewpoint and then code just starts to flow from them. I have experienced this state several times, where I space out and my fingers just start bashing away on the keyboard producing code with suprising compiles that first time, bug free, and does exactly what was needed. When this happens, according to what my friends say, I don't respond at all to them, what they say goes in one ear and out the other. This also happens to me when I play my guitar, when I get going on a groove I just zone out until I have finished. When I do get forcefully interupted there is hell to pay, it is extremely annoying to having someone force me out of such states. This state of mind reinforces to notion that creative people make good programmers, possibly better than less-creative people. The odd thing with this is that I did horribly in the non-science courses in school. I got 75% in english while the majority of the class got 85%. But then again I did really try, I never paid any attention really although he was a really good teacher. Another interesting thing is that in a project I was working I never commented any of my 7000 lines of code yet when I came back to the code half a year later, despite from what most people say, I could still clearly remember what each line did. In further explanation of my persona and why it makes me a good programmer is that despite being a complete geek I am also into extreme sports, downhill biking, windsurfing and so on. These are my outlits for taking a break. Is anyone else like this?
Checking out my form of escapism.
I manage a team of programmers in a foreign country and I can tell you, it isn't worth it.
We pay them $10/hour but the work they do normally has to be redone 2 or 3 times before they get it right, and even then, the code is awful: Variable names like x and z, C when they are supposed to be using C++ and lots and lots of access violation errors that destroy all the hard work that I do.
I would rather pay a good programmer $50/hour.
At first I thought, for $10/hour how can you lose? But in retrospect I'd say the problems just about outweigh the benefits.
"When creative people work on making something new, they often enter a mental state where things just flow. This is a highly desirable state, both for the programmer herself and for the organization that profits by her labors."
what's w/ this recent trend towards using feminine pronouns where they're totally inappropriate. I don't think that I've met more than three female programmers in the decade that I've worked in this area. There are a sizeable minority of female sysadmins , but very very very few women programmers. Is cousin fester trying to be PC , or is he just totally oblivious to the fact that for all intents and purposes there are no female programmers.
In general this article is queer , frankly most of what proports to be psychology is bunk. Programmers are actually alot like engineers. I think this guy has a very shallow understanding of what engineers do. Programmers certainly aren't like most of the artists I've met. It's nice that he recognizes that development entails a creative process , but that's only one aspect. The rest is pretty clearly engineering.
Which shows that this guy doesn't know scientists. Scientists - true scientists, not technicians - are very like this guy (correctly) describes programmers. Both programming and scientific research are creative skills which, as the man says, require you to be "in the groove". He is not wrong about programmers - he is wrong about scientists. Techicians, to some extent, have less need to be "in the groove" - though much of what he says applies to any human being, with only the time constants varying.
OTOH. 3. Accommodate Reasonable Special Requests. When I get really stuck on a design problem, I go for a walk in some very beautiful woods about three miles from my office. An hours walk in the woods has about an 80% chance of delivering a solution to the problem. Even, curiously, if I don't spend much time conscioulsy thinking about the problem. In fact, I sometimes feel that by subconscious is telling my conscious to let go that problem and leave it to me. Dropping a problem for an hour or day and then coming back to it can be remarkably constuctive.
In fact, I sometimes feel embarasssed that the conscious "me" claims credit for the bundle of mad scientist, lechers, random thought generators, and idiots who inhabit my subconscious and do all the work.
Consciousness is an illusion caused by an excess of self consciousness.
That is not to say that our education system is evil (well, it is, but that's not the point) or that people today are stupid. The reason for this programmer pluggability is that the market evolved to the point where creativity simply is not neccessary, since most common problems have been solved and codified -- and there is no demand for uncommon tasks.
The only two places right now (IMO) where creativity and real intelligence are needed are the embedded coding and theoretical CS research. Theoretical CS research requires creativity because it's, well, research. Embedded design requires creativity because the resources are so limited, and a pre-designed solution simply will not work in your PIC16 microprocessor with 4Kb of RAM, and so you must be really tricky to make your program fit into the limited space and time constraints.
Outside of these two niches, programming has truly become similar to construction work: a few engineers design the building, and then 100 grunts carry bricks around and hammer nails until it's done.
>|<*:=
I think the article has an interesting perspective, and I totally understand the "in the zone" argument. Sometimes you have it, sometimes you don't, and sometimes an interruption really is just soooo irritating.
However, I'm not sure the suggestions are really the way forward. In particular, such research as I've seen (sorry, can't cite a link off the top of my head) suggested that actually, a small team of programmers was much more productive in their own open-plan-like "team space". There are several logical explanations for this, not least the fact that if you do get stuck with a mental block, help is just a question away. You also get interaction with conversations other members of the team have, and either learn something yourself or offer them a solution neither of them knew about but you did.
Sure, you need to have a team who get on, and realise when someone is really going for it so they don't interrupt at just the wrong moment. But all that really takes is having a little consideration for your team-mates, and a willingness to say "Can I get back to you in half an hour?" without being distracted, neither of which is hard to do. No-one really sits in the zone all day, it's more like a few minutes when the germ of an idea comes to you and you want to flesh it out, and that's the time when it's bad to be interrupted.
Other than that, I find it's much more helpful to have the interaction for the remaining 90% of the day, so you don't get "programmer's block" and just sit there thinking about a problem but not really getting anywhere. I guess this is one of the major advantages of "pair programming", too, if you've got people who are happy working together that closely.
I agree that programmer comforts are generally a smart move: where I work we have a decent flexitime system, concern over things like chairs and lighting, headphones so people can listen to CDs while they work and, yes, even a shower. These are all good things, appreciated by the developers, and so the developer productivity and loyalty is very high. But we still work in an open plan office, even if everyone does have "their space" in it. :-)
If you disagree, post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like.
As a 'Brit' I too find this very odd. Consider this small chunk of text:
If written by someone from the UK (and probably AU or NZ) this would be written like this:
No use of gender, and perfectly correct English too.
Blaming GW Bush for the Iraq war is like blaming Ronald McDonald for the poor quality of food.
I was wondering how much of this 'psychology' is cultural. Do these programmer 'sweat shops' in non US (or non Western) locales suffer the same problems of distraction that as their US counterparts apparently do? I feel I'm lucky that I'm in a situation where distractions are kept to a minimum (well, really it's that I control my distractions myself) but if I were to be thrust into a more distractive environment my creativity would certainly suffer. Does the guy in Elbonia feel the same way, or does he work in an active environment with no loss of creativity.
After 8 years of software testing and QA, here are my experiences of programmers. No it's not flame bait - but mark it down as you wish
1. They do not know the meaning of deadlines! How many times, I've been working late because some dim wit of a developer didn't see the importance of actualy meting the deadline he proposed himself. Working late evenings, working weekends because the programmer didn't see why he should put the extra time in to catch up. Sounds familiar?
2. They do not know the meaning of quality. How many times have I sat there with a program or package from development that simply will not work / start-up / compile. All this despite development's assurances that they do actualy unit test. I once had to test a program that did nothing, ie it was called from another program, but all it should do is close itself down - it was a stub. How difficult is that to program and how difficult is that for the programmer to test themselves? It took SEVEN attempts to get it right!
3. Keep it simple stupid! How many times have I had to sit there wondering if I was looking at the correct Buisness Requirements and Functional Spec. Final designes seem to be as complcated as posible rather than simple. Functionality slippage is common - lets put this bit in as well.
4. Yes, but programmers are artists. Bollocks! If you look at almost any system, you will see that the basic number of functions is very limited. Given any average office system, you could probably find public domain code to do 90% of what you need. Yes it will need changing and tweaking, but this idea that you sit there creating is simply rubbish. Perhaps if you stopped creating and started engineering things would be better.
5. The Prima Donna syndrome. Programming used to be a black art. Well it isn't any more. However, some developers seem to think they should still be treated differently as this article demonstrates. If any other professional argued that they needed a kip durring the day, they would probably be booted out. You want a kip, have it at lunch time! Not having a much time at lunch - welcome to the real world.
I know this is going to be marked down as flame bate, but it has to be said it is about time that programmers came back into the real world. With comments like If a programmer's flow is interrupted it can take a large amount of time for her to regain the state, sometimes up to an hour. do you realy wonder why people question programmers professionalism? Everyone else has to work hard for a living, and creativity comes into most jobs, but most just get on with it.
I've got to say that article was quite the ego booster.
First, programming is most definitely an art as it is a blending of layout, design, creativity, and tasteful hacking to derive a solution.
The section about programmer's concentration was interesting, and I definitely fall into that category. It is nothing for me to sit down to go through the process of designing, coding, debugging, and repeat for 8 hours, without realize it at all. It only speaks of my passion for my work, and my enjoyment in solving challenging problems.
Poster here who have noted about treating programmers more like people than equipment hit the nail right on the head. In my school, our proffessors warn us to avoid jobs that look as though the employers treat programmers as "code monkeys" (if you sat enough monkeys at computers typing C, how long would it take until you get MS Office?). At some of my best internships, and the job I have gone back full-time to, my section leader encourages his team to take regular breaks (which often involve heading back to an ongoing game of RISK), schedules frequent offsites/classes/excursions to get us out of the cubicles, and overall creates one of the healthiest work environments I've ever been in.
All that said, I shouldn't be to programmer biased. Not all programmers are great programmers who have mastered that mystical "flow". I could see a manager reading this article, trying all these things, and getting really burnt.
It's all a game of balance that definitely begins with treating employees like people, not equipment.
Painting is an art. Playing a musical instrument is an art. Programming, like everything else explicitly constructed by man, has distinct rules to it that allow one to do well, and can be objectively deconstructed to what makes it good or bad. Calling programming an "art" is just self-congratulatory tripe that people spew to fool themselves into thinking that they have a human side.
--sdem
Yeah I work that way as well - I need to explain the problem to someone else sometimes before I come up with the solution.
A good manager of programmers treats the coders as professionals. If someone wants to lock themselves in a silent room, go for it. If someone wants to do pair programming outside on the front lawn of the building, go for that too.
My best projects have come out when doing team programming, we'd sit next to eachother and talk back and forth about the problem.
The best way to manage this is by good office design. Having centralized offices, but with a shared space in the middle with cubes, really helps. The people who want silence can close their doors, the Pair Programmers can plop down in the cubes with their coworkers and go at it.
You know it has to be said that programming, really good programming, comes about through a passion and enjoyment of your work. Achieving goals, pushing the envelope, competing with other programmers, learning new tech - its all exciting stuff. But pay me $4 a day working on some brain number of a project I dont give a shit about and you know what kind of code you're going to get back? Crap.
I've had jobs as a "web developer" where idiot VB coders would frown on me, giving me the script kiddy jibes (which is fresh considering the use VB). It amuses me however, I got into web design to learn new tech like XML and web services. I used to write games, I've hacked ASM on a variety of processors- was using C back on the Amiga. But anyway I digress- that environment did nothing for me, the management sucked, the didnt understand creativity (I could stare at a screen for hours putting connections together in my head) but if code wasnt being written I was a slacker. Shame really, I left to go it alone.
If they bothered to pay attention to my previous employer where I got soooo wrapped in my own AI app that I would work 24hrs at a pop they would see what a resource they lost.
Programmers are different. They are not productio line workers churning out pre-formed shit. They love what they do, care about it (I love prettifying my code as I near completion), each app for me at least is a work of art and no-matter how these foreign programmers are touted as being hot shit, I just know they wont care as much as I do, and the results will reflect that.
Sorry for the rant- people will come around eventually. You want great software? Pay the price, this isnt factory work.
Under a very tight deadline, I once told a manager quite forcefully:
"Look, each of us has an obligation to the other here. Your obligation is to do everything you reasonably can to empower me and enable me to meet the deadline. My obligation is to do everything that I reasonably can to meet my commitment on this deadline and to inform you when there are things that you can do to improve my chances. Therefore, as part of my obligation, I have to inform you that by constantly interrupting me to ask me how it's going, you are breaking the concentration that I have spent several hours building and reducing my chances of meeting the deadline in the order of 2 or more hours* per interruption."**
He looked quite shocked at first but then seemed to summon his memories of his days in the trenches, apologized and backed off. We had a new understanding from that point on.
----
* 1/2 hour to cool off + 1 hour to re-build my mental state + 1/2 hour fudge ('cause we always gotta fudge ;)
**(This is what I said IIRC. It was some years ago and legends tend acquire new dimensions over time. It's also possible that I said something more concise like "quit f---ing bugging me, so I can get this done". I can't remember exactly now.)
Sigs are bad for your health.
I don't know if I can agree with the statement anymore that programming is an art form instead of a science. I certainly recognized the creative component when I was programming, and at that time there not much engineering discipline applied.
In the last ten years there has been a lot of movement to add discipline to the software engineering process. The Software Engineering Institute/Capability Maturity Model (SEI/CMM) may be the chief among these, as its creation was originally sponsored by the US Department of Defense. This model does take a lot of the fun out of programming, but it does provide the business benefits of a disciplined approach, which is chiefly a reduction in defects.
I think there is a mechanism in physical engineering that does not carry across well into software engineering organizations that follow SEI/CMM or other programming methodologies. In building construction you have the architect who applies both functional as well as creative/artistic qualities to the work. Then you have the (civil or other ) engineers that apply more of their discipline to make sure that the building works and does not fall down and meets other requirements. This is oversimplified as there is a necessity for creativity at all points of constructions, but I don't think this analogy carries well to software organizations. Maybe it does in web development groups, but those are outside my area of experience.
Use your head, can't you, use your head,
You're on earth, there's no cure for that - S. Beckett
Sometimes it is good for a programmer to be interrupted.
Some author - maybe it was Hemingway - said that when he was done writing for the day, he'd always stop while he was still "into" it. This gave him something to look forward to the next day. It gave him a place to start.
I think a similar technique is useful for programmers. For example, say you are writing a really fun function but only have 10 minutes of work left. I say, stop writing! Spend the rest of your time on the net reading some tech articles, or improve your code's documentation (if you think documentation is boring, maybe you aren't doing it right. When you document, pretend your talking to another programmer about your program).
When you come in the next morning, you'll have an easy way to start the flow again. You won't be hacking around trying to figure out what to do next.
Malachi
http://www.google.com/profiles/malachid
I hated being in the building, not wanting to hear who was porking whom from a three cubes down(you know who you are, Bitch!)or the personal problems of a bunch people who hated management, hated the products they were working on, and hated life in general.
Once I got my office, or more importantly, ONCE I GOT MY OFFICE DOOR, I could shutout the bullshit, crank up the tunes, and get down to business. Microsoft lets you decorate your office however you want, so over time my office became my favorite place to be. People joke about how people at Microsoft would rather send email to someone in the office next door, rather than get up and ask a question face to face, but nobody likes to be interrupted from a programming train of thought.
I would never, EVER again work as a programmer, if it meant going back to a cubicle. In a cube, you are nothing but a faceless, nameless pod person, waiting to be replaced by some other pod who wants to work for less than you do.
What we have here is a classic case of "telling programmers what they want to hear". I wonder if this guy is selling something?
--sdem
Music (not so good to makes one want to hear the music instead of working, neither something so bad that breaks concentration)
In Peopleware DeMarco and Lister writes about a series of test at Cornell on the effects of working with music in the 1960s:
The result was that groups with and without music performed about the same in speed and accuracy of programming.
However, the output data was to be manipulated about a dozen times. The net effect of the operations left output number equal to its input number.
The overwhelming majority of people who figured it out came from the group working without music.
If the right brain is busy listening to music the opportunity for a crative leap is lost.
So if programming is a crative art do not listen to music.
It doesn't matter how much 'wonderful' code you were producing. If you weren't there at the same time as the other people working on your team and/or the people who define the requirements, you weren't working cooperatively. You can spin algorhythms into the night to scratch your own itch. That isn't what you're paid for.
I had a problem with my management along those lines. I started getting up and making a tally mark on the whiteboard in my cubicle every time I got interrupted. About the fourth time my manager came in and saw me do that, he asked me what the marks were for, and I explained to him that he could multiply the number of marks by 15 to get the amount of productive time I lost due to interruptions since I arrived at work that morning. Turned out that the number was roughly equal to the time I had been at work that day. I had a copy of "Flow" with me, and I loaned it to him.
He actually got the message. Not only did he quit bugging me, but he actually started running interference for me. Unfortunately, I haven't had many managers who were that bright.
Concealed Handgun License Courses in Plano, Texas
It's sort of puzzling that many of us can understand the interruption problem, but many who are our MANAGERS do not. A (part time) professor at college told me about how he was a manager and how the place he worked for endlessly harassed the programmers. Eventually he set up a system so that you had to go through a secretary and then it was determined if it was absolutely critical, otherwise you just got dumped to a voice mail box. It sounded like a good idea to me, and now that I work for a place that interrupts me every 10 minutes for a "just reboot your computer" answer, I appreciate it a lot more.
Software - How Software Companies Die
By: Orson Scott Card
The environment that nutures creative programmers kills management and marketing types - and vice versa. Programming is the Great Game. It consumes you, body and soul. When you're caught up in it, nothing else matters. When you emerge into daylight, you might well discover that you're a hundred pounds overweight, your underwear is older than the average first grader, and judging from the number of pizza boxes lying around, it must be spring already. But you don't care, because your program runs, and the code is fast and clever and tight. You won. You're aware that some people think you're a nerd. So what? They're not players. They've never jousted with Windows or gone hand to hand with DOS. To them C++ is a decent grade, almost a B - not a language. They barely exist. Like soldiers or artists, you don't care about the opinions of civilians. You're building something intricate and fine. They'll never understand it.
BEEKEEPING
Here's the secret that every successful software company is based on: You can domesticate programmers the way beekeepers tame bees. You can't exactly communicate with them, but you can get them to swarm in one place and when they're not looking, you can carry off the honey. You keep these bees from stinging by paying them money. More money than they know what to do with. But that's less than you might think. You see, all these programmers keep hearing their parents' voices in their heads saying "When are you going to join the real world?" All you have to pay them is enough money that they can answer (also in their heads) "Geez, Dad, I'm making more than you." On average, this is cheap. And you get them to stay in the hive by giving them other coders to swarm with. The only person whose praise matters is another programmer. Less-talented programmers will idolize them; evenly matched ones will challenge and goad one another; and if you want to get a good swarm, you make sure that you have at least one certified genius coder that they can all look up to, even if he glances at other people's code only long enough to sneer at it. He's a Player, thinks the junior programmer. He looked at my code. That is enough. If a software company provides such a hive, the coders will give up sleep, love, health, and clean laundry, while the company keeps the bulk of the money.
OUT OF CONTROL
Here's the problem that ends up killing company after company. All successful software companies had, as their dominant personality, a leader who nurtured programmers. But no company can keep such a leader forever. Either he cashes out, or he brings in management types who end up driving him out, or he changes and becomes a management type himself. One way or another, marketers get control. But...control of what? Instead of finding assembly lines of productive workers, they quickly discover that their product is produced by utterly unpredictable, uncooperative, disobedient, and worst of all, unattractive people who resist all attempts at management. Put them on a time clock, dress them in suits, and they become sullen and start sabotaging the product. Worst of all, you can sense that they are making fun of you with every word they say.
SMOKED OUT
The shock is greater for the coder, though. He suddenly finds that alien creatures control his life. Meetings, Schedules, Reports. And now someone demands that he PLAN all his programming and then stick to the plan, never improving, never tweaking, and never, never touching some other team's code. The lousy young programmer who once worshiped him is now his tyrannical boss, a position he got because he played golf with some sphincter in a suit. The hive has been ruined. The best coders leave. And the marketers, comfortable now because they're surrounded by power neckties and they have things under control, are baffled that each new iteration of their software loses market share as the code bloats and the bugs proliferate. Got to get some better packaging. Yeah, that's it.
-
A programmer's ability to focus on a single task for long periods to the exclusion of all else has led some people to comment on similar behavior in autistics (Asperger's Disorder), and to wonder whether most programmers are mildly autistic. I would be surprised if most programmers were autistic--our concentration is too easily broken.
As someone who is a programmer and autistic I felt the need to jump in. I am diagnosed with both Asperger Syndrome and ADD. Although I have many of the classic autistic symptoms (nonverbal language deficits, sensory integration issues, near-photographic memory, obsessive interests, etc.)My concentration is interesting. While it is normally quite short, I have the ability to hyperfocus for hours on anything I am obsessing on. This is usually code, so that works out just fine, tyvm.
As far as working accomodations, to get what I really needed, I had to jump off the deep end and become self-employed. My home office has extensive soundproofing and other "accoustical management" stuff, most of it was pretty easy/cheap.
For the first time in my life, I have all of the people I need to be in contact with to do mainly via IM. If I'm lucky, one of these days I can cancel my phone, but for now, I will just settle for turning the ringer off (it flashes, too).
It seems to me that the "flow" the article discusses is not limited to programmers or artists; it can happen to anyone who is truly involved in a task that they love, in any area of endeavor.
I code. Admittedly, it's just PHP, a language of limited utility for anything but web-oriented tasks, but nonetheless a real programming language. I have felt that "flow" when working with PHP: you code fast, overcome obstacles fairly quickly, and it all just flies out of your head and into being. Then you blink and realize that it's been 10 hours since you sat down, and you haven't had anything to eat or drink since breakfast. It's glorious.
But PHP is just a hobby. I'm a medieval literature postgrad; I write papers analyzing tales written over a thousand years ago (my specialty is Old English). And I can tell you that when I really get going on a paper, I reach the same mental state as I described above: I sit, I type, and it flows. The thoughts I've been tumbling around coalesce miraculously into a full paper. Sometimes the flow lasts even into the "debug" stage where I have to go through and check to make sure that all of the footnotes are there, and that every comma, semicolon, and punctuation mark is in place, from the first sentence to the end of the bibliography.
For this reason, I believe that "flow" happens to anyone who is capable of becoming absorbed in a task. The type of task is probably important, though. I feel a bit flow-ish writing this post, because the topic is interesting and requires thought. But if you set me out as a lifeguard, say, over a pool full of people, I would never, ever achieve "flow". "Zoned out" maybe, but not "flowing" (which is bad news for the drowning guy in the deep end). On the other hand, repetitive physical labor -- setting bricks, knitting, making chain mail armor -- can be mentally liberating (in proper amounts).
I have to add another "me too" agreement here. The thing that annoys me most at my current job is that I am being interrupted very often throughout almost any given day. Sometimes, my interruptions are further interrupted by other people, and those interruptions also get interrupted, with sometimes up to four people on this "stack" of interruptions. I have to handle each one, and still try to remember all the things I *was* doing at the bottom of the stack when I first got interrupted, which itself can occupy several "stack" layers when you're programming. It not only breaks my concentration, which can take very long to get back on track (*easily* an hour, as the article mentions), but I find it also very draining: it seriously tires me out, and also drains my motivation, morale, and kills my job enjoyment. And those interruptions can also very directly be the cause of bugs. Often, at time of interruption, I may already have a 'mental stack' of the five or ten things I need to do next. Occasionally, when interrupted, I will forget one or more of them: I have several times now found bugs months later in code that were caused because I left something half-finished after being interrupted.
Person after person seem to come into my office, and they always seem to claim to have "just a quick question". Some days I think, 'if one more person asks me a "quick question" I'm going to quit'. I can really echo your "leave me the hell alone, dammit!" :)
My boss is aware of it though and has been trying to help the situation.