Being A Lone Developer

Question

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

Answer 1

Best: No one overwriting your code and breaking it.

Worst: No one fixing it when you break it.

Answer 2

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

Answer 3

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

Answer 4

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.

Answer 5

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

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

Answer 6

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.

Answer 7

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

Answer 8

Pros

• No frustrations of bad programmers in your team.

Cons

• No brainstorm sessions

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

Answer 9

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.

Answer 10

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.

Answer 11

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.

Answer 12

Plus:

• 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

Minus:

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

Answer 13

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.

Answer 14

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.

Answer 15

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

Answer 16

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.

Answer 17

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.

Answer 18

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.

Answer 19

serious negative: You can't pair-program solo

Answer 20

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.

Answer 21

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.

Answer 22

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.

Answer 23

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.

Answer 24

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.

Answer 25

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.

Pro:

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

Answer 26

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

Answer 27

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.

Answer 28

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

Cons: ditto

Answer 29

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.

Answer 30

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.

Answer 31

Another con: No deputy when you're on holiday

Answer 32

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.

Answer 33

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

Answer 34

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.