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

I am the only developer in my company. I do programming (in ASP.NET 4.0, jQuery and SQL Server 2008) and maintain the database and web server (win 2008 r2).

I enjoy the freedom of implementing what I like at the same time I feel I could be doing everything in a bad way. I don’t use any SDLC diagrams not any kind of methods like Agile etc. I handle multiple small projects. I use my free time in keeping up with latest technologies and learning and testing new stuff. I have been doing this for the past 7 years.

  1. My concern is how difficult will it be for me to adjust when I switch my job to a company wherein more developers are involved in a project?
  2. Since I don’t follow any design pattern would it play against me when I look for job or get adjusted with new job?
  3. Any other pros/cons you can think of?
share|improve this question

6 Answers 6

up vote 5 down vote accepted

If you like this situation with it's freedoms it is likely you will dislike going anywhere that views this as a problem (having jumped this fence I know I do).

It actually plays in your favor on future jobs because you end up with a much wider skillset than 90% of the people out there.

The lack of someone to argue with about pro/con decisions is a problem as Pierre describes (+1 for him), but a college in another company that has the patience to listen to what you are trying to do and enough interest to have a strong opinion serves this role nicely, sometimes better than a co-worker because they are an outside point of view. (I still do this even though I work in a bigger shop now, it helps me keep up on what others are doing to solve similar problems and see future issues in the design)

The one other issue I had when I was the lone dev was that their was nobody to back me up when it came time to really fight a bad direction from management. Your mileage may vary, but if you are the lone dev and all of the management is non-technical it can become very difficult to explain why you should or shouldn't be doing something and very tough when it comes time to tell them their latest dream is not reasonable to try to implement with current technology.

share|improve this answer
5  
The other issue with being the only techie is when you've got a high fever and severe nausea and the web server goes down. One hopes they've got a backup plan other than bringing a laptop to the hospital if you get hit by a bus. –  David Thornley Apr 29 '11 at 17:16
    
That is an issue, but it is often an issue in sizable companies as well once they spread their resources too thin. –  Bill May 2 '11 at 17:35

When you are alone, nobody can tell you are wrong

So you may go in the wrong path, for a while, without even knowing.

For that reason, I encourage you to find someone you can talk with about development. Not only online, but in real, physically.

No need to quit your company. Being the only one has some advantages too.

share|improve this answer
3  
This is fantastic advice... –  webdad3 Apr 29 '11 at 15:30
    
Thanks ...!!! Apprecite your advice –  bp581 Apr 29 '11 at 16:02
2  
Key word is "may". If a developer makes a conscientious effort to stay educated on the various technologies and methodologies, and more importantly the data surrounding them, then there's no reason to believe he'd be doing sub-par work. Of course, developers who work in a vacuum and just stick to what they know are probably making themselves progressively more obsolete. –  Aaronaught Apr 29 '11 at 18:30
    
Agreeing with Pierre here, two developers can produce [code or db or whatever] far better than either could individually]. The benefits increase with more devs but there is a diminishing return. –  Puddingfox Apr 29 '11 at 19:15

I have worked as the only developer at a company who knew a specific technology, as the only one who did the type of programming I did, and as a contractor in similar situations. (I've also worked in team environments with other developers who knew different tools and with other developers who did exactly what I did.)

Pros of being the only programmer

  • As you mention, you frequently have the freedom to use whatever tools or languages you feel you can learn. You don't always have to make a case before your peers to get permission to work with New Technology X while everyone else is using Current Technology Y.
  • You have more responsibilities. Essentially, you function as both project lead and developer on each of your projects, and with your ability to identify and implement new stuff, you're effectively the department head as well. (Don't tell salespeople this. They love to talk to decision-makers, and you don't have time to talk to them.)
  • There is no question about credit for the work that gets done: it's obviously you and you alone who made things happen.
  • You can spend more time actually working on your own projects and less time in meetings about projects that are basically someone else's (but you're there as a support person, possible backup, or whatever.)

