The mind is sharper and keener in seclusion and uninterrupted solitude. No big laboratory is needed in which to think. Originality thrives in seclusion free of outside influences beating upon us to cripple the creative mind. Be alone, that is the secret of invention; be alone, that is when ideas are born. That is why many of the earthly miracles have had their genesis in humble surroundings.
These are the voices which we hear in solitude, but they grow faint and inaudible as we enter into the world. Society everywhere is in conspiracy against the manhood of every one of its members.
I shun father and mother and wife and brother, when my genius calls me. I would write on the lintels of the door-post, Whim. I hope it is somewhat better than whim at last, but we cannot spend the day in explanation. Expect me not to show cause why I seek or why I exclude company.
The book "Peopleware" has documented this very concept decades ago (according to wikipedia, first edition was published in 1987), yet here we are in 2012 with still more "cool open" environments for programming teams.
Lots of startups want to recreate the cafe experience as a workspace, but I'd rather work in a real cafe, with more people and more noise than an open space office. In a cafe, you still have somewhat of an expectation of privacy, there's less the prospect of someone interrupting you just because you're within reach.
A huge difference at a cafe (or library, or beach villa patio ...) is that the people around you don't have any say in your activity. Other than, perhaps, the cafe manager who could kick you out for hogging the table.
But, generally, the people there are strangers (or casual aquaintences), not workplace bosses, subordinates, rivals, or even true collaborators. So what they do has a lot less influence on you than would be the case at an office (or a home environment for those who work at home with roommates or family).
Not only does this reduce interruptions (other than someone with low social awareness or boundaries, you're not likely to get interrupted), but the conversations and activities at other tables don't concern you. While you might casually observe or evesdrop as a diversion, you've got no stake in the outcome of a given conversation or interaction.
Similarly, you can flirt with the boy or girl at the next table without worrying about it turning into an HR issue.
This is much less the case in an office. Particularly one with any sort of disfunctional relationships.
Online collaborative projects (including Free Software projects) typically operate similarly. People participate because they're interested and are capable. You can't be fire (OTOH: you're often not being paid), but in a sense this is a good thing as it disintermediates work and work product from concerns over how that product is received.
My current company, a startup, has an even split of developers, half under 30 and half over 45. I'm one of the old guys. The development environment and approach, mostly set up by the young guys, is pretty modern -- lots of open source tools, hosting on launchpad, test-driven development, code reviews, all developers in one big open space, everyone does everything (as opposed to developers doing development, testers writing tests, build engineers creating build infrastructure).
The young guys seem to thrive in this setup. It's driving me nuts.
I am most productive when I have a problem to solve and I can immerse myself in it for hours every day, days at a time, without interruption. But now I have to do timely code reviews for others. I also have to respond to reviews of my code. The encouraged way of working is to commit small, reviewable pieces, but then each commit involves several interruptions, and it's difficult to go on to part 2 while addressing everyone's concerns about part 1. The infrastructure is problematic, because no one actually owns it, so there are more interruptions to deal with problems there.
Everyone has an IRC window open, and while there isn't too much social chatter, there is a distraction every time that a message arrives. (I hate IRC. I was forced to it in my last job, when people would IRC my officemate to get hold of me.)
I recognize the benefits of some of these practices. Code reviews do catch problems. (On the other hand, a code review often acts as a substitute for a design review, so we actually end up reviewing and maintaining bad designs.) More people know more of the code, and we avoid problems created by a guy going into a cave for weeks at a time.
But there is no denying that this style of working really makes it difficult to concentrate, at least for me.
I like to choose days in which I plan to be distracted, and days in which I plan to concentrate. During the former type of day I fix bugs, talk to people, do odd chores. During the latter type I stay home and turn off the router, and try to get some detailed design accomplished.
It'd be worthwhile for you to discuss and argue the process in your company. Having worked in startups like that, there will be times when developers will say, "I need some time without distractions. I'm going to be way over there; please don't disturb unless it's a serious emergency." As far as I've seen, people have been completely understanding of this.
Discussing it might not work if your boss/coworkers aren't good at grokking your needs, but their priority should really be to enhance your productivity the way you need it enhanced, not to force you to conform to their style.
I'm a young guy who works the same way you do. The insights I have after a few hours of hard work are worth the increased mental energy required. (It can be exhausting, and I don't want to talk to anyone after I'm done.) The downside is, as you've said, very few people seem to even attempt to focus for long periods of time.
I think a big part of the problem is the obsession with collaboration, as the article mentions. I feel it often leads to more and more 'fake work,' where employees deliberately work in an unfocused manner to avoid real work.
Simple example. It may disrupt my flow to help my colleagues solve problems, but it may save them hours of time if I say "oh, I already did that here..."
What I find gross is that the article somehow considers cubicles as a "private" solution.
This modern management cargo cult has reached really gross levels of absurdity.
If open plan is a cacophony of voices amidst which a person is to find focus and deep thinking, then cubicles are the same cacophony without the peripheral vision part.
I find teamwork, collaboration and such bullshit words just a mask for true motive. Cheapness. Cheapness in landlords, Cheapness in architects and Cheapness in companies who ultimately make up reasons for why they don't want to spend money and time on building truly productive environments.
I don't know about other people, but cubicles instill in me a sense of paranoia I don't get in an open office plan. It actively raises my stress level and makes it harder to focus knowing anybody can show up behind me at any time and I can't see them coming.
Thank you to the writer of this. This is actually the reason I only take work that allows me to mainly work remotely. I used to work in an open layout as described and I would be interrupted for every little thing resulting in not much actual work being achieved. Oddly enough the open layout seems to be'the way' for cool startups - maybe in actuality this driven more by the cost savings of having an open layout office versus the alternative. I find it to be a poor setup for having to do anything that requires mental concentration.
I'm sitting here in one of these "cool startup" offices right now. I absolutely hate it. No place to stack anything, no walls to hang whiteboards, calendars, pictures. No DOOR to close when I just want to get something done.
I have noise everywhere that headphones can't drown out. I have people tapping me on the back constantly because, apparently, having headphones on isn't a big enough signal that I'm trying to shut out the world. Yeah yeah, I know, sit people down and tell them. People forget. Just give me a door I can LOCK and that will work just fine.
I'm a few hours away from commandeering an unused storage room and making it the new Software Lab.
You have my sympathy. Was in a similar situation and tried lots of things... hiding myself in a conference room, headphones, being artificially mean, blocking out parts of my calendar as alone time, telling people I preferred to be left alone for the next few hours - unfortunately none of it worked because when people want something from you their impulse is to turn around and ask you when the barrier is so low. I'll admit that it wasn't a one way street, I probably unknowingly did it to people when they were in the zone.
The only thing that really solves it is if you can convince your employer to let you work remotely even a day or 2 - thats when I actually got to do real work. Just my 2 cents.
In my experience, the open office idea only works well if you've planned your company around it. I worked at one place where we were all open, but by convention, everything short of a true "the site is down" emergency started with asynchronous communication. IM and group chat, mostly. If it took more than a few messages, it might move to verbal, but it always started in a form I could ignore for a while if I felt like it.
Unfortunately, that only works if it's part of the company culture and each new employee sees it pretty clearly.
No whiteboards? What kind of startup doesn't have loads of whiteboards? You should go buy a load of that paint you can use to turn walls into whiteboards and paint your desk and cupboards and floor - www.ideapaint.com
No, we have whiteboards. They're just across the room on the outer walls where I can't reach them easily. We also went cheap and bought melamine bathroom panels that are impossible to erase.
I don't understand the appeal of open layouts either. Wherever I've seen them, they have been pushed unto developers from top-down. The arguments I've heard in their favor boil down to "they force people to communicate". Well, obviously, if developers don't communicate than it's a problem, but forcing a layout (or pair programming) does not seem to solve the root cause of the issue.
Ideally, I think developers should have a choice. There should be rooms for working in a group when necessary, and there should be cubicles or rooms for working in isolation. People would switch depending on the situation or personality.
I agree, the ideal offIce has a mix of both. It's great to have an area where everyone can chat and come up with ideas, but after that I want a deep, dark cave with impenetrable force fields and intra-office IM and email forbidden by nazi firewalls. I've taken to coming in on Saturdays just so I can get a solid 5-hour chunk of work done without interruption.
Poor communication is a cultural problem. No magic tool or seating arrangement will fix a company with poor communication skills. The only thing I've seen help in that situation is daily standups led by somebody who knew how to draw out more than "I fixed two bugs yesterday."
There are many parts of this article that boil my blood. The biggest of which is the use of "Groupthink" to describe a practice of creativity. Groupthink has a very specific meaning in many peoples minds which does not apply in this situation. Dilution of the word Groupthink as well as the mischaracterization of a practice the author happens to dislike are both egregious.
Creativity is often spoken of as an end. I do not believe that is true. Sitting in complete isolation being creative does good to no one. Instead, it is a goal to share and execute on your creativity and vision that you have thought of in your own mind.
Programming is interesting because it is a marriage of creativity and skill--it is not art nor engineering but is a craft. You forge creativity with skill (and experience) into lines of code.
However, that does not scale. If we have 50 programmers working in complete isolation then we will have 50 different programs. Collaboration becomes key to scaling the craft.
The only way to scale craft is through constant, effective communication. The tools we use every day as software developers serve to enhance, enforce or provide communication. Even in completely remote projects like Linux, there are tools used to ensure communication: code is submitted to a committer in small, readable patches; style guides focus on the readability of code rather than their cleverness or creativity; changes are discussed and debated on mailing lists and IRC; subcomponent Czars are assigned that share the overall vision of the project.
The so-called "Groupthink" isn't about Creativity--it is about effective real change in the real world by actually applying the creativity that we have instead of allowing it to evaporate.
However, that does not scale. If we have 50 programmers working in complete isolation then we will have 50 different programs. Collaboration becomes key to scaling the craft.
Sticking 50 people into the same room does not guarantee true collaboration. Especially if they have different goals, which is often an overlooked factor in large companies.
"""Since most programs can be broken down into a set of components I believe it should be relatively easy to parallellize the workload."""
The "easy" part of your phrase, is the one key misconception that project managers have since the beginning of software engineering. The mythical man-month and peopleware anyone?
You are probably correct, I haven't read those books yet! But, I was not explaining myself fully either way.
While I think the individual parts could be considered easy, the interaction of these and their integration I would consider a hard, complex problem with the potential to bottleneck all of the work.
The reason being: it's very difficult to parallelize integrative work because by its very nature, functionally it suggests dependency and coupling, and socially requires efficient communication.
I have a very comfy and full-featured home-office set-up, but still try to get out at least once a week to (ostensibly) work among other hackers.
There are some business advantages to not being cloistered, not the least being people know you exist and may be available for whatever kind of work you do. And it's good to have be around smart geeks who can answer questions or give you a sanity check on ideas.
But the big gain for me is the serendipity. I don't expect to be dreaming up amazing creative thoughts in any sort of communal or committee activity, but the exposure to semi-random ideas and events is important to my own thinking.
Left alone (or alone with the Internet) people may tend to only read what they're familiar with, or approve of, or in some way filter out the things that might challenge their beliefs and expectations. That's fairly natural, but it's bad. You need to take deliberate steps to overcome that.
If you pick your groups well it can help free you from the prison of self-reinforcing thinking.
If the group thinkers can re-invent Bolshevism for the classroom and the workplace, allow me to invent my own journalistic sociological gloss to bring attention to a physiological trend that the group thinkers might not appreciate.
It is an anthropological finding that the human brain decreased in volume by 10% — about the size of a tennis ball — around the dawn of civilization 20,000 years ago. It is believed that the decrease in volume coincided with the emergence of cooperative, prosocial behavior, which enabled the members of reduced-cranium groups to solve some problems that eluded their more amply-brained relatives. The larger brains were adapted to more independent modes of survival.
Bonobos have smaller brains than chimpanzees, but can solve problems that larger-brained chimpanzees will not solve, unless they decide to cooperate, which is unusual. [There are videos online of cooperating chimpanzees in the lab.] Successive generations of domesticated animals exhibit reduced brain volume in comparison with their ancestors.
The assumption that assimilation into the group is always good ignores the flip side of cooperation among prosocials. Prosocial behavior doesn’t imply feeble-minded docility. Fear of separation from the group, and antagonism toward larger-brained independent individuals is deeply ingrained. The reduced brain volume is compensated for somewhat by vindictiveness. Prosocials reward conformists and will punish transgressors at some cost to themselves. Road rage is an example. The capacity for revenge, even if this is costly, is the flip side of cooperation.
One should exercise caution when internalizing group values.
In a study published on July 15, 2011, in the Institute of Physics and German Physical Society’s New Journal of Physics, researchers have shown that swarming, a phenomenon that can be crucial to an animal’s survival, is created by the same kind of social networks that humans adopt.
…
Locusts rely heavily on swarming as they are in fact cannibalistic. As they march across barren deserts, locusts carefully keep track of each other so they can remain within striking distance to consume one another — a cruel, but very efficient, survival strategy.
— Science Daily (July 15, 2011), Swarms of Locusts Use Social Networking to Communicate
Man, what are you trying to say? Something about small-brained prosocial locusts eating separated chimpanzees because they feel vindictive, is that it?
I am asking how far we want our craniums to shrink in the name of cooperation. There are trade offs. I suggest that cooperation has its sinister aspects. And I believe you should carefully consider the group values you internalize, if at all possible. My career suffered at my previous place of employment once I pointed this out, so one might wish to be circumspect.
I couldn't make it past the first page of the article because I felt it was veering too much into the territory of "I have an axe to grind, and I'm looking for anecdotes to support it." My two sentence take:
1. In my experience, private space and time is necessary for individuals to get real work done.
2. In my experience, small, focused teams which have as-needed discussions and well-partitioned responsibilities are massively more productive than individuals when it comes to solving large problems.
I felt he was confusing my two points, and it got frustrating. Collaboration does not imply literally working with those people in the room all the time.
This is very interesting, especially in light of certain software development approaches such as XP, where you're told to work in pairs as much as possible. Many people argue that you haven't truly experienced teamwork until you've pair developed for a whole workday together for months at a time. The approach works for several companies, Pivotal Labs comes to mind.
I've personally experienced benefits of that work style, but at the same time I've always wondered if in the process you lose the opportunity to be by yourself and deeply and creatively think about a problem from different angles, without having to share that with anybody while it's still brewing.
On the other hand, you have companies such as MySQL that were almost entirely remote, and still managed to get lots of great technology built, rarely, if ever, working in the same building. That did the trick for them, they were also quite successful.
I think at the end of the day you can have the cake and eat it too. How about this: if you need to do some deep thinking or some heavily creative work, you can do it on your own terms, by yourself, late at night, like the Woz would prescribe. If you need to do some work that you can easily wrap your head around, then working closely together with someone else or a larger team is a likely boost in effectiveness, as it provides you with safeguards and spare pairs of eyes.
I don't disagree with you, but I think pair programming (at least as how it was explained to me, and how I've approached it in my studies/work) is less a mechanism to foster creativity and more as a 'second set of eyes', a way to alleviate tunnel vision. (I not-so-fondly remember staring at an error-throwing piece of code for at least twenty minutes until a friend pointed out that I had accidentally used a ')' instead of an ']').
I vaguely recall reading somewhere that pair programming wasn't meant to be for more than a few hours a day (like 4). An agile coach I know agreed with this. But I can't easily find this caveat on the net.
I remember seeing that, you're right. I believe it's actually in Extreme Programming Explained, or in one of those other core books. If I recall correctly, the guideline was to avoid pair work at maximum intensity for longer than 4 hours (small breaks are implied).
I've spent far more programming hours pair-programming than working alone. It works for me. This fall I decided I wanted to learn Cocoa, so I called up Pivotal Labs and asked if they had any iOS projects I could work on. They paired me with someone who had been working with Cocoa for a year. On day one I was adding value. Within two weeks I was proficient, and within a month I was working as fast or faster than other developers at Pivotal. I wouldn't have been able to do it alone.
Pairing is the fastest way to ramp up in a new language, ecosystem, or codebase. And beyond just ramping up, it continues to teach you long after you reach mastery, because you're constantly exposed to new perspectives and ideas. Pairing is also good for the team... by rotating pairs frequently, you distribute knowledge through the team. It's like a RAID array for your codebase.
People talk about the cost of being interrupted. But what about the cost of having to read through someone's solo-written code when they're home sick and not understanding it? When your team is pairing, you can interrupt one person while the other person keeps coding, maintaining the focus for the pair. If you have a question, ask it. If the team needs to know something, tell them.
Working alone is good, too. I enjoy rocking out with my headphones or working quickly from a gut level understanding and not having to articulate it to a pair in words. But often I find that my solo code improves when I expose it to feedback from a pair. Not a slow asynchronous code review, but a real time back and forth conversation. For me, software is a social activity. Deadly silent offices give me the creeps.
It's true that people are more creative in private than they are in public. But, that is why brainstorming sessions are so useful.
Brainstorm sessions might surface creativity that has already happened. If you ask a group, "What are some product ideas we haven't considered?", there's a chance that some people have been independently thinking about new products, but wouldn't have thought to propose them.
Or they can serve to direct/request creativity. If you ask "What are some product ideas we haven't considered?", people who had not been thinking about new products, might start. It gives them something to think about on the drive home or in the shower. I've received some great ideas via email a few days after the actual session.
"In one fourth-grade classroom I visited in New York City, students engaged in group work were forbidden to ask a question unless every member of the group had the very same question."
This is the essence of what's so destructive and horrifying about today's obsession with groups: the idea that everyone in the group is equal. Equal in talent, equal in work ethic, equal in drive, and equally entitled to being heard. And that the consensus of the group of purported equals is more important than the achievements of any of its constituent members.
The plain, and perhaps un-PC truth is that that's a load of hogwash. Some perspectives are better than others. Some people are smarter than others, or work harder, or are better read, or are more knowledgeable, or are more capable. Some creative visions are more correct than others, even if we imagine that it's not possible to be "correct" or "incorrect" in the praxis of creative expression.
Beyond these variances in ability or capability, we also encounter variances in style. As noted in the article, some people simply work best alone. Some disciplines -- writing, coding, art, etc. -- simply lend themselves well to conditions of quiet, relative isolation, and to long bouts of individual effort. That effort can be in service of a team, or as part of a team, but we shouldn't fool ourselves into thinking that creating by committee is in some way ideal.
The creative output of a committee tends to revert to the average creative capability of the least creative member on the committee. Social psychological studies have borne out that fact, and anyone who's ever been on a design committee knows it from brutal experience.
That's not to say, of course, that group brainstorms and the like can't be productive. They certainly can be. But the people in the group are everything. They need to be very sharp and very creative. They need to get along well enough not to clash over personal matters -- but not so well that they simply agree with one another and revert into groupthink. But such groups are rare, and I dare say that they're the exceptions to the general rule. High-functioning creative teams are things of beauty, but they're not for everybody or every situation.
Finally, the structure of a group is critical to its success (or failure). Groups with well established divisions of labor tend to be more productive, and far less painful, than groups in which everyone does everything together. Ever try to write a school paper as part of a team? It was either a horrendous experience or a fantastic one. The horrendous teams sat down together and drafted every sentence, laboriously and unceasingly, by committee. The fantastic teams either divided up the sections by areas of interest or expertise, or delegated the task of drafting the paper to the person who expressed interest and professed great ability in writing -- allowing everyone else to do research, discuss and debate the topics, and so forth.
"In one fourth-grade classroom I visited in New York City, students engaged in group work were forbidden to ask a question unless every member of the group had the very same question."
I'm going to guess that the idea here is that if someone in the group has a question, and another member of the group knows the answer, then they can resolve it within the group. Funny how the same thing can be framed so differently isn't it?
I used to be a teacher and received training to instruct exactly as you describe. The idea is that students are supposed to ask each other first, and if no one else in the group knows, then they ask the teacher. I have very mixed feelings about the push towards group work, but I will say that in much of the inner-city, asking a peer for help on anything is considered pitiable weakness. So the idea of getting kids to learn to work together and help each other when they can, is, at least in it's conception, not altogether terrible.
I believe that is an extreme and cartoonish conclusion to draw from so little information. How do you know that is the experience the children have?
The sister comment from another teacher brings facts to the table that explain the intent of the exercise, which is limited in scope and aimed for a specific purpose. Good or bad it is a game to attempt to teach kids it is ok to admit they don't know and to ask for help from their peers. If you consider how often and how ennervating it is when our adult colleagues can't admit not knowing, I think you can understand why someone crafted this exercise.
I have enough information to tell that children in this case are forbidden to ask their question unless everyone in the group has the same question, because that information was explicitly given. This is not the same rule as one which allows an individual child to freely ask the teacher whatever he likes, whether his groupmates want to ask or not, if he still feels like asking after trying his peers first.
The former process is controlled by the group; the latter, by the individual.
I agree that it sounds like a bad idea, but you're just having a knee-jerk reaction. You don't have enough information to make that judgement. How do you know this wasn't a well crafted exercise designed to teach certain elements of social interaction? I guarantee you a good teacher could use a situation like this as a tool to teach the class something valuable.
Hell, it could be an exercise to teach students the dangers of group think. It would be intellectually dishonest of the author to frame the situation in the way that she did, but we have no idea of the context. Did the author watch the whole class and speak with the teach afterward, or did she just observe the class for a few minutes?
Without more context you just don't have enough information to make such a damning judgement.
I am going to think beyond my programming, as it were, for a moment and make myself vulnerable.
I have a faulty logic. When I post something controversial, I often feel insightful while drafting it, but my 'spider sense tingles' because I innately fear downvotes. If it does, then I get upset because I feel that I made myself vulnerable by sharing something I should have kept quiet since it was not popular. Since an account apparently becomes 'dead' after enough downvoting, this is roughly being punished, at least digitally.
The faulty logic really kicks in when I use the same expectation of group reaction to garner upvotes. I feel satisfied when I get 10 or 15 upvotes, even though those posts are very often just aligned with what I suspect is popular opinion. I feel great, but gloss over the reality that I didn't really add anything new. It's like eating some chicken mcnuggets - I didn't really get anything out of it but it felt good.
There's a sort of protective stance people use in online posts, a deflection of anticipated peer reaction. Comment armor. "I know I'll get downvoted for this", "I know I'll get a -1 flamebait", "karma be damned" etc. We see this posturing all the time on karma based websites. Watch, I'll do this exact procedure in my closing sentence.
I know we're not supposed to complain about downvoting but I believe that's in a meta sense and since this topic is about groupthink, I believe it's relevant to discuss as part of the topic.
I've been grouped with people who always try to find a reason for something not to work. Their worldview seems very limited in that they never push the status quo; they don't seem to look very far into the future and they can't seem to recognize what's possible with some hard work. Maybe they are afraid to step outside of their comfort zone. They would probably call themselves realists. Coincidentally enough, through my personal experience, I've found that these types of people tend to be "control freaks". (Sorry for lack of a better word.) There's definitely some correlation between trying to control situations and only attempting what is a sure thing.
I've also been grouped with people who, like me, are constantly trying to do things differently for the better. For every idea, they try to figure out how and why it will work, if it isn't immediately obvious; but if they don't also take time to determine whether or not it is the best solution, it could be detrimental in the long run. This is where the qualities of each person within the group becomes important. Not everyone can find the balance between dreams and reality; more often than not people lean towards one side so they need to be paired with someone on the other.
Too many realists in a group and you'll see little to no innovation. Too many dreamers in a group and you may never see the project's completion. Although I personally would put my money on the latter any day.
But if one person can find that balance by themselves, I think that's when creativity (and sometimes productivity) exceeds that of a group.
Places which have nothing but cubes and sealed-off workers do miss some of the "creative" or "interactive" benefits of open, collaborative workspaces.
At the same time, places that strictly "open"...do indeed inhibit certain types of focused work. Isolation definitely helps progress in particular problems. There are examples throughout this thread of that.
I think the best work environments/attitudes are those that encourage a blend: the last few companies I've worked at have had open, collaborative workspaces, but at the same time really encouraged folks to go find their own nook (in the building or somewhere else entirely) when they needed to focus. The concept of "desk hours" or "continuous availability" was basically nonexistent.
It's all about balance. If your workspace lacks that in any aspect, you'll have something to complain about.
Off topic: The illustrator is apparently Andy Rementer, and while his name isn't familiar, the art very much is. Where else has this guy's work been featured?
Though I'm thinking I've seen similar styles before. It's vaguely reminiscent of some of the 1960s/1970s psychedelic comics such as R. Crumb. Not really my forte though.
In East Germany, toddlers and grade schoolers were required to go to the bathroom together, with no partitions between the toilets. Privacy was irrelevant because individualism was irrelevant. Even extending into bathroom habits the communist goal was to make people cogs. I'm sure this seemed like "scientific management" to them, and I bet many of them have no idea why it failed.
At my last job, all the programmers worked at a central table. I was criticized for working in my office (which I shared with one person) with my headphones on. This was called "siloing". They wanted people to work on code together.
I don't know about other programmers, but for me, when solving problems I find I often have many things in my head at once, many requirements to be met for the solution and sometimes a variety of variables whose meanings I have to keep straight.
I literally can't think when I'm constantly being interrupted. I can't think when I'm having to explain each symbol in a line of code to a co-worker.
Its impossible, until telepathy is perfected, for a co-worker to have the exact same understanding of what I'm doing and why. Sure simple obvious things are easy, but when you're constructing something original, you can't communicate it to someone completely because there are always too many details, even things you haven't resolved yet yourself.
At this groupthink place, every other programmer was in their 20s. They were all junior programmers (except for the founder of the company, who worked alone in his office.) They were not very productive. They adopted a whole lot of bad process, but they thought that by sitting around all at the same table they were more productive.
Maybe they were more productive than they would have been. But there was a huge gulf between the kinds of problems I was capable of solving (architecting major components of the product) and the kinds of problems they were solving (each unit test written was a task, everything was broken into tiny little independant, simple tasks.)
After I left, I decided I was done working for other people. I knew it was time to do a startup, because I'd reached my limit.
That company culture represents the view that people are cogs. Just like the east germans attempted to instill into their kids the culture of being cogs.
I think wozniak is right. Great programmers are artists, they live in their head. I wouldn't call myself a great programmer-- I'm competent, and I'm great at knowing my limitations.
But I make a really terrible cog.
That startup failed within a year after I left it. Somehow I doubt any of them think it was due to their process.
> when you're constructing something original, you can't communicate it to someone completely because there are always too many details, even things you haven't resolved yet yourself.
This is what's so hard to explain to people.
It's the necessary, painful part of any project: where you get to the part that you may not know exactly how to solve. A more communal individual would be prone to throw their hands up and call for a meeting. (I hate when people try to make their problems be everyone's problems.) But, they're cheating themselves out of a wonderful experience. Going at it alone in the face of uncertainty is a delicious thrill; you start hacking away at it, hoping for something to give, but ultimately knowing you're just making it up as you go, and it may not work out. Eventually, you learn enough about the problem such that you can talk about it semi-coherently. But until then, talk is useless, no, it is an impediment. Without understanding, there is no use attempting to articulate anything. Intuition begets understanding.
I believe some companies simply cannot accept this level of uncertainty. It's too dangerous to take something on that might fail. They can hire all the cogs they want.
I feel what you're putting down. It is very hard to explain to people what it is like when you are at the point of a project where you are not really even looking for answers yet. No, you're still determining what the questions are. You're still figuring out what the "what" is. They just don't get it, but I really think you have to go through that to produce a useful product.
> In East Germany, toddlers and grade schoolers were required to go to the bathroom together, with no partitions between the toilets. Privacy was irrelevant because individualism was irrelevant. Even extending into bathroom habits the communist goal was to make people cogs.
Oh please, what a ridiculous example to bring up in the context of the rest of your post. The GDR did not fail because of a different approach to bathroom privacy for small children. It might seem weird to us, but our comfort zone is a completely arbitrary area along a scale. Note that western urinals work in basically the same way; I'm sure there's a huge political significance to that.
Why are you being so unpleasant? Viewing a desire for bathroom privacy as reactionary is characteristic of the whole set of ideals related to the new soviet man.
EDIT: And yes, the unrealistic dream of building a society of new soviet men is central to the failure of communism. Hayek's criticism of a planned economy is valid but a hypothetical society of very altruistic people could make it work much, much better than it ever did in practice.
Thanks for the stories. I love hearing from people who lived in former East Germany. The stuff that went on is just hard to imagine sometimes. I'm always left wondering if there were any true believers, or if everyone just went along with a 'well, what can you do' shrug and made the most of it while privately laughing at the attempt to recreate society in a new image.
That's very true. Today's most intense jobs require originality in ideas and that's not possible in a group. Groups are good for commoditize-able jobs or jobs that can be partitioned orthogonally. Otherwise, for research or creative work, groupthink inescapably leads to lowest-common-denominator solutions that are almost invariably unexciting. You see the same pattern in research, where very few great discoveries are being made in pairs (and much fewer in more than 2 people groups).
-Nikola Tesla