I went a little too far generalizing like that. What I really meant is that sometimes you need to do things that were not part of your job description. I have been a manager and an employee, and I am aware that you have to know what kind of personalities the players of your team/teams have. That being said, and in answer to your initial question, they should fix their computer if I tell them to, or hopefully without me telling them. We can have a whole another thread about contracts. I think we started talking about something different than your original question. :) Also, I am not a free-lancer. My average stint with a company is about 2 years, so I have been working in teams for a long time :) Di

I agree with you. I might have generalized too much just like the title of the thread :) Nice discussing it with you. Di... out

I am not a .NET developer. However, it is a tool. Just like you have a hammer, drill, and a screw driver. A language is a tool, rather than a law you live by. You use whatever suits the project and will yield the most elegant solution. That, however, is by itself a thread so I will cut it here. You are also wright that I would know exactly only if I recognize the error. Most of the times thought you can see an error an you can estimate how bad it is. That is all it take me to know, that if I have to fix it, I need to let others not that it will take that much additional time, or call a tech to fix it and ask him to bring me a laptop so I can keep working. I respect your opinion and I believe that developers should know how to fix their machines, but should not fix them unless it is cheaper, time wise, to fix it than to call a tech support to handle it. Purely cost-benefit analysis.

Ok I think you are dead wrong on that one. Bossed can delegate, but if I am your boss and you call me every time you have a small problem, you are wasting my time. There are a lot of caveats here. -size of company -culture of the company -what do you mean by boss --dev manager or an owner ---If you are really small, job description don't matter and the boss is trying to build a business, which involves more than just dealing with a bunch of developers who say this is not in my job description. That is why start-ups don't hire such developers, or at least try to avoid that. ---If the company goes to 20-30 techs, they will have dev managers with maybe team leaders, depending on how it is structured. Still within your team, you can't just say "when you guys hired me you did not say I will have to do this." ---Don't get me wrong, I am in for money and I don't accept people screwing around with me and passing me work that is not mine. However, I am talking about stepping up to the plate when it is needed to get the job done. That is what I pay top dollar for. Are you trying to say that my boss will be unhappy that I troubled him with one less problem? I have been up in the chain and an employee. If you can't handle being a boss, can't say developers do this or that. "I suck because they do too much work and don't bother me with it" - that just seems like crap to me. I think this can only be discussed over a beer.

I am a self-taught developers, I have done research, developed algorithms, and dealt with math most people, even some math teachers, will not see in their lifetime. Please don't attack the the self-taught developers. I stand behind every line of code I write and every architecture I design. What is hilarious about the threads on The Code Project are generalizations. What's up with all the bashing? Also, just because you can fix a car, that does not mean you always will. If you are a racer, you know enough about cars to fix them. You probably grew up doing that. Nevertheless, you will not jump out of the car in a middle of a race to fix it. That is why you have a team that you trust. Unless, it is something minor which you can handle quickly and go back in the race, you will not touch that care. Plus a racing vehicle is hardly your average one. Your knowledge might not be applicable to that vehicle. In addition, you can research, but you cannot beat that car engineer in the team. I have been reading this thread because I find the topic interesting, but I think we generalize a lot and by developers we actually mean the bad developers. The subject should actually be "Shouldn't bad developers learn how to work with computers?"... In those lines...Same with the developers. I am really sorry that you guys have to work with incompetent people.

In small companies there are no unreasonable expectations. Developers who hide behind the contact are in most cases lazy, or don't think it is there job.

I definitely see your point, but I don't think the problem is with developers in general. I think you should fire those guys and hire somebody who can handle the work of a small company. I started in a small company, and I know what you are talking about. The company just did not hire the right people. I still stand my point too. Good developers can fix their computers, and most of them like myself do. However, with my experience and knowledge, and I am sure this is true for most developers who really care about their art, I know how much time it takes to fix a particular error. Thus, if it takes too much time. I rather call a specialist, in this case a tech, again in a mid-size company, and let him handle it, while I borrow another computer to continue developing. No product developed, no company. Next time when they ask you to fix something, do what should be done... let them suffer until they realize it's time to learn... and learn quick. Change or die. Simple. I am not arguing against you, just arguing against generalizing developers. :)

I assume your are a support tech. Please forgive me if I am wrong. Developers do know how to fix their computers, the competent ones, but it is not cost-efficient to do it. If you are a tech you can probably program in one or two languages. However, a good full-time developer cranks many more lines than you a day. On the other hand, while he is doing that, you fix many more computers. Even though a programmer can fix his computer, he knows, or at least I know that my techs can do it faster than me. I am sorry if you are working with incompetent developers. But, even a good one would not waste his time with fixing a blue screen unless from experience he knows that it is faster to fix it than to call you. The difference between a bad developer and a good one is that the good one will use that time to work, no excuses no complains, and a bad one will go tell the manager that the techs messed it all up and the cat eat his source code. The programmer and the tech should act as a team. The Programmer makes sure the code is as close to perfect as possible within the time constrains, so the company is profitable, and the tech makes sure the programmer can do that without any distraction. It's called team work. I am sorry that you guys have to work with people who don't know what a shortcut is and such. They really need to asses their careers. However, please don't generalize. Respectfully, Di