What are some of the pros & cons to being a lone developer?

+29  A: 

Best: No one overwriting your code and breaking it.

Worst: No one fixing it when you break it.

"No one overwriting your code and breaking it." Until _you_ go back to fix code you wrote 6 months ago.
Paul Alexander
Nothing a good version control system couldn't handle...
+80  A: 

Some pluses:

  • Get to do all the fun parts yourself
  • No personnel issues
  • Ability to choose own algorithms and conventions
  • Often, ability to choose own schedule

Some minuses:

  • Have to do all the dirty jobs yourself
  • You can't learn much by reading the code of others
  • No one to review your code or to bounce ideas off of (easy to become myopic, or just plain lonely)
  • No one to share the blame and late hours with when things go wrong, and at some point, things always go wrong

Telecommute as part of a team. You get to work alone and as a team at the same time. :)

this sounds silly but sometimes I pastebin my code and show it to friends or freenode folk to review it. It's not great, but it's better than nothing.
@dassouki Doesn't sound silly at all. Sounds reasonable to me.
@dassouki I do the same thing here. It also helps to have friends that are developers at other places that you can IM and get help with your code and/or get it reviewed.
Totally true answer! :(I'm currently a lone developer for the computer lab at my college. We don't have the money to officially hire a development team because we're in Arizona and don't have the funds to do that :( I'm pushing though! I will be persistent in my requests :D
@Zack: Does being in Arizona affect your situation? Just curious, hadn't heard anything particularly bad about the economy there :)
Matt J
I work my local community college (academic computer lab). Arizona is ranked 50/50 in education. (last in other words). We don't have much money for a development team -- last semester they froze all of our budgets!
The 'no one to bounce ideas' is actually one of the biggest issues
Remus Rusanu
Another big plus is being able to listen to music while your programming without getting any weird looks. (music happens to keep my mind focused somehow when doing "routine" coding). Yea, the no one to bounce ideas off of is bad though. It gets to the point where you go to your non programming friends to try to bounce ideas off of them that are way over their head.. (I do this more commonly than I'd like)
+7  A: 

Working with other developers is also one of the best ways to learn how to do things better. Whether it may be through their mistakes or through their knowledge about programming

+24  A: 

Best: No decyphering other people's code. Worst: No one to decypher my code.

Actually, the real worst thing is that there is no one to bounce ideas off of and to learn from.

+1: "no one... to learn from" Boards aren't the same as live interaction.
John Pirie
Yea. I agree with the worst one ("no one to bounce ideas...").I have my boss at work here who knows programming but it's been a while since he's done programming in a *real* language (not vb script) and doesn't know my primary language, which is C#, nor the .NET Framework. I struggle a LOT while doing coding here and sometimes ask myself "why am I doing this...I don't understand how it works!" I stick with it because I'm hoping they'll either hire me on full-time to work with their coder team or until they hire a real dev. team and perhaps name me leader. :)
+32  A: 

You can usually win the arguments you will eventually have on how to do things...

It's hard to explain to others when you lose those arguments...

Sure, I have arguments with myself all the time. (They're not so bad until they turn violent.)
Michael Myers
I know, I'm dangerous when I corner myself :)
You can actually lose arguments with yourself when you are a lone programmer. Write something one way realise it's slow, complex or just plain wrong and have to redo it.
+28  A: 

Big Plus: You have near-total control over your own code.

Big Minus: You have near-total control over your own code (and your own mistakes).

Honestly, it is not nearly as fun as it sounds.

Matthew Jones
Superb answer sir! And how very true.
+1  A: 
  • Worst: no one to bounce ideas against
  • Best: Free to choose the solutions you think is best yourself

It's a personal thing, some people enjoy working in teams other working alone.

Fredrik Leijon
+4  A: 


  • No frustrations of bad programmers in your team.


  • No brainstorm sessions

  • Take architecture decisions on your own without anyone to discuss it

Regarding the Pro: unless you are a bad programmer yourself. (But then again, not having anyone to interact with, how would you know you're bad...?)
If a tree falls in the forest and no one is around to....How do bad people know they're bad in the first place? Or good people know they're good?
+16  A: 

I don't know if I've seen pros and cons. But I have noticed some differences.

If I say to another programmer, "remind me that it would be better if I kept track of the min and the max of that array while I was reading in the data," the programmer will say, "Oh, dude, I'm not going to remember that."

If I'm working at home on my own and I say that same thing to the dog, he'll just keep trying to steal my sandwich.

+24  A: 

Speaking as someone who has pretty much always worked as a lone developer (not by choice), the biggest minus is the fact that there's nobody to bounce ideas off of or suggest alternatives. You pretty much have to either "waste time" researching things or go with your gut instinct which might not be the most effective solution. The fact it's almost always quicker to do the wrong thing doesn't help when you have nobody to back you up and say "It's worth it to take the time to do this right" and have management breathing down your back for quick solutions.

IMO it's a really horrible situation to be in - I constantly find myself stressing out because I have to do so many things and I don't know where to begin with it; if I had someone, anyone, else to assist me I could at least brainstorm. As it stands, I can't even do that.

Wayne M
Yea, I find myself having to research a *lot* about something because I have no one to really go and ask who's not busy.
well said wayne
+4  A: 

I was a lone developer for three years - I worked on my own, on my own websites. The only problem I had was with the desperate sense of isolation I got when everyone else was in work, and I had nothing to do.

After three years, I decided to get a job simply to gain some social interaction.

On the plus side, I could work whatever hours I wanted, and I found that I tend towards a 28-hour day when I have no pressure to get up at a certain time.

Mr. Matt
I think I'd rather spend 2 days working, 1 day sleeping, then 4 days doing whatever I want (so the code is sane I'd probably do 3 days working)
Matthew Whited
+7  A: 


  • Nobody who tells you how to do your job
  • You can often take the time to refactor if you want
  • Build it using the technology you want
  • Take time to do research


  • Nobody to give you a compliment if you've just written that beautiful piece of code
  • Nobody around for quick answers if you're stuck or need that regular expression you suck at
  • You take the sole responsibility
  • Nobody to test your code --> more bugs will definately creep in (since you can't test your own code as well as others)

I would really love the fact that I (in general) would have more time to spend on research, refactoring, quality in general, and the fact that I can choose my own technology. I would really hate that there is nobody around to brainstorm with though, and to test my code.

+4  A: 

The biggest drawback I have found is that it generally leads to far poorer reviews (for a good developer anyway). Since there is nobody else working the same job to compare your performance with, the only thing for a manager to base your performace off of is the entire job's adherence to schedule. How many jobs have you ever worked that were delivered on time or early?

I did once have the opposite happen. The person who bid the schedule had no idea how much work would be involved for the little one-man job, and it turned out to be almost none. I got the best performance review of my career for that. HR actually insisted they knock me up a notch. :-)

Also, if you work in a group with a lot of other multi-person jobs going on, you will end up isolating yourself from the group if you aren't careful. That will give you a bad reputation for unsocialiability which it could take years to make up for.

+22  A: 

Pro: If you're competent, you'll be able to deliver high-quality code on time, on budget, at least some of the time, while avoiding annoying process overheads. It's possible given the scope of projects a lone developer can realistically tackle.

Con: You might get used to this blissful state and consider it the norm - until one day you have to work on a large-scale project with 20 other developers and run into the communication and organization problems that entails. Then when things go wrong (as they invariably do) you'll start blaming everyone else and the useless process overhead without realizing that it's the one thing that keeps things from getting even worse. In the worst case, you'll be the team leader and doom the project to failure by trying to run it like a 1 person project.

Michael Borgwardt
+6  A: 

A common mistake for experienced programmers is to solve things by making the code more complex. If you have to share your code with less experienced developers, they will make it clear (sooner or later) that you're making things too complex since they don't understand it anymore. By teaming up with less experienced programmers, an experienced programmer is forced to keep things simple.

Inexperienced programmers will just learn to write more bugs if there isn't someone more experienced to correct their errors. By teaming up with more experienced programmers, they quickly become more experienced themselves.

Lone programmers, experienced or not, become too set within their own mind. If you're a lone developer and you're aware of this then you will make sure that you keep your mind open for anything new. For a lone programmer, it is useful to keep a lot of contact with other developers on sites like this one just to keep their mind open.

However, when you're in a team, you must be able to work together as a team, and take the blame as a team when things go wrong. There's no "I" in "Team! If you can't work together with other programmers in real life, blimey! Better stay alone in that case, asking and answering a lot of questions at Stack Overflow. ;-)

Workshop Alex
There's no "I" in "Team! But there's an M and an E and that's good enough for "ME"!
Jason Irwin
There's also meat in a team and people who are no team-players are just dead meat. :-)
Workshop Alex
+1  A: 

I'm reminded of this brilliant scene in "The Magnificent Seven" when one of the Gunfighters is asked how it is to live like a Gunfighter.

After having answered the question, the Wise Guy (Yul Brynner, one of the Other Gunfighters) interferes and re-answers the question, with an incredible sense of psychological knowhow, along the lines of :

"Assets : none. Liabilities : none. Important achievements : none. Important perspectives : only those that you won't achieve. Places you've been : none. Places to go to : none. ".

It's a lonely life and yet there are people who simply do it because they are convinced that for them, it is the best option.

You are not alone.

+2  A: 

Everyone's answers are great and I agree, so I hope this is relevant to some by breaking down the possible scope of the question from another point of view.

  • If it is being a lone developer/consultant working for yourself out of your home:

    I'd say the consideration of being your own designer, SEO/marketing person and sales agent, project manager, DBA, and lead contact need to be accounted for if the project calls for it. How well can you wear each hat when needed? The pros and cons here are completely subjective to me for the type of project and definitely the type of client; albeit if you have all the control, you decide how much of your development efforts to put into each project, and why. In the end you may only be one of consultants hired, which also means you could be working with others anyway from time to time. Another consideration is how many other resources you know that could lend a helping hand when you actually do need some feedback or help because you've fallen too behind?

  • If it's about being a lone developer at your employer's office:

    I'd say it all depends on how self-sufficient you are at analyzing problems, finding answers, and managing your projects, not to mention how well your manager can understand your needs as a developer and can support those as requirements in a business (sometimes read: political) environment. It can take time to analyze, research, and plan, so if you're the lone developer at an office, more times than not you're the only one that knows what really goes into a technology project and it's tough to comfort others on the necessity of doing things the right way when it all comes down to time and money.

You need to be a jack of all trades in either role because you have to rely on yourself to be able to communicate well, understand the problem, know which direction to run with it, and sufficiently adapt and learn to be able to complete the project successfully with nothing but hurdles in your way. Although there's power and safety in numbers in our field, you can gain a lot of experience pulling the triggers yourself. Just cover your butt because someday it can backfire. Make sure you learn from that especially.

+4  A: 

Best: ultimate flexibility. You can even travel around the world and still be working.

Worst: there is an extreme amount of stress and things to take care on your own. This builds up.

Alternative: joining some interesting and small company and working remotely, while visiting the office a few times a year.

Rinat Abdullin
+4  A: 

serious negative: You can't pair-program solo

...without dissociative identity disorder.
Jeff O
+2  A: 

Pros: I'll defer to those who've already answered. Very, very good answers above this.

Cons: Your skillset gets dictated by only your own experiences if you're not paying attention to your self-pursuit of education.

I have to admit that because of my particular clientele, my skills did not grow in areas they should have for a season.

I was the PM, CM, Architect, Developer and DBA all in one on many, many projects. Did the projects do well? Yes! Did my skillset suffer? Absolutely. There seems to be only so much one can do if you're a loner AND your clientele have specific needs. If you're not carefully, you'll tend to focus on the client's needs (because of the $) and forget your own vocational needs. As a result, I've missed out on a couple golden opportunities because though my potential new clients realized my value in certain areas, they needed someone more advanced in the areas I'd slid on.

Summary: Be sure to keep your education and skills moving forward if you're alone or on a small team isolated to a specific technology or paradigm because of client needs.

+2  A: 

It's been my experience that the best teams are 2-man teams. You have some friendly competition between the two of you that keeps you on your toes.

True, and it's even better if one is more experienced than the other, so the other will learn some additional techniques from working together. (And force the more experienced programmer to keep things simpler, which is often better.)
Workshop Alex
+6  A: 

I would never take another programmer spot where I would be the lone technical guy in a group. Every time I've taken a gig like that I've had to take over a code base from a prior developer who was also the lone technical guy.

In practice that means

  1. The code base has never had a code review
  2. No one has asked how things work, how to set up the build, what the prerequisites to run it are
  3. The code tends to be sparsely and/or inaccurately documented.
  4. The code base got so bad, the prior developer left rather than continue.

This is also the case when you have Silo developers in a large organization.

I am always reminded of this perl code that was written by a lone developer who wasn't lucky enough to have someone point out when something was just a bad idea.

The few times I wished I was working solo, it was because of a dysfunctional team. The few times I worked with a dysfunctional team it was because I didn't get to meet them during the interview process.

Funny story. I was the lone developer on a project for awhile. I was replaced by Offshore resources (i.e. a whole team); then I stole my job back and will be taking care of it again. Therefore it can work out. sometimes. Mostly because Offshore resources work slowly and therefore the code should be mostly how I left it.
+2  A: 

Pro: Flexibility on coding. Con: No one to talk shop with or bounce ideas off of. Also, future employers may interpret this as not being able to work with a team.

Jeff O
+1  A: 

Pro You won't have to write any documentation or comments, or spend long hours in a meeting explaining the differences between Foo and bar, and why you formated your code a certain way.

Con There isn't anyone to blame but yourself when you come across poorly documented code with no comments. You won't have an excuse to step away from the monitor or to exercise your vocal chords often.

Even if you're a lone developer, writing documentation can be useful to you if you put the project away and then come back to it some time later. Also, if you are the only developer at your place of employment, someone else will have to pick up your code when you're gone, and they'll be glad if you left them any documentation ... and arguably you owe that to your employer.
My ex-boss always reminded me "If you get hit by a car tomorrow, how can we pick up your work?"
+1  A: 

Big con:

I think you can learn a lot from other programmers, even if they are less skilled, you can still learn new ways, new tools, etc' also by explaining, and seeing other's code, you are getting better.

Not to mention the isolation...

So if you code alone, you should find some ways to talk with other programmers, (no not virtually, it's good but not good enough).

Would even consider sharing a workspace with some other developer, that is working on some other stuff, just to get that peer effect.


I assume that some of the wildest, most outrages, best programs were written one-man solo like this, as there was no one around to stop them...

That said, on a bad company you get all the cons and none of the pros...

Liran Orevi
+1  A: 

Pros, you have control over the design and path you want to take your project.

+1  A: 

The best thing for me was the flexibility to control my schedule. But I pretty much worked around the clock most of the time anyway.

The worst thing was dealing with clients when they didn't pay.

Brad Rhoads

Pros: if you make a mistake, you can blame someone/something else, and there's no-one to challenge you on it

Cons: ditto

Jeffrey Kemp
+1  A: 

Pros: You and only you choose VCS, code style and other stuff.

Cons: amount of work that can be done without team is rather limited. Also testing suffers: other people can test such states that you never imagined.

+2  A: 

What is absolutely the worst case is to be solo developer at some company and also junior. I've been there, and a few years later, when looking back at the code and database designs I created & worked with, well... I kind of wanted to slap myself in the face.

Not to mention all the painful late hours trying to get my head around some tech issues and having absolutely nobody to go to and ask for help.

SO, in my opinion, senior lone developer might be ok providing that the person has a few years in the business, but JUNIOR lone developer - big NO in my book.

+1  A: 

Another con: No deputy when you're on holiday

Or even after you leave: I switched projects (and customers, but not employers) a year ago and just yesterday was getting "asked" (by my boss, who oversees both projects) to do some stuff for the old project.
+1  A: 

I've been in this position for awhile now, up until recently. The worst thing is you get "lazy", and end up not doing as much documentation and sometimes you don't end up trying to create better tools/abstractions, because you are comfortable with what you have and you have no time to improve.

That brings up to the second thing: being the lone developer means you probably have more work and less free time to think and look at the big picture, which is also very important to being a good engineer.

+1  A: 
  • PRO: Nobody tells you what to do, or how to do it.
  • CON: Nobody tells you what to do, or how to do it.
+1  A: 

One big con is that as a lone programmer, one can never have real big/serious things done, hard to compete with those good teams out there.

Most of the Pros that a long programmer has could be there for a good team too.

Dr. Xray