This is something I've been thinking about lately; what I actually do, and I think I've sort of figured it out
First up, I'm not really a very good programmer. I'm ok, I enjoy it and I have enough skill to get by. What I am good at though, is being able to understand what people want. My ability, and the bulk of my income, comes from being able to take someone's vague fuzzy idea/business rules (rules? huh! business cotton wool more like it) and flesh them out and bring them to life.
I think my most important role is not the technical stuff, but rather being able to listen and to understand and to really try and grok what the other person's telling you.
Yeah, this is a fallacy many people hold. We are not here to "write programs". We are here to solve people's problems, a program is just a means to do that. That's what you're really measured on, how many and how difficult the problems you solve are. If you can solve a problem not with code but wth say updating the documentation, or running a training class, then as a programmer that's the right thing to do.
It can actually hurt if you're really good at or really like programming because it can sometimes lead to unnecessary programming. A common example of this is writing a small script to automate something that would have actually taken less time to just perform manually the one or two times you have to do it.
Agreed, except you need the wisdom to know when you truly will never ever have to do that task again (nor anyone else) vs when you think you only need to do it once. There's value in having something scripted that you end up needing to come back to months later. I also know I would have preferred setup steps to be scripted on projects I've taken over, vs apparently just hand-entering SQL.
This is why you put the script on github and blog about it, that way there's a chance the script could save millions of times the amount of time it took to write.
On the other hand, if you have to do it one or two times a month, you should write a script. It prevents future mistakes on your part, and makes the task a lot easier to hand off to someone else, because you're guaranteed to record all the necessary steps.
This is exactly my job, that of a 'Business Systems Analyst' at a big insurance company. I spend most of my time refining requirements with business stakeholders until I can document a set of atomic tasks. This documentation, generally referred to as a 'Business Requirements Specification' gets passed along to the developer who then writes a 'Technical Specification' detailing the implementation of each business requirement. One of my primary goals is to remove any guesswork or questions from the developers scope, such that they can focus clearly on the implementation of the solution. In all of the enterprise level development jobs I've worked, the developer is not expected to interact with the business at all. The overhead for simple development sky rockets, but that's a reasonable trade off to meet regulatory requirements such as Sarbannes Oxley, etc.
A BA is one of those jobs I'd always thought would suit me until, in a previous life, I spent a few years working as a developer for Big Co. there we had a whole team of BAs and god were they hopeless. One of the worst things to happen to the development process.
the idea seemed to be that programmers are code monkeys; don't let them think, lets define exactly what they need to produce and get them to do exactly that. Then get a team of people to act as intermediaries between the business and the devs.
Geat idea except for: the BAs were passionless and didn't give a damn about anything other than getting the job 'done'. They didn't really understand the business at all. Most (almost all) of the many reams of documentation they produced was useless. They had no programming background, and no ability to anticipate edge cases, missing cases or anything really.
Sorry, but my limited exposure to business analysts has left me with not much more than a mix of contempt/ambivalence for the role.
That is why a lot of programmer jobs, especially for small firms where design and development will never be completely distinct teams of people, are listed as "developer / analyst" (or "analyst / developer").
Translating what the user wants into a practical design that is useful to them can be more important than actual programming skill.
Even further removed from programming: inside industry knowledge/experience can be vital too, particularly in regulated industries, so that you can translate what the user says they want into what they actually need (I have before had to quietly ask "have you run that past your compliance department?" when presented with a requirement that I saw would cause problems with the auditors - spotting these things in design stages rather then the UAT stage saves a lot of hassle).
First up, I'm not really a very good programmer. I'm ok, I enjoy it and I have enough skill to get by. What I am good at though, is being able to understand what people want. My ability, and the bulk of my income, comes from being able to take someone's vague fuzzy idea/business rules (rules? huh! business cotton wool more like it) and flesh them out and bring them to life.
I think my most important role is not the technical stuff, but rather being able to listen and to understand and to really try and grok what the other person's telling you.