(This is a snapshot of my old weblog. New posts and selected republished essays can be found at raganwald.com.)
Thursday, April 03, 2008
What is a Specialist's Skill Set?
My son Thomas had his tonsils and adenoids out today. Huge thanks to his Surgeon, Dr. Chiodo, and the pediatric staff at Toronto Eastern General Hospital. He’s recovering pretty much as can be expected, thank you very much for asking.
One thing I noticed about the process. It all started with a referral from a General Practitioner, in this case our Family Physician Dr. Kohut. She analyzed the situation and determined that an opinion from a specialist was appropriate. This being socialized medicine, you couldn’t pull out our wallet and go straight to the specialist, we had to have our GP do a little qualifying first.
But the interesting thing is what happened next. We went to see Dr. Chiodo, he examined Thomas, and after discussing our options and the risks associated with the procedure with us, he booked Thomas for surgery.
Then today, Dr. Chiodo removed his tonsils and adenoids. This is standard procedure, and I want to mention it to compare it to programming, of course. You notice that although Dr. Chiodo is a very busy specialist, he does his own diagnoses. There is no division of labour where one doctor determines that the tonsils need to come out and the first time the surgeon sees the patient is when the anesthetist signals it’s ok to proceed.
The person performing the procedure is the most qualified to diagnose the patient and also—mark my words carefully—the person who discusses the options and risks with the patient. This is sometimes the case in programming and sometimes not.
Right now, I don’t feel like talking about what kinds of organizations divide things up so that one person sells the service to the client, another writes down the requirements, a third person estimates when it will be done and manages the process, a fourth person turns the requirements into a design and a specification, and finally the hapless programmer, the “specialist,” performs the procedure without any meaningful influence over the diagnosis or the decision-making process. Let’s skip that rant.
Let’s also skip a rant about how many programmers have the skills to diagnose the patient, by which I mean, the business acumen to discuss what a client actually needs to accomplish in business terms. Let’s not argue about how many programmers have the communication skills to present the options to a client in such a way as to guide a client to making a smart decision while still ensuring that the programmer’s business profits. (This is relevant even when programmer and client are employed by the same organization).
Let’s talk about you. Do you have the specialist’s skill set? Can you diagnose, inform, and operate?
If not, why not?
My son Thomas had his tonsils and adenoids out today. Huge thanks to his Surgeon, Dr. Chiodo, and the pediatric staff at Toronto Eastern General Hospital. He’s recovering pretty much as can be expected, thank you very much for asking.
One thing I noticed about the process. It all started with a referral from a General Practitioner, in this case our Family Physician Dr. Kohut. She analyzed the situation and determined that an opinion from a specialist was appropriate. This being socialized medicine, you couldn’t pull out our wallet and go straight to the specialist, we had to have our GP do a little qualifying first.
But the interesting thing is what happened next. We went to see Dr. Chiodo, he examined Thomas, and after discussing our options and the risks associated with the procedure with us, he booked Thomas for surgery.
Then today, Dr. Chiodo removed his tonsils and adenoids. This is standard procedure, and I want to mention it to compare it to programming, of course. You notice that although Dr. Chiodo is a very busy specialist, he does his own diagnoses. There is no division of labour where one doctor determines that the tonsils need to come out and the first time the surgeon sees the patient is when the anesthetist signals it’s ok to proceed.
The person performing the procedure is the most qualified to diagnose the patient and also—mark my words carefully—the person who discusses the options and risks with the patient. This is sometimes the case in programming and sometimes not.
Right now, I don’t feel like talking about what kinds of organizations divide things up so that one person sells the service to the client, another writes down the requirements, a third person estimates when it will be done and manages the process, a fourth person turns the requirements into a design and a specification, and finally the hapless programmer, the “specialist,” performs the procedure without any meaningful influence over the diagnosis or the decision-making process. Let’s skip that rant.
Let’s also skip a rant about how many programmers have the skills to diagnose the patient, by which I mean, the business acumen to discuss what a client actually needs to accomplish in business terms. Let’s not argue about how many programmers have the communication skills to present the options to a client in such a way as to guide a client to making a smart decision while still ensuring that the programmer’s business profits. (This is relevant even when programmer and client are employed by the same organization).
Let’s talk about you. Do you have the specialist’s skill set? Can you diagnose, inform, and operate?
If not, why not?
Comments on “What is a Specialist's Skill Set?”:
<< Home
This post has made me very interested in seeing the kind of software created by a generalist programmer who diagnoses and a specialist programmer who performs the surgery. I'm thinking Conway's Law here... I genuinely want to know what kind of software gets created in those conditions.
This post has made me very interested in seeing the kind of software created by a generalist programmer who diagnoses and a specialist programmer who performs the surgery.
All too often, the generalist isn’t actually a programmer. The usual term in our business is a “Product Manager.” Some product managers don’t design the product, they write requirements. In other words, they describe the symptoms but not the possible cures.
But others design the product, often under the guise of writing requirements. It’s just that their requirements include enough page and report mockups to make a mockery of the phrase “You have complete control of the implementation.”
All too often, the generalist isn’t actually a programmer. The usual term in our business is a “Product Manager.” Some product managers don’t design the product, they write requirements. In other words, they describe the symptoms but not the possible cures.
But others design the product, often under the guise of writing requirements. It’s just that their requirements include enough page and report mockups to make a mockery of the phrase “You have complete control of the implementation.”
Maybe it's just hubris, but I think I could fill all the roles needed. While I admit I'm young and still need to develop my programming skills further, I opted to get both a CS and an English degree while in college, and business interests me.
I don't think I'm unique in this way though. I think a lot of programmers are like this - just not enough of them. However, I think it's the programmers who have this diverse skill set who are the best at their jobs.
Remember though, that there are still bad doctors, just like there are bad programmers. Just because you have the skills doesn't mean you're any good.
I don't think I'm unique in this way though. I think a lot of programmers are like this - just not enough of them. However, I think it's the programmers who have this diverse skill set who are the best at their jobs.
Remember though, that there are still bad doctors, just like there are bad programmers. Just because you have the skills doesn't mean you're any good.
Maybe it's just hubris, but I think I could fill all the roles needed.
I obviously don’t know if it’s hubris on your part, but FWIW, I think it is a great thing to recognize the value of the three skills. Not just for their own sake, but for the way each one informs the other two.
I obviously don’t know if it’s hubris on your part, but FWIW, I think it is a great thing to recognize the value of the three skills. Not just for their own sake, but for the way each one informs the other two.
I'd like to hear the rant about specialists. We're struggling with exactly this at work: should the coders do BA work? Can specialist BA's be trusted to spec already-estimated projects, knowing there's no incentive for them not to goldplate?
Lol @ url.
Yes, it always annoys, no infuriates, me that my small company has no person to do the things us programmers suck at, such as user-interface design. At least we sort of have a DBA, even if it is just that the sys admin seems to be pretty good with SQL.
And programmers should under no circumstances make design or usability decisions. :(
Yes, it always annoys, no infuriates, me that my small company has no person to do the things us programmers suck at, such as user-interface design. At least we sort of have a DBA, even if it is just that the sys admin seems to be pretty good with SQL.
And programmers should under no circumstances make design or usability decisions. :(
The most complex part is diagnosis.
A medical specialist knows my body better than me, he just asks some simple and dumbed-down questions about symptoms and clues but he completely understands the inner workings of my body and can find the problem.
When we, I dare say software specialist, go to business people, we generally have no idea how they are running their business, and generally we don't how they should. So typically I can't help them improve their process or I must study about their industry's best practices, etc. which must actually be their specialty!
A good programmer can be a good BA, but it's rare and that's why we separate the two tasks in our companies.
A medical specialist knows my body better than me, he just asks some simple and dumbed-down questions about symptoms and clues but he completely understands the inner workings of my body and can find the problem.
When we, I dare say software specialist, go to business people, we generally have no idea how they are running their business, and generally we don't how they should. So typically I can't help them improve their process or I must study about their industry's best practices, etc. which must actually be their specialty!
A good programmer can be a good BA, but it's rare and that's why we separate the two tasks in our companies.
we generally have no idea how they are running their business, and generally we don't how they should.
So, you are describing a surgeon who is incredibly talented at cutting and sewing tissue, who knows the ins and outs of the various tools like electrified scalpels, but is ignorant of basic anatomy, and must be told what to cut and sew without understanding why.
So, you are describing a surgeon who is incredibly talented at cutting and sewing tissue, who knows the ins and outs of the various tools like electrified scalpels, but is ignorant of basic anatomy, and must be told what to cut and sew without understanding why.
programmers should under no circumstances make design or usability decisions.
I have no idea why you are saying this, so I won't put words in your mouth. However, I can repeat what others have said, namely that they aren't competent at it.
That is a self-serving argument. IOW, if you assert that programmers have no business doing it, you build your business around separating the activities. Which leads to having no job openings for a programmer who designs the UI. Which leads to you never meeting any programmers with design skills. And ultimately, if enough people are like you, programmers do not consider UI design a basic job skill, so they don't study it.
However, the world is a pretty big place, and if you look a little harder, you will find (1) programmers with UI design skills, and (2) companies where the two roles are not separated. Many of them are start ups that emphasize the quality of the result over trying to build a repeatable process that works no matter what kind of monkeys you throw in the cage.
I have no idea why you are saying this, so I won't put words in your mouth. However, I can repeat what others have said, namely that they aren't competent at it.
That is a self-serving argument. IOW, if you assert that programmers have no business doing it, you build your business around separating the activities. Which leads to having no job openings for a programmer who designs the UI. Which leads to you never meeting any programmers with design skills. And ultimately, if enough people are like you, programmers do not consider UI design a basic job skill, so they don't study it.
However, the world is a pretty big place, and if you look a little harder, you will find (1) programmers with UI design skills, and (2) companies where the two roles are not separated. Many of them are start ups that emphasize the quality of the result over trying to build a repeatable process that works no matter what kind of monkeys you throw in the cage.
WRT to requirements being akin to symptoms, IME the requirements are part of the solution set and not the problem set. Most projects I've been part of were seriously compromised because the requirements overconstrained the solution, while a less restrictive requirement would still give as much business value and lead to a better solution.
On comparing programmers to doctors, remember that the specialist doctor handles one kind of human issues, he don't provide integrated care solutions, but more often than not a programmer must build a integrated solution that cover many different areas of software building. A better analogy would be a product manager representing the patient and the programmer team being the different specialists required to treat the entire "health issue", with different programmers creating a solution to a single problem. This still leaves open issues like integration problems, which are less frequent in health because the underlying system (i.e. the human body) is much less flexible and more well understood than software. People have their own bodies and are familiar with its needs and limitations but in software such constraints aren't well understood, we end up creating software because we can, but not because we should.
On comparing programmers to doctors, remember that the specialist doctor handles one kind of human issues, he don't provide integrated care solutions, but more often than not a programmer must build a integrated solution that cover many different areas of software building. A better analogy would be a product manager representing the patient and the programmer team being the different specialists required to treat the entire "health issue", with different programmers creating a solution to a single problem. This still leaves open issues like integration problems, which are less frequent in health because the underlying system (i.e. the human body) is much less flexible and more well understood than software. People have their own bodies and are familiar with its needs and limitations but in software such constraints aren't well understood, we end up creating software because we can, but not because we should.
A very interesting post. I am constantly wondering if I am what you describe. I work very hard to try NOT to separate myself and these activities from what I do every day - but I will certainly admit that it is not easy. It is so much easier to just wave a hand and make an estimate or design or decision without consulting other programmers. It does require some conscious effort to make sure that everyone making the 'diagnose' decisions are involved in making the 'design and implementation' decisions as well - that those people are involved at each step in the 'process path'. At Big Co. these things ARE separated - I am working to make sure that despite that 'physical' separation that they remain etherically connected to provide better continuity.
Thanks for making me think - again.
Thanks for making me think - again.
The specialist did *not* do his own diagnosis - he simply confirmed the diagnosis. The skills of diagnosis and specialist are separate - if the specialist tried to diagnose everything, then he would lean too much towards his own area of specialization. He would likely fix the problem, but he would do so using his own techniques, which may not be optimal for the situation.
Likewise, I think there is a place for a business analyst or product manager separate from a programmer. There is an understandable tendency for programmers to stick to their own technical areas of expertize - something a business analyst should be independent of.
Thats the theory at least. I've never seen a good business analyst in the wild, although I have seen a good product manager.
Likewise, I think there is a place for a business analyst or product manager separate from a programmer. There is an understandable tendency for programmers to stick to their own technical areas of expertize - something a business analyst should be independent of.
Thats the theory at least. I've never seen a good business analyst in the wild, although I have seen a good product manager.
It entirely dependent on what one's actual skills are.
In this case, the specialist likely did perform his own diagnosis since the GP is probably not also an ENT. It may have concured with the GP but in the end, he's on the hook for it so he has to do it himself. But this is no different than the interactions of competent programmers in most large orgs.
I'm a GP .Net guy, but when something funky is coming out of SAP I have to go to the SAP specialist and say "Hey, this BAPI is returning the wrong results."
It would be irresponsible on their part to just accept my interpretation and slap in a change without a complete investigation on their part.
However, I have the creds to diagnose and correct all types of .Net apps, GUI, Web, Service, etc.
My observation is that most managers just don't know how to judge these abilities.
In this case, the specialist likely did perform his own diagnosis since the GP is probably not also an ENT. It may have concured with the GP but in the end, he's on the hook for it so he has to do it himself. But this is no different than the interactions of competent programmers in most large orgs.
I'm a GP .Net guy, but when something funky is coming out of SAP I have to go to the SAP specialist and say "Hey, this BAPI is returning the wrong results."
It would be irresponsible on their part to just accept my interpretation and slap in a change without a complete investigation on their part.
However, I have the creds to diagnose and correct all types of .Net apps, GUI, Web, Service, etc.
My observation is that most managers just don't know how to judge these abilities.
Yes. I've been there from pre-sales, negotiations, design, implementation, post-sales and support. The more interesting question is: why?
Because I've been in a number of tiny startups. Often as small as 4 or 5 people. In that situation, you either learn to do it yourself or it doesn't get done. I'm a pretty fair network and system admin as well.
But I've also worked for large companies, where I get to 'focus' a lot more on my primary tasks, architecture and coding. Both are good, but I do like doing it myself.
Paul.
Because I've been in a number of tiny startups. Often as small as 4 or 5 people. In that situation, you either learn to do it yourself or it doesn't get done. I'm a pretty fair network and system admin as well.
But I've also worked for large companies, where I get to 'focus' a lot more on my primary tasks, architecture and coding. Both are good, but I do like doing it myself.
Paul.
So, you are describing a surgeon who is incredibly talented at cutting and sewing tissue, who knows the ins and outs of the various tools like electrified scalpels, but is ignorant of basic anatomy, and must be told what to cut and sew without understanding why.
exactly :))
exactly :))
I've tried to forge a career as somebody involved in everything from requirements and user interface design through programming and even to things like database administration sometimes. It's hard to do - there aren't many jobs around like that and I sometimes end up feeling like a jack of all trades and master of none.
However, understanding properly why you are writing the software and your users means you don't have the chinese whispers things going on. Maybe I'm not quite as good a programmer as I could be as a result, but it's far better to be a slightly worse programmer coding something useful than an amazing programmer coding something that isn't.
I actually originally started a programming career and decided that it wasn't for me. I didn't realise at the time that the reason I didn't enjoy it was because I couldn't see the big picture or why I was being asked to code things. I was very much a cog in a machine. I went and made websites instead, and gradually found myself getting back into programming because it was the only way to get things to do what I wanted. I now love it.
However, understanding properly why you are writing the software and your users means you don't have the chinese whispers things going on. Maybe I'm not quite as good a programmer as I could be as a result, but it's far better to be a slightly worse programmer coding something useful than an amazing programmer coding something that isn't.
I actually originally started a programming career and decided that it wasn't for me. I didn't realise at the time that the reason I didn't enjoy it was because I couldn't see the big picture or why I was being asked to code things. I was very much a cog in a machine. I went and made websites instead, and gradually found myself getting back into programming because it was the only way to get things to do what I wanted. I now love it.
Very interesting comparison of professions, thanks a lot for the post. Maybe it is just hybris on my side, but the medical scenario you described is one of the reasons I enjoy my current position. The company I work with provides a very flexible CRM system. For a lot of projects I do pre-sales tech presentations, analyze requirements and present and discuss options ot the customer, participate in the spec/design sessions. Then I do the GUi design, implement the solution and am responsible for a sucessful roll-out. The challenges? To quote Lewis Carroll, you have to run as fast as you can just to maintain you position ;-)
You need to learn a lot more about social skills than you might think and you have to let go of "bare metal" system programming and use an application server architecture that is customized using something high-level (in our case, JavaScript). But I have some word in the development of the app server, on the other hand. So I don't know how close that comes to you surgeon, but this is exaclty what I like, the *need* to learn about GUI design, the *need* to learn how to cast fuzzy business processes into software. The downside: by no means I would dare to suggest that I am a pro in any of these fields, I just try to learn as much as I can for the last 26 years (I'm 44 now).
You need to learn a lot more about social skills than you might think and you have to let go of "bare metal" system programming and use an application server architecture that is customized using something high-level (in our case, JavaScript). But I have some word in the development of the app server, on the other hand. So I don't know how close that comes to you surgeon, but this is exaclty what I like, the *need* to learn about GUI design, the *need* to learn how to cast fuzzy business processes into software. The downside: by no means I would dare to suggest that I am a pro in any of these fields, I just try to learn as much as I can for the last 26 years (I'm 44 now).
<< Home
