Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

I'm trying to put together some ideas for a talk, and one of the things that occurred to me, is if there's any documentation or research into how many programmers work as the lone developer within their team.

I think this is an important distinction because individual developers (and perhaps small team developers) end up having to wear many more hats than developers part of a large developer group. It could give us some better insight to career development and transition tactics, as well.

I've tried some generally googling, and wasn't able to turn up anything, so I'm hoping maybe someone has seen (or studied) something related to this.

Thanks in advance!

share|improve this question

closed as off-topic by Ampt, Bart van Ingen Schenau, ratchet freak, GlenH7, Dan Pichelman Oct 17 at 14:09

This question appears to be off-topic. The users who voted to close gave this specific reason:

  • "Questions asking us to recommend a tool, library or favorite off-site resource are off-topic for Programmers as they tend to attract opinionated answers and spam. Instead, describe the problem and what has been done so far to solve it." – Ampt, Bart van Ingen Schenau, ratchet freak, GlenH7
If this question can be reworded to fit the rules in the help center, please edit the question.

"lone developer within their team"... Over what time period? I never manage more than a week ;) –  Izkata Jul 21 '12 at 4:35
Over the general totality of their employment. There may be someone here and there who puts on a 'programming hat', so to speak, but by and large, i'm focusing on those who are 'the guy/gal who makes it all work.' –  JMather Jul 21 '12 at 8:01

4 Answers 4

Well, lone developer within their team - seems very strange situation, and it indicates that something is wrong in team building. Overall, mid to large size projects have teams and every team member work in coordination. At least that what we have in our team.

However, solo developers do exist in small companies, where he/she wears hats of every position to drive the project to completion. In addition, solo developers do a 2-3 week prototyping job in a big companies for solely product/prototype demo purposes.

There are dangers to program alone ! Some folks have claimed that [working alone] presents a great opportunity to establish your own process. In my experience, there are more hidden dangers of programming alone. More on this topic from post - In Programming, One Is The Loneliest Number

share|improve this answer
See, in my experience, the lone developer is fairly common. My current and former positions are sole developer positions. I have designers I work with, but no other programmers. –  JMather Jul 21 '12 at 8:02
"In my experience, there is no process in a team of one.": In my experience there can be, and sometimes it is much better structured than in a larger team. –  Giorgio Oct 14 '12 at 14:29
That expression is too powerful, i have corrected that to express what actually i had in mind. Thanks for pointing though! –  Yusubov Oct 14 '12 at 15:20
"indicates that something is wrong in team building." not necessarilly. If the company or team is small, he may be the only programmer they have and work alone on his part of the business while the rest of the company and team is concerned with things like marketing, finance, and customer support. Worked like that for a while several years ago, I was the only programmer in the company. We were a team, of course, but the technical stuff was mine and mine alone as nobody else in the team/company knew anything about it. –  jwenting Oct 15 '12 at 5:37

The lone developer in a team was called "the guy in a room" in a book called The Dynamics of Software Development. Good advice against this dynamic for the good of the team and the developer can be found on the Coding Horror blog.

Sometimes "alone on a team" is related to the needs of an assignment (one developer is enough, more would be overkill). Sometimes it is a consequence of attempts to separate a developer from other developers due to personal differences. Sometimes this kind of exile is self imposed. The developer doesn't want to work with others for any number of reasons like: he doesn't know how, others don't want to work with him due to eccentricities, skill/quality/speed of the work may lead to isolation, or he is simply belligerence. The opposite case where although technically sound, the developer fails to be assertive, so working alone is a route to having a sense of control over project decisions. Whatever the reason, I believe it is less effective in the long run to have insular developers. Solutions range from partitioning project differently, conflict management, training, team building, to disciplinary action.

Diversity is a benefit for teams. However, sometimes things can go wrong and people who can benefit from working together are excluded because people with things in common form a clique, excluding the other people. Teams can divide artificially based on age, politics, religion, national origin, race, sex, what degree they hold, where they went to school, what sports they like to watch or play, and a host of other silly reasons.

A few years ago, I traveled with a team of developers from our office to another office for training. The two offices were in different states, but within the same region, so culturally, there should have been little difference. There were important incentives for our team to engage with the other team. Our customer had a failing business and our project was cancelled. In contrast, they had a thriving business and we were being assigned parts of it.

However, the entire time we were there, the team from my office ate together, drank together, and sought out entertainment together, with little or no interaction. Perhaps it was a throw back to high school sports culture where we were the away team and they were the home team, and out of habit, competition was the paradigm and cooperation was atypical. Even in their lunchroom, where in theory food induces a certain level of casual mingling, four days of joint training passed with both teams in the same room, but barely interacting.

You don't want to know the result of this awkward partnership, but I can tell you it lasted less than two years. Management tried many things to integrate the teams. A vice president from our facility took over important functions at a high level, my supervisor became a manager for the other team, and I worked for a supervisor at the other facility who had been working to earn the manager position for about 15 years including many years as a start up.

Even with extensive restructuring to create cross site communication and engagement, I was one of only a few people who had daily interaction with multiple members of the remote team. Occasionally, I had conversations with managers from the remote site and was shocked that even after a year or more, they had so little interaction with members of their remote team that they could not recall the name of one of their direct reports. Not sure if it was the fault of the manager or the subordinate, but it certainly showed a serious problem with "alone on a team" that was compounded by geographical distance.

share|improve this answer

Lone developers will usually be found working on small projects or self-employed programmers who live off their own software.

share|improve this answer

We have lots of programmers at my company that work like that. We are a large company, but the engineering group is split up into teams of various sizes, most of which are responsible for creating or improving oilfield tools. These tools are complex devices with custom mechanical design, electrical hardware, and firmware. It's common for the engineer doing the firmware to be the only software engineer on their project.

The primary management organization is the managers in charge of the projects, but in attempts to improve the company-wide quality and consistency of our firmware, we have made a "parallel" management organization that allows all of the firmware people to do some amount of discipline-wide coordination and mentoring. This takes the form of design reviews, performed within that disciple, specific training requirements, and more informal mentoring relationships. Similar organizations exist for the other disciplines as well - mechanical, electrical, physics, etc.

I'm not sure if you'll be able to find hard numbers on how many developers are actually working solo, but there are lots of us who can talk about the disadvantages to working solo and some of the ways to work around those disadvantages.

share|improve this answer

Not the answer you're looking for? Browse other questions tagged or ask your own question.