28
votes

In my experience, software developers tend to wear multiple hats and fill multiple roles with different responsibilities. From not only coding, but sometimes also writing SQL, designing the user-interface, designing the database, graphics manipulation, to even QA testing.

If the primary role is to write software/code, what roles should the developer not take on? Are there any?

The intention of this question is not because a developer is incapable of filling another role-- but having the additional role actually works against the primary role, or should really be a dedicated role of someone who does not primarily program.

10
  • 20
    A bonnet... oh wait.. Sep 29, 2010 at 17:46
  • 21
    IMO a programmer should not wear one of those big Mexican sombreros, because the brim would keep banging against the monitor. Sep 29, 2010 at 20:36
  • 1
    @Peter Turner: The 'awesomest programmer hat' would be one of those novelty jobs that mounts two beer cans. Only, no beer. Red Bull.
    – BlairHippo
    Sep 29, 2010 at 20:48
  • 4
    Damn. Such a promising title...
    – Nobody
    Sep 30, 2010 at 14:59
  • 4
    @Mason, keeping the sombrero over the monitor will shield against reflections in glossy screens. In other words - technique.
    – user1249
    Nov 2, 2010 at 22:12

19 Answers 19

53
votes

Sysadmin. Developing software and handling the IT infrastructure are two different skillsets that look similar to an outsider. (It's all just banging on computers, right?) For a smallish company, the temptation will be very strong to make The Computer Guy responsible for all the machines in the office.

If you have the skills to actually wear both hats, awesome; but it's one of those things that can be a much greater time sink than people realize, and if you're self-teaching as you go, chances are you're not doing it very well.

9
  • 7
    THIS. Seriously, just because I work ON computers doesn't mean I can fix infrastructure. You're just wasting your developers' time. Sep 29, 2010 at 20:06
  • 5
    +1 the damage that can be wrought by an amateur sysadmin is enormous. Sep 29, 2010 at 21:36
  • And if you get the sysadmin hat, they may stick you with the facilities manager hat too which is to be avoided at all costs.
    – HLGEM
    Oct 7, 2010 at 14:52
  • 3
    OTOH, I work in a company with an incredibly incompetent and sluggish IT department. What I wouldn't give to just be able to make my own firewall changes... Dec 3, 2010 at 18:47
  • 1
    Someone pointed out that my boss was not dressed up, but told them he would be getting dirty from the floor setting up computers. They pointed at me indicating I should be doing it. I almost jumped across their desk and strangled them, but I sipped my coffee and mentioned that I don't do hardware.
    – JeffO
    Jan 28, 2011 at 0:46
34
votes

You wear whatever hat your employer asks. That's what makes you a team player. That's what makes you a Problem Solver.

People get way too caught up in the idea of being a "developer" or an "architect" or an "analyst". Screw that. You should be a problem solver. Code is just a tool in your belt.

Problem Solving never goes out of style.

If my employer wants me to do tech support or build computers, so be it. It think they're wasting their money, considering a developer salary, but that's their business. I'm here to solve problems. However I can do that, I will do it. And if I feel like, after a certain amount of time, my talents are wasted or my job satisfaction isn't where I want it to be, then I have just a much of a right to move on to another job.

But to the basic question - there isn't a hat you don't wear. Heck, if they want you to fetch coffee, do it. Solve their problems; just know that you have the right to find another job if you desire a change.

18
  • 5
    @Josh: I think that'd be one of those "find a new job" situations.
    – Adam Lear
    Sep 29, 2010 at 18:50
  • 21
    Just be careful with this. Bosses tend to take advantage of those willing to do anything. Just make sure you are being compensated correctly.
    – Tony
    Sep 29, 2010 at 19:51
  • 5
    I don't think Chris is quite saying "do anything" (well, he is a bit at the end; I wont fetch coffee for anyone that doesn't fetch me drinks too), but saying "I'm a developer, I wont change a printer cartridge" is just being snooty. Sep 29, 2010 at 21:56
  • 10
    I disagree. It's easy to say that a developer should be able to do anything asked but that doesn't mean he/she SHOULD. There are some considerable conflict-of-interest problems that arise in these situations. I don't want access to production systems because I will be blamed when they go down ("oh, well XXX was in there last month, so I'm sure he messed something up cause he's a dev, not an admin")
    – MBonig
    Sep 29, 2010 at 22:11
  • 7
    -1; there's a kernel of truth here, but there are some stark limitations to this mindset this answer doesn't do enough to acknowledge. What about when the true underlying problem is that your employer sucks at personnel management? I once watched an office collapse because the higher-ups insisted on shoehorning intelligent, capable engineers into roles they hated and did very poorly. There are times when saying "No!" is the best thing you can do for both yourself and your employer.
    – BlairHippo
    Oct 7, 2010 at 15:01
