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