Psychology of a Programmer

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."

Comments

It's not really psychology

[xintegerx]

There is no psychology really involved... Just treat the programmers as the professionals they are. Treat them like people.

Re:It's not really psychology

[Orthanc_duo]

I think the big point is that programming is an art. Every programmer I know knows this on som elevel but lay people generally do not. I'm lucky in that my boss is a programmer

Re:It's not really psychology

[SpaceLifeForm]

It's not that simple. Just treating them like people is part of the problem. Most people can deal with interruptions because they don't stay on the same train of thought for very long. Non-programmer types when they interrupt a programmer *never* for a second believe they are really causing a problem. But, IMNSHO, those interruptions are real thought-killers.

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?'

Re:It's not really psychology

[WindBourne]

I use to code all night long but dealt with to many morons at the office bitching about my never being there. So now I am there and productivy is at about 1/4 of what it was. But hey, they can see that I am there.

Re:It's not really psychology

[wideBlueSkies]

From personal experience I have to agree with this. In the morning when I come in it takes a good 10 minutes for me to settle down and start to think 'in code'. Once the train starts rolling though, the ideas (usually) just flow down to the keyboard.

If I'm interrupted, it's like the train fell off a cliff.

So then I have to focus on whatever interrupted me, while trying desperately to cling on to those ideas that didn't make it down to the keyboard before I was interrupted. Because now i'm having to think in 'real world'.

If I'm interrupted to help another developer debug something, or brainstorm a problem (which I enjoy immensly) It's harder because I have to switch over to their programming mode, and try to understand what they're doing.

So then when I can finally get back to the joy that is programming, it takes another 10 minutes or so for me to get back to where I was.

I know it sounds like a buch of BS, but it's true. If people keep bugging me, I can lose an hour (or more) in startup time every day. It's not that I'm not working, it's that I'm not working at peak.

So leave me the hell alone! Dammit! ;)

Re:It's not really psychology

[arvindn]

Dead right. Often when I'm coding (mostly at home, being still a student) someone interrupts me with a question. I look at their face and stare blankly for a full 10 seconds. That's how long it takes me to get off my train of thought. And they often think I'm doing it on purpose, to irritate them :(

Re:It's not really psychology

[DuctTape]

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?'

Reminds me of one time I was a project manager "under the gun" for a past-due project deadline, and my manager and his boss and various other PHBs would come around at nondeterministic intervals to ask what the status was (essentially it was done as soon as the developers had a V-8 moment), so as an experiment, and a total waste of time on my part but the developers understood what was going on and that I was being a very effective filter between them and the PHBs, I would continuously round-robin visit the developers getting continuous status updates, and at the end of each cycle, I would pop my head into the PHBs' offices and let them know what was going on. This kept me from getting interrupted at random moments, and the guys kinda figured out when to expect me, and could give one-syllable grunts to convey status with minimal context switch.

I think my approval rating went up that period. Of course, I never did it again.

Perhaps we need an article about the psychology of PHBs. Or project managers. Still can't believe I did it....

DT

Re:It's not really psychology

[Snork Asaurus]

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.)

Re:It's not really psychology

[WindBourne]

Actually, we techs were getting it all done and communicating just fine. We were the "requirement gathers". The problem was managers who had to see bodies. And yes, as a software engineer, I am paid to get the job done. Not to simply serve as somebodies' viewing entertainment. That is the difference between MIS and CS.

Re:It's not really psychology

[JaredOfEuropa]

You are absolutely right. But for non-programmers it is hard to believe, especially for managers! A project manager's job often is basically going from one small task to the next, from having to revise the planning to answering queries from accounting about a misplaced comma, to consoling a team member whose cat just passed away. Their job consists of little 'regular' or scheduled work, instead it is like one long stream of interruptions and crises. No wonder managers cannot understand the way a programmer likes to work; they thrive on these interruptions.

Nothing wrong with that. But this mode of working is completely the opposite of the programmer's. I had the opportunity once to combine the job of programmer and project manager. It was a nightmare and needless to say I got little programming work done, but from the viewpoints of both programmer and manager, it was educational to be in that position.