29
votes

Tester!

Please send us testers straight out of tester school if need be!

Without testers people expect everything to work off the bat because the programmer is the tester and they're very smart so it should work.

I'm not saying dogfooding isn't a good idea. I just think testers are very important now that I'm a programmer.

9
  • 4
    Good dedicated testers are definitely under-rated! Sep 29, 2010 at 21:57
  • 3
    Dogfood!? I only cook up five star lobster!...and thats why I need a tester to tell me when I screwed something up. I made the thing and know how it works. No one who made a UI is ever qualified to test it thoroughly, simply because they know how it works, not how it works with someone who doesn't. Sep 30, 2010 at 5:43
  • 15
    There's nothing wrong with being a tester in general. It's wrong to be the only tester for YOUR OWN code. Programmers code with a set of assumptions in mind, and if the tester has identical assumptions, they won't exercise unexpected parts, and will miss many bugs.
    – dbkk
    Sep 30, 2010 at 5:44
  • 5
    Testing your own code is definitely a big no-no. A programmer can cover a lot of other stuff, but actual functional testing ( if you're not doing unit testing you may not be a programmer anyway ) of your own code is a very bad idea. Dogfooding with it is good, mind.
    – glenatron
    Sep 30, 2010 at 11:31
  • 3
    +1 - programmers think distinctively different from non-programmers in terms of how to use programs. Would you ever discover a bug in the "File -> Save" menu item?
    – user1249
    Dec 3, 2010 at 17:37
26
votes

You should be careful about becoming the go-to guy for office hardware problems. This can include PC troubleshooting, server admin, backups, and even phone system work. I made the mistake of mentioning my previous hardware experience, and eventually my hardware/troubleshooting duties severly conflicted with my programming duties.

4
  • Tell the culprits that they need permission from your boss, and register all time used for this.
    – user1249
    Dec 3, 2010 at 17:38
  • @Thor The direction to work on hardware stuff -came- from my boss. It was helpful for the office, but I couldn't focus my career on programming as much as I would have liked at that point. Dec 3, 2010 at 19:06
  • @Jon, if the boss says you need to do it, well... you need to do it. You can then discuss with him whether this is satisfactory or not, and if you cannot get to an agreement, it is time to leave.
    – user1249
    Dec 3, 2010 at 20:19
  • +1 The same thing has happened to me. They want me to not only write code but also deal with network issues along with browbeating vendors and that has led to a lot of stress.
    – Rich
    Dec 3, 2010 at 20:23
16
votes

A programmer should not be the only tester for his own code.

Developers write code with a set of assumptions. If testers have the identical set of assumptions, they will not exercise the unexpected functionality outside of those bounds, and many issues will remain undetected.

Moreover, in order to move forward, devs are not highly motivated to try to break things, while testers are (perhaps at a subconscious level).

This does not imply dev testing is useless. Quite the opposite -- good dev testing enables testers to focus on finding deeper issues. However, dev testing is not a substitute for a dedicated tester.

10
votes

Two I can think of right off the bat.

  1. Tech support. I'm not here to help clients work through the new site or teach them how to use features.
  2. While it may be necessary to interface with clients at various points in the process, unless you're a managing programmer you really shouldn't be directly communicating with them about features and design implementations.

You could say that CSS / UI development would be outside of the programming "realm" but in my experience it is a necessary skill today. You can't just get away with tables and depend on someone else to implement it correctly. I may not like implementing design or altering the code to handle a new design, but that is part of the job.

Writing queries is fine, Q/A testing is fine (and IMO should be the job of the programmer, having an external department do it is find, but first you should test it). Server administration is a bit of a grey area. Depending on how large the project is or if you have a dedicated server admin it may or may not be needed.

1
  • 7
    Regarding point 2, there's at least one company who has as a founding principle that the person writing the code should be talking directly to the customer: disintermediation has its advantages. Sep 29, 2010 at 18:31
10
votes

In general, it has been my experience that most programmers should not develop the look and feel of the user interface -- although I am certainly capable of developing a UI (and often create one when building a prototype or proof of concept), this is better left to a human factors person (who in our small company is a graphic artist who also does the screen layouts and creates most of the manuals and brochures).

Also, developers should not be doing QA testing -- that is the job of the QA department (the company I work at makes embedded medical devices, so this is a requirement that the testing be done by a separate department).

On the other hand, I see no reason why developers cannot design databases and write SQL, if they have the background to do so -- I have done so many times.

19
  • 2
    +1 Agreed that QA testing by the developers that wrote it defeats the purpose.
    – spong
    Sep 29, 2010 at 17:45
  • 2
    @JoshK Some QA testing can be done by the developers, but the main QA testing should be done by others. If you test your own app that you wrote, you'll subconsciously walk around any potential problems. The point is to discover problems that the developers are unable to find, a kind of fresh set of eyes so-to-speak.
    – spong
    Sep 29, 2010 at 17:52
  • 2
    @JoshK @ChaosPandion Agreed, some prior testing by developers should be done-- but it shouldn't be trusted, thus separate QA testing by those who didn't develop it.
    – spong
    Sep 29, 2010 at 18:06
  • 5
    -1: I disagree that programmers shouldn't design the GUI. I have worked for 8 years in a small company, and I designed all the user interface. I always followed the excellent design guidelines by Microsoft, and read a couple of HMI designing books. We outsourced to external illustrators only graphics.
    – Wizard79
    Sep 29, 2010 at 18:41
  • 3
    One thing that bothers me here is the implication that a graphics person is better suited than a programmer to design UIs. It may be that your graphic artist is very good at designing interfaces, but in the general case it can degenerate into a confusing, unusable, pretty interface as opposed to the confusing, barely usable, ugly interface you'd get from the stereotypical programmer. Sep 30, 2010 at 17:46
8
votes

Tech Support

So much of my day is wasted by taking tech-support calls...

Some popular ones are:

  • "My account is locked out" or "I forgot my password"
  • "My [phone|keyboard|mouse|computer] doesn't work"
  • "My computer is slow, can you check it out for anything unusual?"
  • "Why does X happen when I click this button? It should be doing Y"
  • "I keep getting these popups...." or "I think I have a virus"
  • "This person is no longer here, can you disable all their stuff?"
  • "We have a new employee, can you set them up with login, security card, phone ext, email, etc?"
6
votes

Any role that makes him manage himself. In small teams, there is often a tendency to make one of the senior developers the project manager, but also keep him in the team as a programmer. This leads to all kinds of problems, since this guy, as a programmer, is basically unmanaged. Instead of delegating all tasks to the other team members, he will often be tempted to assign many of them to himself, especially the most difficult tasks. So the most difficult tasks, those who are most likely to cause problems, are assigned to a person who is only 50% available as a programmer and as such reports to no-one. When other team members are unable to deliver, instead of kicking their ass, he will try to do their tasks, to, because as a project manager, he is responsible for the success and the safest way to get it done is to do it himself, isn't it?

5
votes

Tech support for something you had no hand in developing, deploying, or maintaining, and have gotten no training for and aren't kept up-to-date on major changes. Part of my job has become answering the phone for clients calling about why their internet isn't working. I don't deal with that half of the business, so I can't tell them anything of use.

It's not having to do tech support, that there's no problem with. It's being a secretary/tech support guy while trying to develop things.

It gets quite taxing having to listen to people complaining all day and not being able to tell them anything. I'd advise avoiding this at all costs.

1
  • Yes it is taxing to have to switch personalities several time throughout the day. It's difficult to work on tasks that require concentration when you are constantly being interrupted.
    – Rich
    Dec 3, 2010 at 20:26
5
votes

Sales.

Some poor bugger has to do it, but it sure shouldn't be the developers.

4
votes

As I've gotten older, I've realized that is is best if developers don't do their own deployments (I fought this one tooth and nail). They should not have any rights to the production database except select rights. Our code got a lot less buggy (and the same thing didn't crop up multiple times because the change was only made in prod and a later dev deployment overwrote it again then fixed only on prod in a hurry, rinse and repeat)when we had to start giving it to other people to deploy and not being allowed to make quick fix production changes because the deployment wasn't quite right. Further we stopped having those accidental "updates without the where clause highlighted that changed every record in the table" issues.

