28

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.

Thomas Owens
  • 79,623
  • 18
  • 192
  • 283
spong
  • 9,361
  • 6
  • 44
  • 58

19 Answers19

53

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.

BlairHippo
  • 8,663
  • 5
  • 41
  • 46
  • 7
    THIS. Seriously, just because I work ON computers doesn't mean I can fix infrastructure. You're just wasting your developers' time. – Jaco Pretorius Sep 29 '10 at 20:06
  • 5
    +1 the damage that can be wrought by an amateur sysadmin is enormous. – davidtbernal Sep 29 '10 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 07 '10 at 14:52
  • At least you are in a good position for a better computer. Fewer to convince... –  Dec 03 '10 at 17:36
  • 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... – Gabe Moothart Dec 03 '10 at 18:47
  • +1 and depending on where you work, it might not be legal to wear the sysadmin hat if you're a developer. – Larry Coleman Dec 03 '10 at 21:32
  • An important issue that this raises is that the network admin often has a privileged account - not necessary root/Domain Admin, but more privileged than 'regular users'. If writing code for 'regular users' to use, they just won't see the same kind of problems. – JBRWilkinson Dec 05 '10 at 23:55
  • 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 '11 at 00:46
  • Doing development and operations is a current hype termed "DevOps" – johannes Nov 29 '12 at 10:52
34

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.

Chris Holmes
  • 2,244
  • 14
  • 14
  • 1
    Until you turn out to be really good at building computers or doing tech support and they cut your pay to hire a new developer. – Josh K Sep 29 '10 at 18:46
  • 5
    @Josh: I think that'd be one of those "find a new job" situations. – Adam Lear Sep 29 '10 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 '10 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. – Peter Boughton Sep 29 '10 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 '10 at 22:11
  • -1 problem solver is a different role than a programmer. As a developer I must focus on the actual code, unit tests and the like. A problem solver should know the code, and should be able to pin point most of the deployment/interaction-with-other-software problems, also should be able to make some modifications in the code or give the programmers a hint of the required changes in the code, and IMHO is a highly needed member of a team, but it's a different role. – alexandrul Sep 30 '10 at 07:07
  • 1
    I dont think you should do everything your employer asks. You should have a say as well ... – Guillaume Sep 30 '10 at 07:09
  • @Peter Boughton: +1 for pointing out the real reason why, in a software company, a separate IT support team is usually redundant and devs should be allowed to hack on their IT needs themselves. – Lie Ryan Sep 30 '10 at 11:20
  • "Problem Solver" and "Programmer" are the same job alexandrul. Does your business analyst know how to connect to a web service and display the aggregate data on the UI? No? Then that's a problem. And you're there to solve it. – Chris Holmes Sep 30 '10 at 19:18
  • 2
    @Peter Boughton I'm saying there are too many people nowadays who don't understand the value of being a team player. I can understand the attitude - it's a generational thing; people feel entitled and there ARE some bad places to work that will take advantages of employees. But I know for myself, when I hire people, I want team players, no elitists. – Chris Holmes Sep 30 '10 at 19:20
  • Chris - precisely, working together with colleagues instead of only focusing on your own projects - something *all* staff should do, but (in general) a programmer's mind can be more suited to solving problems than the average, and they should want to help out. Co-workers that are always busy with their own tasks and wont spend a few minutes to make someone else's work easier are a PITA. – Peter Boughton Sep 30 '10 at 23:17
  • 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 07 '10 at 15:01
  • 1
    ... though having said that, I agree that getting a stick up your ass about "Dammit, Jim, I'm a developer, not a [fill_in_joke]!" isn't a good idea, either. As with most things, it's important to find the appropriate middle ground. – BlairHippo Oct 07 '10 at 15:09
  • Does this mean we should all be jacks-of-all-trades and masters of none? – CraigTP Oct 12 '10 at 14:00
  • No. That's not what I'm saying CraigTP. I'm saying there's a distinct difference between being a team player and being a "I don't want to do that because that's beneath me" type of developer. – Chris Holmes Oct 12 '10 at 20:17
  • 1
    @Chris: I think your answer was easy to misinterpret, but now that you've clarified in the comments I think it's easier to understand. I agree to a certain extent - last month I was given a task that I found boring and wasn't what I wanted to do, but I did it because that's what needed doing. Now that's done, and I've pushed for a better project because unless what I need (a good project I can test my skills on) and what the company needs (a good developer who has proven abilities) aren't lining up at the moment, and they need to. You can't forget your own goals. – JohnL Dec 03 '10 at 17:41
  • As others have mentioned, there is gray area, here. I believe that one of my roles at my firm is to maximize the value I add. If I spend time getting a paper shredder to work, simply because my boss asks me to, it's my responsibility to *at least* suggest that this may be a better task for a person who doesn't have software to write. – Tim Claason Dec 03 '10 at 18:56
  • If your top programmer takes the time to work on something that a lower level developer could do and as a result an important project doesn't get done, that is not being a team player. It's a lack of priorities and management. – JeffO Jan 28 '11 at 00:48