Re:It's not really psychology

[wideBlueSkies]

>>Gee, now I feel bad being the co-op student who needs advice a couple times a day. I at least try to bug different people each time! :-)

No No, please don't feel bad. Teaching is part of the job. At least I think so. And I try extra hard to not appear distrurbed when a junior guy comes with questions.

I remember very well what it was like to ask people for help. Hell, I still have to sometimes.

If you find that someone that you're looking to for help is making it obvious that he's being 'bothered' then he's probably just a selfish person who's forgotten what it was like when he was new.

Hopefully when you become a senior person you'll remembr what it felt like to be new, and you'll try to pass kindness and understanding down to your junior guys.

Good luck to you.

Re:It's not really psychology

[Bald Wookie]

So then I have to focus on whatever interrupted me, while trying desperately to cling on to those ideas that didn't make it down to the keyboard before I was interrupted.

Sounds like you need to disable write caching.

Please forward to our foreign compatriots...

[rand.srand()]

Well intentioned, but the reality is programmers are being wholesale replaced with foriegn labor. Businesses, especially non-IT ones, want nothing to programming or hiring programmers. Much less cater to them in any way above other employees.

A shower?? There's a guy in the Republic of Elbonia who's willing to work out of his hovel on a old 386 for $4 a day programming. He doesn't demand breaks, and there's no coffee machine to stock. And he's viewed as a nearly identical resource. Now is not the time to demand high priced add-ons. But... if we could just get the people of Elbonia to buy into this and equalize the market...

Re:Please forward to our foreign compatriots...

[sane?]

Stop bitching about it and start profitting.

Option 1: Overseas programmers produce poor code with lots of errors.

Answer: Get a group of you together and setup a company offering to rescue faulty developments and fix bad overseas code on a high speed/high fee basis. Invest in tools that help you to do this, or write your own.

Option 2: Actually, they can program quite well - well enough that they are more cost efficient than you will ever be.

Answer: Setup a company sketching out the design of the software, and outsourcing the work yourselves to India. Sell it a as risk reduction exercise.

Option 3: They program well, but you don't fancy option 2.

Answer: Create code and programs that enable you to program cost effectively in relation to Indian programmers, even in only specific niches.

In short, the global marketplace isn't going away. If you want to survive doing what you're doing at the moment, you are going to have to raise your game to compete.

Times of change bring opportunties, grab them. When you do, and you control your destiny - you can have whatever setup you require.

Other ideas

[gmuslera]

• Not fixed working hours
• 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)

...her?

[Anonymous Coward]

Why do people insist on using 'her' instead of 'his' for the generic pronoun? It isn't 'sensitive', it's illiterate. Using female pronouns is even somewhat insensitive: it implies women need to be compensated for, and gratuitously inserts a gender issue into one's writing.

Re:...her?

[phaze3000]

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.

Re:...her?

[HungWeiLo]

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.

This is grammatically incorrect. You are talking about a singular programmer, hence "himself/herself" and "his/her" labors. You would need to use "both for the programmers themselves..."

(Ducks flying rotten tomato)

Re:...her?

[Trisha-Beth]

Why do people insist on using 'her' instead of 'his' for the generic pronoun?

Because they're writing about me.

I guess a male author planning this kind of article would prefer to imagine the situation involving female (in this case programmers) rather than males, unless they're gay or something.

Why do you think the shower was so important to the computer researcher mentioned in the article?

He doesn't understand Scientists

[AlecC]

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.

No longer true

[Bugmaster]

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

[Dixie_Flatline]

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.

Interesting but wrong?

[Anonymous Brave Guy]

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. :-)

Nonsense

[sql*kitten]

I only skimmed the article, but it looked like more self-indulgent "programmers are special" whining.

programmers usually do have a longer attention span and a greater ability to concentrate than the majority of the population

Anyone who has a degree has a longer attention span and greater ability to concentrate than the majority of the population. There is nothing here that makes programmers special.

