What kind of a software engineer am I, I often wonder.
Consider a Java developer, Tom Ws, who has worked on SOAP based web services for over a year, yet does not know how XML schema and WSDL are related.
Tom gave the front-end guy, Dick Ui, an updated WSDL. Dick then tells Tom, ok, now I need the XSD. Tom Ws thrashed about for a day, giving Dick Ui this XSD file and that, which Dick kept rejecting. Finally, Tom goes to the purported architect, Harry Bs, who, wonder of wonders, asked Dick Ui the right question. The WSDL contains all the XSDs you need, embedded within it. What on earth are you talking about? After this, the situation resolved itself fairly rapidly. It turned out that Dick Ui was looking for the schema of JMS payloads, a related but different unit.
Engineers
There are resources, that know your domain, technologies, tools coming in. These are few and far between. You cannot always count on finding these folks.
However, there is viable alternative. There are resources that will not know your problem space, nor the technologies and tools that you use, but upon arrival, they are perfectly able to dig into the existing system, discover what they have to learn, and learn it themselves.
They will not have answers right away, but they know the correct questions to ask, and can find the answers with minimal hand-holding.
Clerks
They begin work at pretty much the same gate as the engineer. There is much they do not know about the business domain, and the technical solutions of your choice. That is where the similarity ends.
They learn nothing that you do not teach them explicitly. They wait to be told what to learn. Then they wait to be taught what they have to learn. They cannot fill in any of the gaps themselves.
When they run into a roadblock, they will send out an email and are happy to wait, and wait, and wait. You see, they believe “answers” are someone else’s responsibility.
Baby-sitters
Someone must spoon-feed the clerks. Enter, the baby-sitter. You know those people that say to you pityingly, “Do you still code?”. That’s a baby-sitter.
The baby-sitter thinks that programmers are simply draftsman, translating a perfectly conceived blueprint into Java, C#, or what have you. That writing computer code is an act of communication, which requires thought and practice to master, a baby-sitter considers a fanciful concern. The baby-sitter believes that the coder will never have to make a consequential choice when he writes code, and actively encourages the coder to dumb himself down.
If you got rid of the clerks, you would not need baby-sitters.
Imagine
Imagine an engineering outfit that has only engineers. Imagine a development team that religiously avoids both clerks and baby-sitters.
This seems like a reasonable goal to me, especially, if you factor in the trope that a good developer is usually worth 4 or 5 mediocre developers (a case that I must learn to make one of these days). There will be human resource challenges; how to hire and keep high-skilled, and hence high-valued resources, but you have man-management challenges with low-skilled workers too.
As for me
What kind of a developer am I?
I suppose I have been around long enough to be some kind of an Engineer.
On some days, though, I am happy to be a baby-sitter. That is all the energy I can muster. Further, some poor soul is happy that I am making his job easier, and that is not a small thing.
On other days, I dream about a rigorous development outfit that is entirely, of and by, engineers. I would very probably bring up the caboose in a place like that, but that may not be such a bad thing.