29

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.

Peter Turner
  • 6,897
  • 1
  • 33
  • 57
  • 4
    Good dedicated testers are definitely under-rated! – Peter Boughton Sep 29 '10 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. – Morgan Herlocker Sep 30 '10 at 05: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 '10 at 05: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 '10 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? –  Dec 03 '10 at 17:37
  • 1
    Testers out of uni aren't a bad idea - we use gap-year students as interns and they don't make the same assumptions more experienced people do. In many ways, they're closer to our target audience. At a previous company, we roped in the administration staff for the same reason. – JohnL Dec 03 '10 at 17:45
  • I disagree in the context of the OP's question. Sometimes the best people for testing a particular piece of a system are those who know how to figure out the internals... the other devs on a project. I'm firmly of the belief that EVERYONE on the project needs to wear the testing hat to some degree. You should never sign off on your own code, but beyond that anyone is a potential tester. – MIA Dec 03 '10 at 22:27
  • @Jim I work at a small shop with no QA dept. The bossman said we're supposed to test our own code to save money and we know where the tentacles are so we should be the first line of defense. He's right on one count, but oh so very wrong on the other. It's not going to save him any money relying on us bums. – Peter Turner Dec 04 '10 at 06:19
  • +1 - Although I am a good dev, going by the evaluations I get, I know I am a lousy tester. If there is a sound technical reason for something, I just don't see that it could still be wrong from a user perspective. – Bart van Ingen Schenau Jan 13 '11 at 10:59
26

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.

Jon Onstott
  • 1,538
  • 12
  • 18
  • Tell the culprits that they need permission from your boss, and register all time used for this. –  Dec 03 '10 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. – Jon Onstott Dec 03 '10 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. –  Dec 03 '10 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 03 '10 at 20:23
16

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.

dbkk
  • 2,106
  • 17
  • 16
10

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.