Cons

  • As David points out in a comment, you are the only developer, so no development gets done without you. I once bragged to my brother that I was "the guy" on a particular project at work. He accurately described my situation for me: I was trapped. I couldn't move on in that company because I'd never be able to get rid of that project. (He was right, too. It took several months of training over an extended period of time before I could hand it off to someone who was even somewhat capable of supporting it.) You may find it difficult to take a true vacation when nothing can be done without you.
  • As Pierre points out, there is no one on site to do code reviews or share best practices with you. You can reach out to peers in various ways, but nothing is quite as effective as tapping a coworker on the shoulder and asking her to look at your code for 5-10 minutes.
  • In a similar vein, you may have difficulty getting experience with new tools. Offsite training may be as rare as vacation time: someone will complain that the company can't afford to have you off looking at Language 3.0 for a week when there's no one to keep the Language 2.0 apps working.
  • Career advancement can be extremely difficult to manage. You may not have a position for which you can strive, even a change in title may be difficult to gain, and end-of-year reviews don't have any frame of reference, so excellent work may go largely unnoticed if for no other reason than that no one really understands what you do.

If you decide to move to a company where you would be working as part of a team of programmers, I don't think your solo experience is likely to hurt you much. Your lack of experience with design patterns isn't necessarily as important as your willingness to learn them. (There may be situations where you're interviewing against a candidate with a similar background and also experience in whatever methods that company uses, but that is true of basically everyone.)

Along the same lines, your lack of experience on a team is balanced by your ability to wear many hats. There are some developers who are good team players but never develop the ability to manage a project; you've already shown that you can do that.

I would recommend that when you are a solo developer, you should spend some time reading about tools and techniques that similar developers are using, so even if you don't use them yourself, you're aware that they exist and you can refer to them during an interview, even if only to say "Yes, I've read a little about MVC frameworks, but I haven't used them myself." Do what you can to stay in touch with other developers: go to local user group meetings, read and comment on blogs (or keep one of your own), try to get to workshops from time to time, watch webinars and such. (You might also consider sites like lynda.com for in-house training: it's not as good as a week-long conference somewhere else, but you can watch the videos on your own time and not send everyone into panic mode because you're out of the office.)

share|improve this answer

Your programming skills deteriorate every day you are in this type of situation. Coding is the easiest part of any programmer's job.

Communication / working with a team to implement a solution is infinitively harder. Those skills can only be sharpened by doing it. Also when you are part of a team, most members are trying to keep up with technologies just as you are, so the chances of the team finding something great are that much greater.

Please dont take this as an attack on you personally. I also am a lone programmer, but looking for a team asap.

share|improve this answer
    
Developing alone means you miss out on the 'cardboard programmer', which is often a useful tool. Basically, having someone else to explain a problem to often means the solution presents itself mid-explanation (before the other side has a chance to make suggestions) –  Phil Lello Apr 30 '11 at 14:38

I agree with @Pierre 303 answer 100%. I would also add that you should take it upon yourself to teach yourself the proper practices. Maybe a certification would also help too.

Yes if you switch jobs it will be difficult... Not only if they have processes that you aren't currently used to, but also with personalities. Programmers are notoriously competitive. You don't have to deal with that right now. But you will when programmers >= 1

It sounds like you have a good gig... I would hold on to it.

Just my 2 cents.

share|improve this answer

I think you're missing the fact that most of the standards/practices you'll find in a large development house can be applied to your situation easily. Making these adjustments to a one person team has been covered before on SO. Search around a bit for guidance:

How to apply agile to personal projects?

share|improve this answer
    
Thanks for the link ...!!!! –  bp581 Apr 29 '11 at 16:02
    
Is there any link to find the complate sample project using all the methodlogies like SDLC, Agile...etc ? –  bp581 Apr 29 '11 at 18:00
    
Don't get too hung up on words like 'Agile' and 'Scrum'; their just formal definitions of the methods successful teams were already using. However, they are useful if you haven't been lucky enough to work somewhere where it's a natural part of the environment. –  Phil Lello Apr 30 '11 at 14:40

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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