Writing code is an act of creativity. It isn't science and it isn't engineering, although programmers are happy to apply science and engineering to the creative process, when possible.

This is just nonsense. Why can't engineering - the design of a new product - be creative? Why can't science - the discovery of new knowledge - be creative?

The vast majority of programming in the world is not creative. It's a skilled craft, sure, but it's not about creativity - that is, making something exist that did not exist before. One database application, or web site, or GUI etc is really much like another. The details differ, but it is not pushing the envelope of the possible, like scientists and engineers do every day.

Professor Mihaly Csikszentmihalyi of Chicago University, formerly the chair of the psychology department, has studied hundreds of exceptional individuals, from IT entrepreneurs to Nobel Prize winners, researching creativity. He has written many books and papers on the subjects of flow and creativity

An entrepreneur has a wholly different perspective than a programmer. There may be some overlap between the two groups, but they aren't directly comparable. An entrepreneur will spend most of their time on tasks other than programming, for a start, such as raising funding, making sales, hiring employees, managing existing staff, scouting out the next office, a million other things. But the article is all about how programmers can only do one thing at a time.

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.

This is just mystical hand-waving. I half expected the next paragraph to be about "using the force".

you should isolate the programmer in his or her own room.

why not give each programmer a budget with which they can buy their own chair and desk?

This is just more "programmers are special and should get special privileges". Programmers are no different from any other skilled craftsmen or any other office workers.

I don't give a fig if this costs you more money; the potential benefits are huge. If you continue to view the world as a risk/value proposition then you'll continue to produce mediocre results.

Any sane business manager weighs up risks and rewards. The suggestions in this article aren't about productivity, they're about luxury. Work is work - many people forgot that in the 90's when an office was more like a kindergarten, and look where that got us - many of those people are unemployed now. It's time to grow up and start behaving like all the professionals in the world.

*Yawn* nothing new here

[IIRCAFAIKIANAL]

