3 ms·

What one programmer can do in one month, two programmers can do in two months. -- Fred Brooks As a programmer, I'd be happy in a team to be the only programmer

by TomK32 9y ago

What one programmer can do in one month, two programmers can do in two months. -- Fred Brooks As a programmer, I'd be happy in a team to be the only programmer as long as the rest of the team are experts in their domains.

oneeyedpigeon 9y ago
> As a programmer, I'd be happy in a team to be the only programmer as long as the rest of the team are experts in their domains. As someone in that position right now, let me just tell you that it's not all roses (not that I think you'd necessarily assume it was!). For one, you have to deal with the stigma of being 'the nerd' in the team. You'll also end up doing a lot of menial tasks because "you're the technical one" (e.g. trying to fix the printer, explaining basic tech to other members of the team). Finally, most importantly, other members of the team don't really understand what you do. They might devalue it, expect you to complete tasks in an unrealistic amount of time, or get frustrated when you're the bottleneck. There can be benefits of course — you can probably plan your work yourself without being told, quite as much, what to do — but, contrary to expectations, I've found it quite problematic: you are in a very isolated position.
- TomK32 9y ago
  When you are in that role it's also your task to define the role. I can't fix your printer, I can take it apart (and it's usually 5 a year that suffer this faith for my hunger of cheap motors and axis to hack thing with). Your task is to implement a core asset of the company, not to fix a stupid printer. Estimates is a skill barely anyone is good at, put a higher estimate on tasks and tell the team that stuff is always work in progress and subject to change but change requests are the cheapest if the come early. Also, involve the team so they see the current state (and make it clear that this or that tiny functionality is still simplistic and will be improved later on).

by TomK32 9y ago

oneeyedpigeon 9y ago

> As a programmer, I'd be happy in a team to be the only programmer as long as the rest of the team are experts in their domains. As someone in that position right now, let me just tell you that it's not all roses (not that I think you'd necessarily assume it was!). For one, you have to deal with the stigma of being 'the nerd' in the team. You'll also end up doing a lot of menial tasks because "you're the technical one" (e.g. trying to fix the printer, explaining basic tech to other members of the team). Finally, most importantly, other members of the team don't really understand what you do. They might devalue it, expect you to complete tasks in an unrealistic amount of time, or get frustrated when you're the bottleneck. There can be benefits of course — you can probably plan your work yourself without being told, quite as much, what to do — but, contrary to expectations, I've found it quite problematic: you are in a very isolated position.

TomK32 9y ago
When you are in that role it's also your task to define the role. I can't fix your printer, I can take it apart (and it's usually 5 a year that suffer this faith for my hunger of cheap motors and axis to hack thing with). Your task is to implement a core asset of the company, not to fix a stupid printer. Estimates is a skill barely anyone is good at, put a higher estimate on tasks and tell the team that stuff is always work in progress and subject to change but change requests are the cheapest if the come early. Also, involve the team so they see the current state (and make it clear that this or that tiny functionality is still simplistic and will be improved later on).