2
  • Yes, yes and yes. Never give developers any access to the production and very limited (and preferably none) to the staging. If for nothing else it decreases the stress they are exposed to. Dec 22, 2010 at 18:35
  • 1
    Yes! I'm a developer, and I don't want access to all this production stuff. And with other people doing the deployment of the software, that's one more test of the deployment process. (And perhaps the desaster recovery will improve out of this as well.)
    – cringe
    Oct 13, 2011 at 12:22
3
votes

Artist and User Interface Designer.

Most programmers are very poor at artwork, but companies don't bother to pay for an artist to draw images and icons for their products, and just use "programmer art" - with hideous results. (Until Windows Vista, this was the most immediately obvious differentiating factor between Macs and PCs - Macs looked beautiful and friendly, PCs were an eyesore)

In a similar way, a lot of programmers aren't very interested in user interface - they care primarily about their code. They simply expose the contents of their member variables directly into some editable fields, often not caring where they put buttons and fields on their forms, and assume that this is sufficient, resulting in unusable software. (The entire mobile phone industry was very guilty of this until the iPhone arrived to show them that you could actually make a phone UI that was nice to use)

Lotus Notes is a shining example of how bad both of these things can be if you don't get a professional designer to help the programmers out.

2
  • 2
    "Most programmers are very poor at artwook" and "A lot of programmers aren't very interested" isn't the same as "no programmer is interested" and "all programmers are bad". I've actually known a couple that do fairly well at it.
    – MIA
    Dec 3, 2010 at 17:25
  • 1
    @Jim Leonardo: Indeed. That's why I said "most" and "a lot" rather than "all". :-) Dec 5, 2010 at 20:39