(I drafted a rant, re-read the article, and re-wrote my rant. It's not so harsh now :)

Programmers should be treated like professionals. Just like every other professional. What a revolutionary concept.

However:

A secretary is being creative when s/he drafts a letter to send to a client on behalf of the resident phb. Does s/he get a shower in his/her office? How about the sysadmin that creatively comes up with a method to speed up deployments? And the engineer that shaves 10% off the time to manufacture your widgets?

Just because your job involves being creative does not mean that you deserve special consideration. Adequate tools, training, and respect, yes. But everyone needs those to perform their "best."

Therefore, this article is bullshit. All creative people can perform better if you enhance their working conditions. All *people* can perform better if you enhance their working conditions.

What a waste of electrons.

(Yes, this is 90% nicer than my previous rant :)

The problem with exporting work

[Anonymous Brave Guy]

The problem with this whole "exporting work" argument is that, the vast majority of the time, the foreign workers simply aren't as good at it, or even close. I'm sorry, I'm no racist, but this is simply the way things are.

It's true of call centres, where people reading from a script with no concept of the product and English as a second or third language just don't project a good impression or offer much help. If you doubt this, ask Carly about how HP did when they moved much of their call centre work abroad.

It's also true of programmers. If someone in India can do the same job as me, for 1/10 of the price but just as well, then apparently at least one of us has got our expectations wrong. OTOH, if a programmer in India has the same job title as me, charges 1/10 of the price but does 1/20 of the work, is this an improvement? Of course not. And I think it's fair to say, quite objectively, that the vast majority of foreign developers lack the education, industrial experience and professionalism exhibited by decent programmers in places like the US or UK.

In the long run, companies will have to adapt to this. They will either recognise that the cheap option doesn't stay cheap when your quality, and consequently your business, suffers, or they will see the need to invest in proper training and support of the foreign labour to raise standards, which will cost them more. Either way, you do get what you pay for. It's just a matter of time until corporate greed starts losing to smart management on this one.

My experiences of programmers

[Anonymous Coward]

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.

Re:My experiences of programmers

[Garg]

1. Every place I've ever been, the programmers work more hours than anybody, with the possible exception of harried middle-managers. They certainly are there more than the QA people. Deadlines are only ignored if they are arbitrary or unreasonable.

2. This is either because of unreasonable deadlines, or you work at Microsoft. Maybe both.

3. Keeping it simple is good, unless you sacrifice quality, or scalability. Maybe the programmer knows something you don't?

4. If you're adding fields to a payroll program, you don't need to be creative. If you're designing a system unlike anything else in your organization, you do.

5. Anything can be abused, and will be.

In short, you could've learned something from this article, but you chose to use it to fuel your own personal vendetta instead. Hopefully you never go into management, unless it's for one of our competitors.

Garg

Re:My experiences of programmers

[axxackall]

1. Working extra hours doesn't help programmers to understand the deadline. The irony is that none, besides the programmer, can tell that precisely how much it will take. Other people give even more arbitrary answers. And the extimation by the programmer oneself never includes post-coding cycles (like bug-fixing), which is unavoidable, and thus it must be corrected by the project manager.

2. I wuould say, this is b/c of poor quality of requirements and other specs - the concept of quality and scalability of the product should never be created by the programmer, instead it should be very explicitely clarified begining from requirement gathering (marketing), then analyzed (product managemers and architecturs), then specified (software architector), including all possible unit and otther tests. The programmer should just continue processing of requirements for quality of the product to the quality itself (before QA, sales and support will finish it). If this chain is broken or missed then the product is not supposed to make any money. Only Microsoft can let the product be designed without requiretns for quality (they compensate it politically). others will go out of business.

3. Keeping specs being simple doesn't sacrifice (including scalability) the quality of the product by itself. But the way how such requirements for quality are expressed (gathered, analyzed, designed and specified) must be as simple as possible (but not simpler - see Albert Einstein). It is true that often a good UML diagram explains better than the text of the same paper size. But if the case is not typical (not from UML/RUP books) then it's more likely you'll spend more words to explain your non-typical diagram (what does it display and why it is important for this project) than you'll do it without a diagram just on plain English from the first place.

4. If you are adding a summary filed from another subgroup (perhaps from bellow) to a regular record line in the report (for some sort of comparison) - then you have to redesign the architecture of your report by either making it two-cycle calculated, or using some temporary table (bad DB idea). So, you are creative at that time. But I prefer to thing about it as about engineering creativity. BTW, trying to reuse any code (as a source code!) from virtually any open source project has more art than writing a poetry and if you disagree than perhaps you've never tried it by yourself.

5. I've never seen in my life sleeping programmer aside from extreme situations of several shift straight forward. What programmer are typically want is arbitrary time to come and to leave the office. Same as many other people do. Some companies refuse it and play the game "we are in army", anothers let it go but more intensively rotate (fire and hire) persons with low evaluation points.

Re:Interest

[Troed]

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.

You're probably a good coder - but you're a lousy Software Engineer. As someone else has already pointed out - comments are not for YOU.

Well written code is code that someone else can start working with without having to ask the previous developer any questions.

Tom Gilb writes books. Read them :)

I felt like I just visited a shrink

[wordisms]

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

[renehollan]

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.

Psuedoscience

[wizzums]

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.

I particularly like how this fellow uses Autism as a reason, then clarifies it by noting a single branch of the entire syndrome as if that's what it's *really* called, and finishes up his great assumption by explaining that autistics must have high concentration levels.

While they're in the same psychological realm, he's trying to refer to ADD.. not Autism.

From ADD.org
"You get one idea and you have to act on it, and then, what do you know, but you've got another idea before you've finished up with the first one, and so you go for that one, but of course a third idea intercepts the second, and you just have to follow that one, and pretty soon people are calling you disorganized and impulsive and all sorts of impolite words that miss the point completely."

Autism on the other hand is the complete inability to concentrate on ANY task for short periods of time. Autism is associated with Stims, self stimulatory behaviour. Asperger's Syndrome is a "mild" form of Autism that tends to affect mostly boys. Note that there is still a lack of common sense associated with this. Simply being quirky is not Asperger's.