tcrosley
  • 9,541
  • 1
  • 25
  • 41
  • 2
    +1 Agreed that QA testing by the developers that wrote it defeats the purpose. – spong Sep 29 '10 at 17:45
  • @sunpech: Why does it defeat the purpose? – Josh K Sep 29 '10 at 17:46
  • 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 '10 at 17:52
  • @sunpech, @Josh - I think any good developer will perform extensive positive testing of their code. – ChaosPandion Sep 29 '10 at 17:56
  • @sunpech: I would agree that tests by others is required, but testing by the developer should be done first. – Josh K Sep 29 '10 at 17:59
  • @JoshK, I probably didn't make it clear in my answer that I still expect the programmer to do both unit and integration tests, but these are both separate from QA testing (at least in most of the companies I have worked for where there are separate testers). – tcrosley Sep 29 '10 at 18:06
  • 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 '10 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 '10 at 18:41
  • @Lorenzo -- I have edited my answer to say "most programmers should not develop the UI". You obviously have taken the time to learn some human factors engineering. IMO most programmers do not have the skills to do this for a successful consumer product (obviously, like myself, they can design a UI, it just won't be an optimal one). – tcrosley Sep 29 '10 at 19:06
  • 2
    @tcrosley: but I really think that some degree of expertise or knowledge on HMI and GUI design should be part of the basic background of any programmer. Even if he will never do that. – Wizard79 Sep 29 '10 at 22:53
  • Developers should not only design the UX/UI (with or without the aid of dedicated graphic/interaction designers) but it should be a priority over developing the functionality. Another way: the usability should be more important than the functionality (which is logical in that the worlds greatest hammer can't hammer nails without a handle). – cottsak Sep 30 '10 at 00:33
  • 1
    @cottsak: "it should be a priority over developing the functionality" -- I agree that the GUI design should be done first, but then it should be made part of the spec that is passed on to the programmer. – tcrosley Sep 30 '10 at 00:49
  • 1
    @tcrosley": "passed on to the programmer" mmm.. not really a fan of this either. Designers and developers should work together. Not in isolation. Ok to be fair, "passing something on" may not be considered isolated, but the definition should not be contained in a spec. The "spec" (if you must stick with that word) should evolve with the communication of the designer and developers working together. The idea that software can be created by this ["pass the parcel"](http://en.wikipedia.org/wiki/Pass_the_parcel) approach is ridiculous. – cottsak Sep 30 '10 at 01:12
  • 1
    We routinely (every 2-week iteration) have developers do QA on new features and bug fixes, but it's always explicitly programmers *who didn't actually work on the code for that task*. –  Sep 30 '10 at 01:41
  • @cottsak: I never meant to imply that the spec couldn't be updated. In fact I'm working right now on a project where I am implementing a GUI interactively with two human factors designers, one of whom sits in an office two doors down from me. But their design is contained a specification, so that it can be reviewed and updated as we go along. That is the mechanism of communication. – tcrosley Sep 30 '10 at 06:08
  • 1
    @tcrosley I think i get where you're coming from. The thing that jumped out at me from your answer was the inference or suggestion that since there are separate UI/UX/"human factors" people, a developer should not concern herself with the experience of the user. Maybe you're not even suggesting that. But it's a popular misguided belief. And sure lots of valuable software gets created from those who think that way. But _great_ software comes when developers engage the users experience first and are thinking about what the user might want/need/think every step of the coding process. – cottsak Sep 30 '10 at 07:01
  • 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. – David Thornley Sep 30 '10 at 17:46
  • 1
    @David Thornley: That's why I used the term "human factors person" in my answer. The guy that is designing the UI in our company has a degree in visual communications in addition to his fine arts degree. He knows what he is doing. – tcrosley Sep 30 '10 at 19:59
  • +1 I agree with this answer. I may know a thing or two about UI design, but I also know my mental model is skewed by my understanding of the 'guts'. (Even if I haven't started coding, I think about implementation implications behind every design I evaluate, and I can't be alone in that...) That's why a user advocate with a different perspective is key. Not to say that @Lorenzo can't achieve both perspectives in one person, but I think he's in the minority. – grossvogel Dec 03 '10 at 19:25
10

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.

Josh K
  • 23,019
  • 10
  • 65
  • 100
  • 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. – Frank Shearar Sep 29 '10 at 18:31
8

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?"
Rachel
  • 23,979
  • 16
  • 91
  • 159
6

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?

user281377
  • 28,352
  • 5
  • 75
  • 130
5

Sales.

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

Dan Ray
  • 9,106
  • 3
  • 37
  • 49
5

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.

Tarka
  • 1,588
  • 11
  • 14
  • 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 03 '10 at 20:26
4

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.

HLGEM
  • 28,709
  • 4
  • 67
  • 116
  • 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. – ElGringoGrande Dec 22 '10 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 '11 at 12:22
3

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.

rjzii
  • 11,274
  • 6
  • 46
  • 71
3

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.

Jason Williams
  • 279
  • 1
  • 5
  • 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 03 '10 at 17:25
  • 1
    @Jim Leonardo: Indeed. That's why I said "most" and "a lot" rather than "all". :-) – Jason Williams Dec 05 '10 at 20:39
3

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.

David Thornley
  • 20,238
  • 2
  • 55
  • 82
  • 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. – Peter Boughton Sep 30 '10 at 17:56
1

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.

wildpeaks
  • 2,691
  • 1
  • 19
  • 17
1

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.

Ingvald
  • 151
  • 1
  • 3
1

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.

Audrius
  • 179
  • 3
0

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.

johnny
  • 3,669
  • 3
  • 21
  • 35