If you are the smartest person in the place, either in truth or in your perception, then you are probably going to fall behind your peers who work in other organizations where they can work with talented professionals, have their ideas challenged, and improve through collaboration.

I have been fortunate throughout my career to work with very good software developers, architects, and problem solvers. While I think that I have been able to bring a lot to the table over the last 15 years, I believe that the best ideas and solutions have come through a collaborative process.

So, I don’t think Mark is saying that you cannot come up with solutions when working by yourself. It’s more to the point that you will typically get better solutions when working with others.

Bubba

In both of the incidents you described, it seems like you discussed a solution with someone else, and you personally came up with the better solution because the issues echoed previous experiences you’d had.

If you’d been solving those problems by yourself, it might have taken slightly longer (without the benefit of someone else to organize your ideas with in discussion?), but you would have come up with the same solutions; it was your personal experience that was the key. If you hadn’t been there to help, your colleagues would have deployed their less ideal but probably still effective solutions… unless while implementing them they too stumbled into the better answer. Either way, the project moves on.

Not all projects can afford multiple lead developers (some will just have one lead and some interns…). Not everyone thinks better while interacting with other people (personally, I definitely benefit from discussion, but I think far deeper when alone — and that’s when my “breakthroughs” are, even if the germ was planted from a good discussion or something I read).

I’d agree that the benefits of direct collaboration are large; but never *ever* work alone with no exceptions? Too far, and just plain unlikely.

Besides, we are constantly interacting less directly — even a project I develop entirely solo will involve ongoing interaction with the customer or public, with everyone who’s published sample implementations, code for frameworks and APIs, language guides, etc. that I might read — everything I run into normally.

1) 10 developers were asked to get the legacy billing system integrated with a new CRM application.

2) 9 of the developers could write the code in C++ and Java that was required for integrating the CRM app to the legacy billing system via IBM MQ series.

3) 1 of the developers was from the legacy billing system written in Mainframe cobol

So that leaves 1 developer able to write, develop, and architect his code. His code came out perfectly fine and he actually beat the java/C++ developers to the release schedule. The project turned out well in the end, however what you fail to remember is not everyone is writing their code in Java or C++. Many companies have millions of lines of code out there written in languages that you may not be familiar with (and do not have the time to learn during a project cycle).

I understand your argument but it is not always doable. You still need Strong programmers that can work alone.

Thanks for the added info. This sounds like a promising avenue to explore.

Cheers,
-Mike Nygard

Of course, after nearly twenty years, when I do hit some algorithmic or structuring problem that is new (which gets rarer as you get older), I generally go in search of a ’sounding board’ to bounce ideas off of. What sounds great in your head, doesn’t alway look so good when you have to try and explain it to someone else.

So, I guess I’d prefer to work alone, or possibly clone myself. If only I had the 100 years necessary to be able to do that …

Paul.

We’re using JRockit in our environment, so there is no perm space. Classes are loaded in heap space, so we simply filled up the entire heap. JRockit won’t crash with an OutOfMemoryError like Sun’s runtime will. JRockit appears to want to GC to find space and page what it can to disk. So, our servers never quite crashed, they just spiked to 100% CPU usage (GC) and lit up the drives with IO (paging), which makes the server unusable. I’d rather they just crash with an error.

Sun’s JRE has perm space that would fill up with classes. HotSpot will also throw an OutOfMemoryError before jettisoning the heap and classloaders before trying to start again. The restart never seems to work, of course, because all the required lifecycle methods are not called on various containers. I’d rather they just crash with an error, too.

You are exactly right. We did not keep a single instance (static or otherwise) of the Spring AppContext. We created a new one on each login. Every AppContext generates classes (Spring proxies and Hibernate DAOs). It is these classes that fill up perm space because they never get unloaded.

Mark

Cheers,
-Mike Nygard