3
votes

Writing overall tests and test plans. Seriously, guys, I can write my own test plans, but that means baking into the product whatever misapprehensions, false assumptions, and cognitive mistakes I made while writing the stuff. It was the only thing I hated about one company I worked at; where I am now, we at least have code reviews that will likely catch this stuff.

1
  • Yep, most tests should be written alongside the specifications, before any code is created. Although having a developer add extra tests based on the knowledge of what they touched isn't a bad thing. Sep 30, 2010 at 17:56
3
votes

Never wear more "hats" than you can reasonably handle and are comfortable with, trying to pigeon hole developers by saying that they shouldn't do A or B means that a great UI designer might go unnoticed because someone thinks that programmers should stay away from the UI.

At the end of the day everyone is going to have different strengths and weaknesses and a good manager/supervisor/team leader should know the best way to direct the people working for them to ensure that talents are being used appropriately. Likewise, if you are not comfortable with designing UIs or dealing with the end users, then let you team know so you can minimize your role in that area. However, you should be prepared to pick up some additional work in another area.

Also, if you are wearing too many hats (e.g. programmer, UI designer, tester, business analyst, etc) then you are either going to do poorly at some of them, or you will burn yourself out. Make sure that you know how many hats you can handle and try to keep the workload around that level.

Beyond that, there really are no "hats" that a developer shouldn't wear if they have the skills to excel in that role.

1
vote

I tend to take any job that is thrown at me if and only if:

  • I warn in advance about my skill level and possible implications and my boss decides that it is acceptable
  • There is a guru level person who can (and probably will at some stage) help me to deal with something unexpected
  • Read through some documentation, asked questions online, etc.

This way I am mostly insured against my boss and if someone goes wrong it is at least fixable.

1
vote

Developers are stakeholders in the situation (like customers, owners, etc), so they have a right to expect a meaningful job. In my opinion, that means the opportunity to work with your strengths.

So, a developer should not wear a hat that doesn't energise, contribute to personal growth, and lead to peak performance - and steal time from "hats" that do these things for them.

Other than not being the only one testing their own code, I think any "hat" is ok if it's meaningful work for the developer wearing the hat.

1
vote

The "designer" or the "creative guy". You'll go from innocently putting together a mockup of the interface of an application to writing marketing text for the next online ad campaign or endless discussions about the "right" shade of blue before you know it x_x.

0
votes

that hat with the beer cans on the side with a straw. bad idea if you get caught.

edit:

Here's the hat I hate but that has great reward - it's a big sign on me that says if this thing breaks it's all your fault....ah, but if it's good, then you my son are the good boy we all know you are - now go back to the basement...good boy...that's it.

The blame hat.

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