A child with ADD is more than likely able to understand you when you tell him to "sit still, eat your dinner," while a child with Autism might just flick his fork around continuously while he's eating.

Credibility: I work with Autistic children, and ironically, have been diagnosed with ADD.

Managers either get it or don't - and won't cange

[hillct]

I've worked for a fariety of managers over the past few years and I've found that they either understand programmers, or don't. They can either acomodate the quirks or can't and that's it. This or any article stands no chance of changing their outlook.

One issue the article fails to mention is that you can in fact divide one programmer between development and support roles. The article says don't intersperse these roles durring the work day, but I've found in my own work, - which requires both activities - that the manager simply has to allow the programmers to do his own time alocation, for example, I find that I can get into the work day completing a series of support tasks, in the morning when I'm relitively stress-free, then in the afternoon, turn my focus to one of the never ending pile of development projects on my desk.

Having said this, I have to agree with the author that interspersing these tasks such that every 45 minutes the programmer has to stop developing and change his mindset to support a user, hten shift back into development mode is inherently bad.

The point is, programmers - being artistic as they are - are reasonably flexible. It's just important not to expect unreasonable flexibility, as this would prevent achieving the nessecery level of focus on each of the tasks at hand.

--CTH

Psychology of a company

[Musashi Miyamoto]

What they really need is a "Psychology of a Company" or "Psychology of working for someone else" for programmers to read.

Too many programmers are Asperger-syndrome types that have difficulty with social skills and with understanding that THEY work for SOMEONE ELSE. They are not the boss, and therefore, just because they think something should happen a certain way, doesnt mean all other ideas are wrong.

There is a severe problem with tech workers in this respect. Too many think that they are driving and refuse to take direction. Too bad if something like this were written, most of them would not read it, and if they did, they would discount and ignore it.

Re:Pfft.

[mrkh]

I've no idea how this happened, but somewhere along the line we let ourselves be talked into the idea that creativity is present in artists, musicians, and architects, but not programmers, box packers, or soccer players. Creativity is a basic human ability.

Computers can't paint. They can't write computer programs either. It's not some crude mechanistic process that we can automate ; there is a need for style and creativity. Which to me, makes it an art.

(Surely painting and music are 'explicitly constructed by man', and each of these have distinct rules that allow one to do it well too?)

So.

[I Am The Owl]

What we have here is a classic case of "telling programmers what they want to hear". I wonder if this guy is selling something?

Peopleware on Music and Programming

[prankster]

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.

Dealing with interruptions

[hlh_nospam]

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.

You're missing the point

[sjames]

This isn't about special consideration because programmers are 'special people' who deserve it, it's about maximising productivity and morale at the same time without having to spend much money in the process because that's good for the company.

A secretary who is drafting a letter is an administrative assistant, and SHOULD be able to draft a letter in peace. Otherwise, it's just another case of damaging productivity by failing to think. The Engineer who shaves 10% off the manufacturing time probably was able to do it by having the same conditions that the article recommends for programmers.

There are a number of jobs that call for that sort of thing to some degree or another, and for varying percentages of the day.

To use your example, it is doubtful that the latter being drafted will run 100,000 lines long, take 3 months of highly professional manhours to produce, and remain 'in production' for the next 3 years (complete with a single typo/thinko costing thousands of hours in excess support manhours

So, though the secretary should be able to finish the letter uninterrupted for maximum efficiency, the time period is shorter, and the complexity of the mental map that will get swapped out if an interruption DOES happen is a lot smaller.

Yes, all people can perform better if you enhance their working conditions. Different professions have different sets of needs for their ideal working conditions. The article was a few pointers to managers about what they should do for programmers. What to do for administrative assistants, lawyers, cooks, and mechanics are all worth knowing to someone who manages those professions, and should be covered by similar articles.

Software bees

[UncleSocks]

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.

Not limited to programmers

[Selanit]

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).