June 19, 2007
Is software development an activity preferred by anti-social, misanthropic individuals who'd rather deal with computers than other people? If so, does it then follow that all software projects are best performed by a single person, working alone?
The answer to the first question may be a reluctant yes, but the answer to the second question is a resounding and definitive no. I was struck by this beautifully written piece which explains the dangers of programming alone:
Some folks have claimed that [working alone] presents a great opportunity to establish your own process. In my experience, there is no process in a team of one. There's nothing in place to hold off the torrents of work that come your way. There's no one to correct you when the urge to gold-plate the code comes along. There's no one to review your code. There's no one to ensure that your code is checked in on time, labeled properly, unit tested regularly. There's no one to ensure that you're following a coding standard. There's no one to monitor your timeliness on defect correction. There's no one to verify that you're not just marking defects as "not reproducible" when, in fact, they are. There's no one to double-check your estimates, and call you on it when you're just yanking something out of your ass.
There's no one to pick up the slack when you're sick, or away on a business trip. There's no one to help out when you're overworked, sidetracked with phone calls, pointless meetings, and menial tasks that someone springs on you at the last minute and absolutely must be done right now. There's no one to bounce ideas off of, no one to help you figure your way out of a bind, no one to collaborate with on designs, architectures or technologies. You're working in a vacuum. And in a vacuum, no one can hear you scream.
If anyone's reading this, let this be a lesson to you. Think hard before you accept a job as the sole developer at a company. It's a whole new kind of hell. If given the chance, take the job working with other developers, where you can at least work with others who can mentor you and help you develop your skill set, and keep you abreast of current technology.
Working alone is a temptation for many desperate software developers who feel trapped, surrounded by incompetence and mismanagement in the desert of the real. Working alone means complete control over a software project, wielding ultimate power over every decision. But working on a software project all by yourself, instead of being empowering, is paradoxically debilitating. It's a shifting mirage that offers the tantalizing promise of relief, while somehow leaving you thirstier and weaker than you started.
Like many programmers, I was drawn to computers as a child because I was an introvert. The world of computers-- that calm, rational oasis of ones and zeros-- seemed so much more inviting than the irrational, unexplainable world of people and social interactions with no clear right and wrong. Computers weren't better than people, exactly, but they were sure one heck of a lot easier to understand.
Computing in the early, pre-internet era was the very definition of a solitary activity. Dani Berry, the author of M.U.L.E., sums up with this famous quote: "No one ever said on their deathbed, 'Gee, I wish I had spent more time alone with my computer.'" But we've long since left the days of solitary 8-bit programming behind. The internet, and the increasing scope and complexity of software, have made sure of that. I can barely program these days without an active internet connection; I feel crippled when I'm not networked into the vast hive mind of programming knowledge on the internet.
What good are nifty coding tricks if you can't show them off to anyone? How can you possibly learn the craft without being exposed to other programmers with different ideas, different approaches, and different skillsets? Who will review your code and tell you when there's an easier approach you didn't see? If you're serious about programming, you should demand to work with your peers.
There's only so far you can go in this field by yourself. Seek out other smart programmers. Work with them. Endeavor to be the dumbest guy in the room, and you'll quickly discover that software development is a far more social activity than most people realize. There's a lot you can learn from your fellow introverts.
Posted by Jeff Atwood
Definitely experiencing this exact situation at the moment - mainly due to resourcing levels, rather than a deliberate decision - and it's not very pleasant.
I'd never thought of the internet in the 'Hive mind' sense before, but it's a good description.
Agreed that being the sole developer on a project is a lonely (if not painful) experience. Yet, there are also very successful 1-person mISVs out there. Those business owners happen to be usually quite talented as coder as well.
Not sure how it fits with your thoughts.
There are many conflicting view points on this one, personally I have worked in teams and alone and prefer to work alone for the following reasons:
1. Full ownership of design decisions.
2. No communication overhead with other team members.
3. Responsible for the project schedule.
4. Can set my own high standards, and do not have to encourage others to live up to these.
5. No "babysitting" of less experienced developers (sorry, but I've been there and it does take time and energy).
6. Can use a project to explore a new technology, without having to justify the decision to other team members or project managers.
7. Can communicate directly with customers without having to work through any middlemen (for example project managers or dedicated analysts acting as a conduit of communication between you and the customer).
8. Don't have to deal with other developer's legacy code, as all of the code is mine my familiarity levels are higher.
9. Get to choose what language and database to use for new projects, assuming that the customer does not care so long as they get their web application.
10. No time required for regular team and progress meetings with managers!
I could probably come up with more, but you get the point. The only reason I miss working in a team is for the peer review of my work, but for any projects were you are able to open source the code and release it publicly, the "hive mind" (to use your term) of the open source community will review the code for you, and will quite happily and vocally point out areas where you can improve.
Maybe I am just a control freak ;-)
Small teams are nice because they allow you to bounce ideas off people. I know that's an old programming trick, the old "bobble head" that you talk to but it's much better with real people. Sometimes just saying an idea outloud will make you realize it's flaws or where you could improve it.
On the other hand, you do have to have the *right* group of people. Some people just suck all your energy and they end up asking you to write their entire program for you, regardless of how subtle or firm you're with them. As far as when you do need to get into heads down mode I've found noise-canceling headphones work the best. Pop'em in, turn up the music and that's a sign that you have your Do Not Disturb sign on.
To be honest, I must confess that I really *hate* open-space hells, where the undisciplined guys are walking around, screaming loud just near my desk, when I am trying to solve one of programmer's daily puzzles. Maybe, just *this* made me misanthropic.
On the other side, as a freelancer I am to deal with trade and marketing stuff which doesn't belong to my hobbies.
I can see both sides, because I both work solo and as a team.
The Biz itself is a team effort.
The Computing is done solely by myself.
If I want to work with other people, that could be arranged. However snags would arrive fast and furious.
"What do you mean you can code in xhtml"
"What do you mean you need your IDE, whats wrong with a text editor"
"No I do not want trash flash on the website"
"No you do not need a database to store everything, its called fopen()"
The list is endless . . .
Working with somebody else is only possible if I lower my standards.
"What do you mean you dont do Unix !"
This is tricky, and yes, I am feeling the solo work problem. But I'm a self-employed freelancer. How do I get all those benefits when I can't afford to pay someone else's salary?
I think there is a huge difference between working by yourself FOR YOURSELF (freelance or mISV) versus working by yourself for an employer fulltime. I was recently employed as the only developer and sysadmin (sysadmin was not the role I signed up for) in a company of over 40 people. In this situation I had no control over the project. In fact, the project that I was hired to work on was never started. Thus I was banished to fix bugs in a legacy system and do sysadmin for 8 months until I finally resigned. Now I couldn't feel better!
I find it too easy to get off task or thrash when alone.
classic post .. I could relate to this from my previous years as a lone-ranger consultant / developer...
What truth! I had this same misconception for a job I quit coming up around a year ago - I wasn't the sole developer for the company - but the sole developer for the organization I was in (not IT but Engineering). I had to come up with standards that only I would have to go by, and it was fun up to a certain point. I really craved interaction with other developers - almost anyone other than the boss (who interestingly enough only managed me).
After quitting, it was offered to continue doing it by contract hour which I am doing at night. Still - I really almost still long for the day when someone actually gets hired (they did hire someone but he quit I don't think more than a month or so after he started - probably for this exact reason) that I can go over the code I had done that she/he would continue and I would just be assisting on. Well - I doubt that will ever happen since I just don't see them ever hiring 2 developers.
Looks like I found the perfect contracting setup though!
I seriously dislike working alone on projects, for the sole reason that when the inevitable delays/setbacks happen, you have to take all the heat yourself. With a group, when *everyone* is late, its much easier to put the blame where it belongs.
Heh. I'm sorry, but every time I see the title "Evangelist" I picture this image:
I don't suppose you have a really big beard, do you? :-)
I absolutely agree. I greatly prefer working in a small group if only so you can QUICKLY get an answer to:
Have you ever tried to do such-and-such?
There are an awful lot of issues that are impossible to dig out of something like Google or Ask unless you know JUST how to phrase the query.
Thats my story. Being sole developer sometimes just pain in ass. I dedicated whole myself to recent big project, I couldn't fuck up. I worked at home to meet deadline, I managed to do this, but still it hurts.
Looking forward to find teamwork job, but now I get used to be lone wolf. In software development, in life. Thats not very effective way of doing things, so I decided to build social skills.
For now - thats picking up girls for me. It has nothing to do with coding, but it builds communicational skills.
Technical skills are great, but social skills are more valuable.
So make a decision: reverse your introverted self to the world: become extrovert.
One of the very few advantages of working alone is that when one is motivated, he can try things out all the time and learn from them all the time as well. It has been my personal experience, anyway.
In part, I think working alone is a bit similar to the guy who is working on his PhD, and in both cases one ends up becoming a crude expert at what he has chosen to study.
When you need to convince others to join you and when your work output becomes a responsibility as in "maintenance", you might not go as deep as you could have otherwise.
Many folks have their sole moments when they might create what thousands or more people will use as soon as it's released. Of course, months by yourself is better than years by yourself. :-)
And while working with others might bring a lot of inspiration, it's quite rarer to be able to use that inspiration in your actual job. Sometimes, folks would rather you left your inspiration at home so you kept your "focus on the job at hand".
It seems like your last two blogs were taken from the pages of my life. I'm definitely on an island by myself right now.
I'm working on a side project by myself right now. That's in addition to my full-time job. I never thought it would be so hard to work 8 hours and then find the motivation to work on my side project at home. It would be a lot easier if I wasn't the only one coding, but then I wouldn't get as much money. ;-)
I think I might have to decline the next side project until I can find someone willing to split the workload with me. It's great to do freelance projects when you don't have a full-time job but it really sucks the life out of when you do. I haven't had a day off in 3 months and it's starting to stress me out.
Just curious why you chose this topic to comment on, since I was under the impression that you were part of a development team.
What brought this subject up?
I'm so glad there is someone else out there that has felt and knows my pain. I worked as a developer of one for a small company for almost 2 years. Initially, it was very cool as the company was a startup and it was a chance to be in on the groundfloor type of stuff. Then as time dragged on, so did the work, the b.s. built up, I had no one to bounce design ideas off of, no one to ask about bugs, it just sucked. It was the suckiest suck that ever sucked. It just plain sucked. I'm convinced its how I got ulcers. Thank you for hearing about my plight.
This could be true in business, but in school it's a recipe for Evil, like teachers assigning a totally incompetent student to work with me. He was in his 11th year of a 4 year education and with good reason. I still ended up doing it by myself and having to make him look busy. Then you have your teams of 8 people with 5 total slackers that later accuse you of not involving them with the project.
I'd hope there are more motivated programmers and less dumb unmotivated slackers out there in Real Business than here in kindergarten university, but I think I'm already too cynical for hope. Who can you trust?
I mostly disagree with this post although it is a good post along with the comments prior to this one.
I believe that a talented developer, with the right discipline and passion, can accomplish a lot working solo. Here is a post I wrote a while back that captures some of my thoughts on this:
Think of yourself as your own CEO where the business you run is yourself. If you work for someone then think of yourself as a business within a business. It is a good mode to get into especially if you have the desire to strike it out on your own (i.e. freelancer, Micro ISV, etc.).
You can also complement your solo career by still being active with others. Such as being involved in open source movements, attending local community gatherings, staying abreast on syndicated feeds such as this one, etc. Don't forget about using other forms of communication such as instant messaging (with web cams) or even Second Life.
Communication and collaboration doesn't cease to exist once you have gone solo, it just changes form.
As I said in your latest post about proceses, I believe that a team of two developers is ideal for many reasons.
I've been a sole developer upwards of 10 years for the same company. I think very few developers are in a position to demand they have other programmers to work with, certainly that was my case as I was the only developer doing what I did - there was no on else.
But that aside, the keyword here is "discipline." Yes, I know it's easy to ignore and hard to do, I have my tangents as well, but when it comes to being overworked and beat up on, you just need to say "No" and keep your sanity as a priority. Because if you're tweaked out you are not help to anybody, yourself or your employer.
If you're running out of time or resources that is entirely (probably) not your fault. It is usually the manager's fault -- a manager's job is managing resources for their staff, so if you as the developer are running out of resources, or weren't given many to start, then this is your boss's problem.
I try my best to stick to my guns and not rush myself or freak out just because someone failed to give me enough time or information on a project. And I'm not talking what I think is enough time, I'm talking the "we need it tomorrow" type stuff that we all get way too often. I refuse to jack myself up due to poor planning and organization that is beyond my control, and so far this approach has worked pretty well.
And when it comes to having backups for vacations, etc. that again is the fault of those above you. It's not my fault that they haven't hired another developer. That's their choice and their pill to swallow when I do go on vacation.
When it comes to work methods I will have to argue that a one-man process can be better because it is homogenous. Right now one of my friends in another department is dealing with project code that has been touched by *too many people* and thus is extremely hard to debug and fix. It's not that there were too many people really, but that those people were not well managed or organized.
More people is not a good solution if those people cannot organize or be controlled.
However, the one area where working alone does bite is in brainstorming. Coming up with ideas is just hard and the more heads thinking the better off you are. So I took to calling other nerds around when I had a problem and we all thought it over. After a session I took all those ideas and went back to work on a solution in solitude. It worked out most of the time, but having extra brains is invaluable.
Another danger of working alone is you get used to it and is hard to get back to groupwork. Alone you can move along pretty speedily, not so much with a group of people. It's a hard change to accept, but then again, you just have to discipline yourself.
I spent a lot of time when I started trying to adapt team ideas into a single-man idea. Success is possible, you just have to stay focused on what will keep you happy and stress-free.
Good topic and a situation that I think is more common we realize.
I agree with the posting, but I think Peer programming is going too far. I like working with others, I think code reviews are great, but to have someone looking over your shoulder (or you over their's) while you develop together has been a negative experience for me.
I would KILL for another developer to even be in the same building. Having another head to discuss things with when I get stuck, or even just show off what I think is a cool trick. How about a discussion of best practices? My output passes the ultimate test, it runs and does what it is supposed to, but what could I have done better / different? Jeez just somebody that understands what I do so we can talk shop over a cup of coffee. Yeah I love the "hive mind" on the internet but it is difficult to talk to, and as my fellow inmates in this rat maze that is our cubicle farm already think I am 3/4 nuts. Talking to the Internet would assure them it was time for the white jacket gentlemen
Working alone in a quite room is bliss, pure bliss.
Now as for working alone for some jerk organization, that's where you simply must have good political teeth - show them - and you can go back to your quite cage and code.
Ahhhh alone is bliss..
I currently am the sole developer for a large company and working alone is not pure bliss. I haven't had a vacation in 2 years due to the rest of the IT staff not having any kind of development background.
I am constantly on call for one thing or another.
So yes.. I think a team environment is a much better working atmosphere.
pI'll throw my $0.02 in here, if only to add another voice to the choir. I am an IT department of 1 for a non-profit company that employs under 20 people (15 full-time). I am responsible for the office network, from clients to servers to CAT5, and assisting off-site consultants and staff. E-mail, web-server, domain management, the list goes on./p
pOn top of all those responsibilities, I'm also the guy who does all our system development (web-based management program for our offered services). It's incredibly frustrating to find my coding groove only to be interrupted with some (sometimes insipid) question about a printer issue, or a missing e-mail, or how to create a PDF. And my boss wonders why I almost never give completion dates!/p
Well yes, there are pros and cons. I think it depends very much on the talent pool and whether the team roles are well understood. Where I work the talent pool and education level is very mixed and projects have always been highly individual.
That means while I do take part of larger project phases, it gets a little harder by not being able to be there physically. And I certainly do miss the social aspect , however I have not REALLY felt part of a well greased team since university where you can actually choose compatible people that you respect. And it does take a high since of self discipline.
I work mostly from home, it sames me many hours of commute and money for the ride. I get a lot done, unlike when I go in to the office and spend most of the day socializing, in meetings etc. Also, I get to do what I want, when I want - you do not depend on anyone so the development pipeline is never clogged because you are waiting. Of course, it is important to throw design proposals around to peers and have some informal feedback not to go blind. I don't have to babysit newbies, that do not yet realize how much they have to learn.
Hmm, I don't entirely agree.
I have worked on a team of over 50 programmers, a team of 10-15 programmer, a team of 5 programmers, a team of 2 (including me), and I've done projects by myself. Each of these situations was for at least a year.
The bottom line is, the larger the team, the worse the nightmare. Anyone who's ever been on a large development team knows how impossible it is to touch any single line of code without stepping on a whole row of toes. Decisions and discussions which should take no more than a day to resolve go back and forth for weeks, and I'm not even going to mention the management.
Possibly the best situation I've ever been in before now was when it was just 2 of us working side-by-side but not neccessarily overlapping in our development. Person A wants black box library to perform function X, and Person B wants black box library to perform function Y. We got loads done, we fixed each other's code, kept each other in check, etc. - but I'm not talking about XP-style "2 programmers 1 keyboard", which is simply not efficient for experienced programmers (I've tried).
In my current situation, I work on smallish (1 week to 6 month) projects, largely by myself, but on a programming team of 5 people. There are always people to go to for help, and always people to show off to, and always some accountability between us, but the person responsible for the project gets to make most of the decisions, and that's pretty much ideal for me. Best of both worlds.
I wonder how widespread is that tendency in small-to-medium companies to divide projects between programmers... It seems to me that employers are afraid to waste more than one resource on a single project, so they assign projects to specific people. It even appears they're also aware they're shooting themselves in the foot, not to mention their programmers' leg! Do these managers care at all? Don't they have any vision?
The single programmer has to develop other strategies to counteract the debilitating effect of working alone. These include: self-discipline, seeking outside sources of information, an ability to envision multiple viewpoints, joining user groups and engaging in technical chit-chat... but is that sufficient?
I don't think so. I've been there and I never was able to get up to my own standards working this way.
I expect there's nothing like working with a team that's good enough to recognize what to aim for and work at it. Anyway, I've fantasized about it, argued for it, tried to sell the idea, because I've figured it could be a really nice way to stimulate growth of processes, products and individuals, not to mention the bottom line. I've given up looking for such an employer. And to be frank, I'm a bit shy of my shortcomings to apply, even though I'm considered competent by my peers.
On the brighter side, these sort of situations can teach you a valuable lesson: leave the computer alone and seek out various other people in different situations.
I used to be the sole programmer in my group. I had a good boss who - while non-technical - could give good general advice (non programming advice) and help deflect things at the time.
My days spent as a single programmer are looked back on fondly.
These days, I'm still a single programmer essentially. I rarely work with any of the other developers because my immediate team consists of me. I have to make all the design decisions and write all the code.
Working in a team has merit. Working by yourself can be great. Working by yourself can also be horrible. My current experience I would describe as the latter but the first time I did it, it was great.
To the guy that hasn't had vacation in 2 years...take a vacation!! They can't NOT let you take vacation. Period. It doesn't matter if there is no one to fill your spot; not your problem, their problem. People that are all-work-all-the-time will go nuts and/or burn out and then be no help at all. Just remember that you are important to them and they have invested a lot in you, and you're probably (honestly) underpaid, so you have to do things for yourself sometimes.
You have to put yourself first, then your company.
The reverse is another problem and could be another article all to itself.
While I agree with the post, in terms of pure productivity on the right project, working alone can be best. One example: http://damienkatz.net/2005/01/formula-engine-rewrite.html
I'm in a strange position because I'm solo in this city with the core group in another. It is interesting to see how I'm viewed because I'm not part of the main group. My main coworker is in yet another city, and though I can call her, she works odd hours and I just never bother. She also never has IM on, and I can't help but percieve this as a signal to "let me me". I do think that the worst thing about this situation is, as you write, the lack of career growth that comes with collaboration.
I also wish I could work somewhere that did code reviews. Of all the places I've worked and interviewed with, I've never come across anyone that does this (save a single review of my first piece of production code).
To echo the "dumbest guy in the room" comment- the most "fun" I get at work is sitting down and discussing stuff with the highly academic (PhD-level) guys and hashing out what-ifs and such..
Could not disagree with you more. If you are stuck you can use the internet, but really I think stuff gets done faster, coding is more consistent and there is not far to look if anything goes wrong. Plus another benefit is that I know everything that is going on in the code, and am not surprised by undocumented changes or "fixes".
I think as long as you are a strong programmer and can be truly honest with yourself that 1 is the strongest number.
Working with other people is much better, for me at least. I went through a five year period where I was the sole coder and while having full control was nice, I realized that I was stagnating.
Everyone has their strengths and weaknesses. In a good team, those strengths and weaknesses overlap. Working alone, those weaknesses can kill you. But even more, we've all had the experience of that frustrating, inexplicable bug that you solve merely in the process of explaining the issue to a cohort.
There's seriously diminishing returns with both these things. After 6-8 people, the communications issues exceed the advantages.
But I think the single biggest advantage of working with other people is that other people teach you things. Working alone, it's too easy to fall into the same ruts of doing the same things the same ways all the time.
I'm an ISTJ with an extremely high I and I'm leaving programming because I hate it so much. I also though it was the perfect job for an introvert. :P
It matters WAY more what kind of people make up your team, rather than how many. Great development teams consist of talented, considerate, motivated people. A team of four with three mushrooms and one heavy-lifter is in many ways worse than the one heavy-lifter as a solo developer.
I am sorry to see the perpetuation of the "Computer Geek" stereotype. Taken in all, programmers and other computer professionals are no more or less "geeky" than other professionals (lawyers, CPAs, doctors, etc..). To be cool in these terms, you must be an athelete, celebrity, rockstar or some other unproductive mode of being.
I don't buy it... and neither should you!
The way to get both of what Jeff and you are valuing is to (1) find another developer who shares the same values and (2) realize that neither of you always has the best idea.
For the latter, see:
It took three years, but I have finally found a coworker who I work with that is an excellent software engineer, good communicator, thinks alike, and is willing to say "you're right, your idea's better." (I end up saying it more than he does though!)
We successfully convinced our team lead to let us work relatively alone and we move like lightening.
@Ian: I'm glad that you found someone that you can work with and be very productive, I guess I have been unlucky so far (especially in terms of management, but that's a whole other thread ;-)
Depends on the type of work really. If you're a jack of all trades in web development, you can successfully freelance alone.
I see pros and cons to working with others, and to working alone.
More or less, I think that what you need to realize and understand as a developer, are the times when you need to be social, and the times when you need to do certain things in solitary concentration.
Unless your fellow programmers are hot women, in which case, I prefer for them to sit on my lap so we can use the same computer together. All in a simply professional sense, of course.
Twice I've had the situation where there were just a handful of developers on my team, all working mostly independently on specific site enhancements such as adding new features but having occasional meetings on the general direction etc.
I like being able to just plan it and do it without 100,000 project meetings and status reports and approvals, yet still having others around to bounce ideas off of and to check things out when needed.
I'm in a small company now, and I really like that I get to do all parts of development..requirements, design, coding, database work, testing etc. I like to think I'm reasonably good at all of those parts and to me its just boring to do *nothing* but the actual coding, with no input and no customer contact.
A place I used to work started going on that direction for a while, assembly line development. My manager was determined that designers should only design and coders should only code. So anything that came in, no matter how tiny, (4, 6, 10 hr projects even) I had to let the official designers lay out the screen (on an already well established design) while I waited for my turn. It ended up a huge bottleneck as they were already overloaded, and not all that familiar with how to lay things out for later code insertion. So very quickly we went back to the old way pretty quickly.
I was working alone in my last job, as a contractor. I worked from home. I experienced many of the things the guy you quoted talked about. I had to live and die by my own estimates. I worked with a small one to two-man business. The owner of the business was so busy he was like a chicken with its head cut off. Occasionally I could get requirements or resource help from him, or an assistant of his, but otherwise I was completely on my own. It was scary, but at the same time rewarding. I got more contact with customers than I ever had before. I got more direct feedback from them on how I was doing. I got all of this because there wasn't that much between me and them.
It was hard, but at the same I was glad I had the experience. I realized that I could count on myself. I learned some valuable lessons in judgement, and customer relations. I also learned something about making my own decisions. When I worked on a team I was usually able to bounce risky decisions off of other people. I had a tendency to lean on others just so I didn't have to take it all on myself, which felt scary. When I was forced to take it on, because there was no one but me to do it, I did it, and realized I could do it. That's a valuable lesson.
I made some mistakes as well. One of them was time management. I was so focused on serving the customers' needs that I neglected to look at how much time (and a bill) I was racking up. I ended up having to eat the excess on some occasions. That'll teach me to "overdo it" again.
At the same time I'd rather not go through some of those experiences again, particularly dealing with a boss who was disorganized. That was the downside to the job.
Working alone, or in a team; I don't understand this sense of 'loyalty' people seem to have to their bosses and companies.
To the company, you are just another cog in the machine. If your boss says 'Sorry, you can't go on vacation because we don't have another developer.' that's not *your* fault. And it's not *your* problem. Managers get paid to manage. If your offer letter states 2-weeks or 4-weeks or whatever and you don't take it; you're just setting yourself up as a doormat.
Look at it from management's perspective...one developer can handle the entire workload. He might have to average 50 hours a week and not take vacation; but, he's salary and he seems like he doesn't mind too much. He'd probably just go home and program anyway, he might as well stay here and do it. Why would they go out and double their developement costs? Because it would make their first developer 'happier'?
You can't expect other people to do you favors. Work your 40 hours, take your vacation, and manage the expectations of those around you. 'Sorry boss, I don't think this timeline is realistic'. It's easy enough to find a tech job these days; why spend years in a job getting pushed around?
This is one of the primary reasons I just accepted a new position at a new company: to work within a team of developers instead of by myself.
Keep up the great blog! Jeff, when are you going to publish a book?
Right now, I'm trying to build a small team. Right now, we've got a code guy and a design guy (interface design, not code design. I do the code design.) I'm trying to find a 'mind of the masses' guy, and an art guy. I'd be fine with those two guys being the same person.
Code is my domain on this team. I figure out how a task needs to be done, I write the code that implements it. Ryan is the design guy. He knows how to make things look good almost instinctively. I may give minor suggestions, but that is his realm. This works out great for us.
What about the micro-ISV???????
Doomed to fail?
Are you advocating pair programming or simply working on a team with other programmers?
I've been programming solo for the last five years. And I disagree with just about every point. It's great. It is also great to work with a large or small team of smart developers-- I've done that too-- but working solo has its own joys.
Being the lone programmer does not mean you're alone. I work on a team, too-- with the CEO and sysadmin in the office with me. I never make a major design decision without their input. I talk to customers sometimes, too. If I am hankering for a code review, I'll have the sysadmin take a look.
I'd agree that it's not a great thing if you're a new programmer, but at some point you've mastered your craft and it's time to move on. And by move on I mean focus your attention not on the coding, but on how it fits into the life of your company and the life of your customers. And those lessons are best taught by those upon whom you inflict your code.
Working solo means I have to be project manager, architect, QA manager, and programmer. I have to manage my own time, and sometimes everybody else's as well. And I write the code so that a good developer could pick up my code quickly if I were to leave. (I'm really writing for myself in six months, when I will have forgotten what I wrote.)
The only difference between a big team and solo development in terms of coding is code complexity. That's something I learned when a former employer laid off everyone but a skeleton crew. It turned out that lots of factory methods and complex class hierarchies were necessary when we had over a dozen people working on things, just so work could be split up a dozen ways. When there were only four developers, it was easier to mantain with one or two classes with straight constructors.
I love working solo because I get to do everything. And I'm in touch with every aspect of the code. When something breaks, there's no ambiguity about whose fault it is. I don't work on a project unless it's of strategic importance. And I set my own schedule.
Another way to put it is that more important than how big the team is who is on the team. One bad apple can really ruin things, or one great person can make it all worthwhile. Working as a solo developer doesn't mean I avoid great people and bad apples-- I'm still on a team, just not a development team-- but it minimizes the chances in either direction.
This kind of article is the reason I read this site.
A great peer gets you up much faster and actually makes work more enjoyable.
I totally agree with can't program with no internet connection. Nowadays, programming with no internet will surely cripple me because programming has become so big and complex in library/API that you can't know it all.
Working alone risks writing code that goes off a cliff. I have done this putting in many hours, turning it over and realize that I missed some fundamental error or the UI just stinks in practice. It always helps to get another opinion.
Having someone to talk through ideas that has similar or (preferably) better skills than I do is always helpful. Coding in a box by myself is generally successful, but I'm always successful when I have input from other developers. It never hurts to have some feedback in my opinion.
I also like having my own space to work in that is separate from others so that I can concentrate without office chit-chat interrupting me. We have a common area where we can discuss designs and such at my office but everyone has his own office for actually working and that seems to work for me.
Shamelessly off topic:
That "desert of the real" reference was sparked by the "no one can hear you scream" reference in the blog post you quoted, right?
exactly my point!
."Code is my domain on this team. I figure out how a task needs to be done, I write the code that implements it. Ryan is the design guy. He knows how to make things look good almost instinctively. I may give minor suggestions, but that is his realm. This works out great for us."
What was perhaps my most successful project ever worked like that. But that was 11 years ago with VB3/VB4 and Access - many things were simpler back then for a lot of projects in my domain (Windows development). At that time I didn't need a lot of help with VB3; working with another coder probably would have actually slowed the project down. That's really not the case for me with .NET in 2007.
Also, these days so many things can be done 3 or 4 ways now, so even if I was responsible for a design and felt good about it, I always would want to ask a peer or two "is there a better way? what do you think?" So for me now, its team (small team) all the way.
Now if someone is a mISV using Delphi or Foxpro to build targeted business applications, I can see that for certain projects where these tools still have enough breadth to satisfy the requirements, developers leveraging their many years experience on these older, less dynamic platforms could get work done very quickly.
But there is another aspect to this paradigm, one that was alluded to in your post. What if your co-workers create more overhead than they alleviate? Or if their skills do not complement yours, or if you feel like your standards and work ethic are of a much higher degree than these people? You are forced to either pick up sthe slack, sprouting gray hairs (the ones that don't turn gray will fall out, dammit) as you bust your ass to be able to say you are proud that you worked on this project. This can only go on so long. Do you seek work elsewhere, or do you try to instill these traits in them?
Lead by example, I say. Don't fit in. Hopefully, those who are doing what it takes to "scrape by" will take note of your exemplary performance and will aspire to achieve the same level of quality and pride in their work that you have demonstrated. This would be ideal. Things drag on, though, and you find that you are becoming more stressed, unable to concentrate on your tasks. Double-checking others' code as it is checked in to make sure that they didn't just shit all over your work. If management doesn't recognize the discrepancy here, then you must leave. Either to find another job where you could potentially be thrown into the same situation, going bald in the process, or better: create your own operation, work by your standards, and hire people who support your vision and will help you be successful. Sounds easier and more fulfilling to me.
On another note: Jeff, I always look forward to your thoughtful and enlightening posts. Thanks for giving me things to think about (other than my damn job!). :)
funny I read this post now because I was thinking a couple of minutes ago about the project I'm working alone on and I told myself "it's hard to resist to the temptation of gold-plating the code..."
Working alone is bliss sometimes but it requires a lot of will to refrain yourself from not making over 10 times the same piece of code.
Just like kids, you gotta let go the code and let it live is own life I guess..
Working in a small team with cool people has been a good experience I've had and I really enjoyed it but it's all thanks to the fact that everyone had a clear cut assignment. I'm no genius but countless are the times where I would be like 'ewww... what the..' as I'd checked other coders' "thing". As someone said earlier in a team we all share the blame when the project gets delayed, which is fine... provided you're part of the guys who are the most responsible for the delay! Getting blamed for other people's mistakes and/or lack of skill doesn't happen when you're alone :)
I'm working on my own, and was just sitting here thinking I'm bored and who do I know will go to pub with me at 12am on a friday...no one their all at work.
The moral is I can do things that I can't do if I worked for someone, but have to do them on my own.
I don't think programming solo does particularly effect my project negatively, in fact I would say the opposite. In all the companies I have worked their is legacy crap, process crap and bad design crap that ALWAYS negatively effects the project I'm working on.
Further more I'm able to put effort into things up front that I know will pay off in the end result, something that is often difficult to do in a company/team environment.
Yes it would be nice to have someone knowledgeable to bounce ideas off but it's not that much of an issue.
When you work on your own you do have to take more responsibility, if this scares you, then maybe it is 'easier to hide in a team'.
solo programming not bad at all,you can managed yourself when you must work and when you must rest, I think programming like art it need to use your mood too. and it easier to control your mood if you work alone. work in team not always the best, remember it like to fix multiple head and ambition in one glass, sometimes it suck.
In my experience team development is more productive than solo programming. I have been through many situations where I am stuck with some problem and people around me could pull me out in couple of minutes. You learn a lot in a team, some times how to do things, sometimes how not to do.. the percentage of each depends on the kind of team you are in, but nevertheless both are good learning which you can’t get if you are going solo.
1. The effectiveness of communication is inversely proportinal to the size of the team.
2. If we are talking about software development (coding, testing new ideas etc.), I prefer working alone. If it is about the whole process, like following standards, checkin, labelling;Yes, we need a team effort.
I am not sure I 100% agree here. On one hand, yes a massive software project with over 500k lines of code cannot be handled by one developer alone. It's just humanly impossible. It's also silly in this ultra-competitive world that we even attempt to compete on that level.
HOWEVER, Most awesome software products we use today all started by one guy (or gal) who put their heart and soul into every line of code. Just try to think of a couple of your favorite apps and then research its founding. You'll be surprised by what you find.
I think starting a project from scratch can best realize its full potential when one developer takes its reins, gets it on its feet, and then brings in others to fill in the gaps.
Unless however that project is very small, such as a utility app (or script). In that case, bringing in others on it will just make the tool bloated and useless.
I am a freelancer/small-business owner and allthough I have to do all the coding by myself, I have friends that are in the same boat, and we chat, fairly regularly, this gives us the opertunity to bounce-ideas, correct, and help eachother, we often share code and check eachothers projects that we are working on. I enjoy working by myself but without this group I dont think I could have possibly have gone as far as I have. Working on a team is great if you have the right people, you have to get along and compliment eachother but you also have to be able to critisize each other. I have one partner for example that is posibly the best front-end guy out there, but he is not so great with the back-end stuff, or the client relations, that is where I come in, I will work with the clients as well as do the behind the scenes stuff, and this works for US, but it wont work for everyone.
Dear Jeff and Friends,
To get back to the point, ONE is The Strongest Number.
All the efforts of "Software Engineering" have been to towards the goal of being able to add more people to a project to increase its productivity. These have all failed that is why new development models are emerging all the time.
Yet the most public and successful project of all time has to be GNU/Linux.
The lack of acceptance of this spectacular and most public fact is the most revealing aspect. It leads an honest programmer to question the true motives of those behind the debate.
A cynical man might deduce that they are motivated by money and not engineering standards.
I read all your comments with interest. Nobody seems to have mentioned what it is like to be hired as the second developer for a small company where the first developer was quite happy being a lone wolf and was beligerent about code being written his way.
In the last three months I have learnt nothing from this guy who communicates in grunts and shrugs and I have had every bit of code I wrote rewritten, behind my back.
I know programmers have never been known for their communication skills but this has been a real shock for me. After only three months I am resigning from my first graduate job. At least I know what to look for in my next job, a company that has developers that can actually work with other human beings.
Because programming is as much art as science, you would think that committees would produce better artwork than individuals.
When I code alone I do control the process. And I don't have to explain myself in code reviews, I don't have to build long complicated documents describing interfaces and making powerpoint presentations about the division of labor. I sit down, start coding, and get it done.
Of course I could cheat and not make good code. I could hack away at it and munge it up so nobody could modify or maintain it. But I don't do that because I have pride in my work and a long lifecycle view. Working with a bunch of other people looking over my shoulder wont fix the lazy, it just makes them lazy AND devious.
While all that may be true and you'll get the job done, but you're ultimately restricting yourself to your own experiences and thoughts.
That might be good enough for you, especially if you're working on "safe" projects. My thoughts on the matter are something like this: Why go through the painful process of making big mistakes yourself when somebody else has already made those same mistakes and learned from them?
Yes, sometimes you'll have to filter the rhetoric from the true wisdom. But inevitably, from working with others you *will* learn new and wonderful things without having to go through the agony of making those mistakes yourself.
I'd agree with Jeff's sentiments, which many of the comments posted so far seem to miss the point of:
Yes, it's possible to work on your own.
Yes, it's possible to do a good job on your own.
Yes, it's even possible get your work done on time in a productive and efficient manner, perhaps learning a thing or two along the way.
But there's a significantly reduced opportunity to *learn* by working on your own. I've been a loner for most of my professional career and I've been craving the experience of working with a real team of developers who know their stuff. People who can potentially lift my software development game to a whole new level.
It's only recently that such an opportunity has come along, and I'm already excited about it. Those of you who have always been loners too but say you're doing "well enough" ... that's fine if it works for you but if you have any hunger for professional growth, you'll almost certainly find yourself wanting.
In my personal opinion, that's the difference between being a "good" developer and a "great" developer. It depends as much on the people you work and their willingness to share their experience as it does on your own ability to learn and adapt.
My two cents :)
All the efforts of "Software Engineering" have been to towards the
goal of being able to add more people to a project to increase its
productivity. These have all failed that is why new development
models are emerging all the time.
From a business perspective you maybe, kinda, sorta have a point.
Methodologies come and go. Software development is still as much art as it is science. We're still feeling around for what might be a methodological silver bullet. This may very well be a fruitless search.
But to deny yourself the experience of others is, in my humble opinion, professional suicide. Which is how I interpreted Jeff's article.
Yet the most public and successful project of all time has to be
With all due respect, if you think Linux was written in a communication vacuum with no sharing of knowledge ... you're stark raving loony :)
I have just read your comments and I decided to post my own one.
It's more a question to you.
I'm just to finish my IT college (C# programming and project management).
I started with programming (assembler for c64) earlys 90's.
Later on few ears C++ and last two years C#.
I have never worked in a team and I probably wouldn't know how does it work. So far everything I wrote I have don myself. Even my last project - and first really big one for me http://www.mariuszzaleski.com/pc.en.aspx - first on the list (I didn't pay attention to put enought info or screenshoots there)
I do myself as well. It takes a lot of time but I don't imagine how it is possible to do that with few people, if you know what I mean.
After college I will try to use this project as some king of my portfolio to get nice C# developer job, hope it will help.
I just don't know how to prepare myself to work with others on this some project. Maybe when I finish a project management part in college it will clarify a bit my not so good picture of working in a team.
I will appreciate if you write something about a team player role.
How do you share a work and how do you join it together later on.
Thanks for reading my post.
Lots of greets
Great comments so far. I'll add one more thing.
Being a lone problem solver is something that most programmers are *naturally* good at, so they don't need any additional encouragement along that particular axis.
I don't want to devalue working alone, because it's absolutely an important part of the effort. But so is working with other people.
I've worked on teams and for now I am working alone, or at least virtually alone, and I have to say that I'm pretty much enjoying every minute of it. Occassionally I get bored and I wander...which is where the above article has some good points about accountability. Other than that I have the "hive mind" as you call it to ask questions from, bounce ideas off of, find examples, etc... Rarely the guys sitting next to me can add more to what I can find off the internet. Still sometimes having fellow coders to bounce ideas off of is great, but more often then not fellow coders tend to be a pain. I've met some great people programming, I've also met some real freaks, I think the last two teams I was on burned me out and disillusioned me about the whole team dynamic. So I guess ultimately it depends on who you are and who you are working with. If you are working with a talented, open-minded, humble set of individuals then by all means hang in there and both teach and learn all you can while your team makes great product. If you are stuck working with a bunch of freaks you are better off on your own.
If you are stuck working with a bunch of freaks you are better off on your own
Or, find a better bunch of freaks!
I did some work with proverbs as an independent study at school a few years ago (before getting into database design and some Net programming), and this blog is about the tension between contradictory truths. Specifically:
"too many cooks spoil the stew (or soup or whatever)"
"many hands make light work"
They're both true, just true in different situations. Multiple people can accomplish more, but only if they can work together, they all know what needs to be done, they have the ability to divide up work smoothly, etc. Otherwise multiple people working together just get into each other's way.
I wish more teams like that existed, but the grim reality is that when I work alone at home on projects for clients I have process, I have source code control, I have a bug tracker database, I have unit testing, I have a secure, stable PC with virtualised test environments and all the tools I need for the task at hand.
When I am at an office, even as part of a development team, I consider myself lucky when I can get permission to use source code control. Usually I am forced to work on a crippled PC with no development tools and I have no access to test environments.
How do I fill the vacuum? I read books (and quality websites like this one).
Fantasic post, and it came quite timely for me. I've been the sole developer for the same company for the past 12 years. Along with that title, I've also been the sysadmin, phone guy, security guy, fill in the blank guy. My crave for working with other developers has reached the point of breaking my sanity. To sum it up, I'm tired of being the smartest programmer in the room.
So when I started listening to Hanselminutes and DNR I began to realize that there was this whole other world of developers out there that were WAY smarter than I, and at that point, my faith as a developer was renewed ten fold. I had read your blog a few times here and there, mostly when Hanselman referred to it. But it was your podcast with DNR that really stuck a cord. For the first time I was listening to someone else tell a story about being tired of not having any peers to share their love of computers with, about not having anyone care or understand when you were dying to share something completely awesome (and after listening to that podcast, I ran out and picked up a copy of Code Complete 2.) So from that day I began to realize that there are other developers out there that honestly share the same passion for computers and programming that I do. This became so exciting to me that I've made the decision to find another job that will allow me to work with a development team. While I don't feel that the past 12 years of being the sole developer were a complete waste, I DO strongly feel that I've done a disservice to my professional growth as a developer and that I've missed out on some great comradery with people of the same cut.
Many people seem to think that working solo is best, and perhaps that's fine for them. But what I have to wonder is are those people really able to turn out top notch 'usable' software that doesn't make the user think? I highly doubt it. And are those people really growing professionally? I sure didn't. My role as a sole developer has not produced software as effective and usable as it could have been. If I just had someone else to share the work with, someone else to contribute ideas, then we could have developed something truly grand; and I'd be a better developer for it too.
So there's my goal as a developer who has just opened his eyes to the larger world. Find an awesome team to work with, find smarter developers to work with, and really discover where my potential can take me. And for anyone else stuck in a similar situation, don't let being a sole developer close your view to and interaction with the rest of the developer community. Furthermore, if you're in the role of sole developer and were the other hats of sysadmin, phone guy, security guy, etc guy - SERIOUSLY think about finding working somewhere else where you can be a developer full time. Those other hats will eventually hinder your productivity and may even leave you wanting to stop programming altogether.
Yes, I was the sole developer in our office in my previous employement. Glad to be out of it, and working in a large software development team again.
Found out the hard way, that the Peopleware quote was true; "The major problems of our work are not so much technological as sociological in nature"
"The major problems of our work are not so much technological as sociological in nature"
so true I worked with biggest bunch of deeply arrogant conceited a**holes ever
I am an independent contractor. I work at home for one client who has many clients. There is one other Web Developer who works for my client. If we were to be considered a company, I'd be the Senior Web Developer. But both of us work primarily alone.
If it wasn't for the internet with its wealth of information, 24x7 Books and Safari Books, I'd be in a lot of trouble trying to work on my own.
I am trying various things to get to be with other developers, such as a PHP Meetup and taking classes at the local Technical College. The problem with the Technical College is that the course work for programming isn't that challenging for an experienced developer (25+ years of programming experience). I will be looking at other inexpensive coursework that would get me out with other people.
The biggest problem I have, which I'd probably have to some degree in large company, is that with the amount of experience I have, it isn't easy getting help in the areas I'm not as experienced in. I don't need to be led through the basics of the area I need help in. I just need to know, "What can I be doing differently to make use of the newer technology more efficiently?"
One can do both, probably at different stages of the life, start in a team and later on do your own stuff. An other thing to consider is if you are employed by someone or self employed or even an employer (you do the main job and some others, payed, do the rest)..and also if you work on a commissioned, defined project or you make reasearch, eperimental projects. I mean...it's not that easy to find a general rule..
Hey, just thought you might like to look up the term "anti-social" and compare it with "asocial." It's big.
I didn't read the full post above, however I see that the subject here is if its worth being the sole programmer of a project.
I am the president of an electrical controls company and do minimal administrative work for this company as we have opened a high tech division. I am designing electronic devices which involves electronic circuitry, C processor programming and later some VC++ for the PC side. The devices will be able to communicate between themselves and are innovatively modular. All this to say that its been four years that I am working on this *alone*. I will admit, at times it gets very stressfull based on the many points that have been mentioned by all fellows that posted their opinions above.
However, the personal satisfaction I get back from all my hard work is priceless. I think it comes down to this, if you are extremely passionate about technology, I believe working alone is the way to go. For example, I may be watching TV and an idea comes up which merits to be integrated in my project. I run down to my basement lab and one half hour later, that idea is electronically designed, built, respective programmation is coded tested and documented... where else can anyone get this type of effeciency and personal gratification?
If I were working with a team, my idea would have to be presented at a meeting bywhich would be further challenged and contested by my fellow teamates and I would probably walk out of this meeting with 25% of the original idea. The 75% that would be altered from my original idea *might* have a positive impact on the overall project, but this often dillutes your personal drive. I guess it has to do with how much control you want in a project. But lets face it, when a prgrammer has a vision, it is the personal satisfaction that he gets from it that makes coding fun.
I am one of the unlucky person who has been programming alone for quiet a long time.I assure you what you have said is true.
This is very true. Working alone can be a relief in some ways, but all those hats start to get heavy after a while.
I think a team of 3 talented developers is the best, at most 5. That way you get to share the workload and bounce ideas but you (generally) don't have endless distractions and conflicting visions.
Of course, good luck trying to build a team like that. If you're a micro-ISV, people are apprehensive because they fear for their job security, and if you're in a business sector, the offer from upper management is rarely attractive enough to get the attention of talented prospects. And if you're in a software shop with 50 people, you've already lost that battle.
So if you can't get the so-called "surgical team", then which is the lesser of two evils? I honestly don't know.
From my experience, the ideal is a small team working closely together - at least 3 people, no more than 10. Enough to get a good variety of experiences and ideas, not so many that they're all getting in each other's way - both in terms of code changes, and idea conflicts. And 10 assumes pair-programming - I'd say no more than 6 or 7 if they're all coding independently.
Working on a team isn't always that big of a change. If/when you start to work with a team the one thing I can suggest is to look at how your teammates code or do design work. It might take some time and you learn to work with everyone to produce great work. The biggest thing though that I think comes from working with a team is you can sometimes ways to make yourself a better programmer by looking at the ways that other people work.
Also something I was thinking about asking how to you work together and join it together later one. I would say Source Control is probably the easiest answer to that. It is good to know that you can have multiple people working on the same application in different parts. Sorry it is kind of all over I have way to many things running through my head at the moment.
BTW, the last link is broken--is there anywhere else I could find your reference?
I am the sole software developer for a small company. In the past, I would have agreed with your article if I was developing in a language such as Visual Basic of C++. However, I'm developing web applications in Ruby on Rails, with test-driven development, and I couldn't be enjoying it more. I use a great open-source project planning application called 'retrospectiva'. I also have regular meetings with my boss (code illiterate) where we plan out the development iterations and prioritize features. So there definitely CAN be a "process in a team of one".
P.S. test-driven development isn't just for Ruby.. check out http://www.slideshare.net/amritayan/test-driven-development-in-c for C developers, or http://www.devx.com/vb/Article/21529 for VB developers. It will change your life :)