September 30, 2017 at 1:11 am
Comments posted to this topic are about the item The Worms-eye View
Best wishes,
Phil Factor
October 1, 2017 at 5:26 pm
"DevOps" is not a process. It's a culture. It may support a process but it is not a process.
I also disagree with your notion of overspecialization. For example, someone in Ops simply doesn't need to know how to write code, someone in finance never needs to actually work on the manufacturing floor, a Developer never needs to install switches or terminate cables, and even in a more closely related case, it's a rare thing where a Front End Developer and a Database Developer actually have a need to get months worth of training in the other's job.
I also find that most companies in the West don't, won't, and haven't rotated talent through the rigors of many different jobs unless an individual has been specially earmarked as a future manager and, even then, it's a rare case to find such a thoughtful and well meaning company, which is why so many managers frequently don't know how to write a schedule and why they have their employees write their own yearly reviews.
--Jeff Moden
Change is inevitable... Change for the better is not.
October 2, 2017 at 2:30 am
I've seen a few projects fail because of a lack of weakness in a specialist area or because they've just run out of funds so I am sympathetic to the view that specialisation is a double edged sword - I think the pendulum is swinging back - a lot of departments and organisations don't have the funds for multi-disciplinary teams and the kind of rich online applications simply aren't available for purchase for lots and lots of people. This is why Google Sheets and Google Docs will be such a winner for many people. Boy are some users going to do some weird ass stuff with those.
The minute someone makes a web enabled IDE that is as easy as MS Access for a reasonable price things will go crazy.
October 2, 2017 at 8:33 am
I think siloed thinking rather than over-specialization is the biggest threat. As people climb the greasy pole the Dunning Kruger affect comes into play. Expertise in one area leads to over-confidence in another. Where are the next generation of good solution architects coming from?
I have made it my business to learn a little bit about a lot of different things outside of my core discipline. Not because I want to be an infrastructure guy but because I want to understand what their stress points are. For a small amount of effort and pragmatism on my part can one of their major headaches be avoided? Ditto any other IT discipline.
Walk a mile in another man's shoes. My experience is that the amount of effort to learn the basics of someone else's disciplines is greatly appreciated. It fosters trust and with trust comes much more open communication. Sometimes an external perspective leads to a radical shift in thinking. I've certainly benefited from people with little data experience asking questions that people with data experience probably wouldn't ask.
I have found that taking the effort to be approachable pays back far more than is invested into it.
It think over-specialization comes with its own risks. It's the old joke about going to university and learning more and more about less and less until you know a hell of a lot about nothing.
October 2, 2017 at 10:06 am
David.Poole - Monday, October 2, 2017 8:33 AMI think siloed thinking rather than over-specialization is the biggest threat.
+1000 to that. You've said it much more eloquently than I did.
--Jeff Moden
Change is inevitable... Change for the better is not.
October 2, 2017 at 10:49 am
I agree that siloed thinking is bad, but so is a lack of understanding of the tasks that your team members have to perform. To participate in any team process, whether it is building a house, producing a new soft drink, or developing software, you need to have some practical experience of the whole process. I don't mean that you should be an expert but you need to know about every role. After all, a musician in an orchestra won't be expected to be able to play every instrument, two or three maybe, but will need to know enough about what is involved to understand the constraints and limitations. The poor conductor is actually expected to know quite a lot about every instrument. An Anaesthetist has a complete medical training and experience in surgery, intensive care and pain management. In IT, by contrast, it is common to find developers who have not even the vaguest idea of multiuser/multiprocess systems and transactions, and entirely lack any knowledge of the legal constraints under which we operate. We have, to be fair, Database people who entirely lack understanding of application development. No amount of group hugs or whiteboard meetings can substitute for an appreciation of the roles and tasks of other IT disciplines.
Best wishes,
Phil Factor
October 2, 2017 at 9:59 pm
Phil Factor - Monday, October 2, 2017 10:49 AMI agree that siloed thinking is bad, but so is a lack of understanding of the tasks that your team members have to perform. To participate in any team process, whether it is building a house, producing a new soft drink, or developing software, you need to have some practical experience of the whole process. I don't mean that you should be an expert but you need to know about every role. After all, a musician in an orchestra won't be expected to be able to play every instrument, two or three maybe, but will need to know enough about what is involved to understand the constraints and limitations. The poor conductor is actually expected to know quite a lot about every instrument. An Anaesthetist has a complete medical training and experience in surgery, intensive care and pain management. In IT, by contrast, it is common to find developers who have not even the vaguest idea of multiuser/multiprocess systems and transactions, and entirely lack any knowledge of the legal constraints under which we operate. We have, to be fair, Database people who entirely lack understanding of application development. No amount of group hugs or whiteboard meetings can substitute for an appreciation of the roles and tasks of other IT disciplines.
Agreed but you don't have to give up being a specialist to understand what other people are doing. Nothing says that you have to be able to do something to understand some of the things it may need. For example, I can troubleshoot C#, COBOL, and a lot of other languages if the Developer can explain things a bit. But sit me down and tell me that I have to write code from scratch in one of those other languages? That's just not going to happen any time soon.
And unless the brain surgeon has an interest, he probably has no clue how the drive train of his car works and probably couldn't replace a tail light. even though the car is very important to his job.
--Jeff Moden
Change is inevitable... Change for the better is not.
October 4, 2017 at 10:30 am
It's a great editorial, Phil.
I've watched more and more over-specialisation taking over my profession to the extent that almost every person who works in industry in computing and/or IT is ignorant of everything but one tiny narrow area and totally uninterested inlearning anything outside their extremely narrow specialism (and maybe there are too many people like that working in academia too). There are not enough people who know enough to have a technical conversation with colleagues in a slightly different profession (for example the C++ specialist can't communicate with the Java specialist and neither of them can communicate with someone who specialises in Javascript or VBScript). Over the years I've told a lot of people that overspecialism (and the unwillingness to look at anything new that goes with it) is a horrible mistake and is holding back progress and damaging productivity in our profession, but a frighteningly small proportion of people agree with me. So this editorial has cheered me up.
Tom
October 4, 2017 at 10:45 am
Jeff Moden - Monday, October 2, 2017 9:59 PMPhil Factor - Monday, October 2, 2017 10:49 AMI agree that siloed thinking is bad, but so is a lack of understanding of the tasks that your team members have to perform. To participate in any team process, whether it is building a house, producing a new soft drink, or developing software, you need to have some practical experience of the whole process. I don't mean that you should be an expert but you need to know about every role. After all, a musician in an orchestra won't be expected to be able to play every instrument, two or three maybe, but will need to know enough about what is involved to understand the constraints and limitations. The poor conductor is actually expected to know quite a lot about every instrument. An Anaesthetist has a complete medical training and experience in surgery, intensive care and pain management. In IT, by contrast, it is common to find developers who have not even the vaguest idea of multiuser/multiprocess systems and transactions, and entirely lack any knowledge of the legal constraints under which we operate. We have, to be fair, Database people who entirely lack understanding of application development. No amount of group hugs or whiteboard meetings can substitute for an appreciation of the roles and tasks of other IT disciplines.Agreed but you don't have to give up being a specialist to understand what other people are doing. Nothing says that you have to be able to do something to understand some of the things it may need. For example, I can troubleshoot C#, COBOL, and a lot of other languages if the Developer can explain things a bit. But sit me down and tell me that I have to write code from scratch in one of those other languages? That's just not going to happen any time soon.
And unless the brain surgeon has an interest, he probably has no clue how the drive train of his car works and probably couldn't replace a tail light. even though the car is very important to his job.
I think you are inventing something to disagree with there, Jeff, Phil didn't suggest that anyone should give up being a specialist, he said that overspecialisation is a problem; and it most certainly is a problem. And you clearly know that it is - why else have you have deliberately learnt things that an overspecialised SQL specialist would consider totally irrelevant to him - like how to help a developer troubleshoot his C# or COBOL or whatever - if not simply to avoid being caught up in the nasty results of overspecialisation?
Tom
October 9, 2017 at 12:52 am
TomThomson - Wednesday, October 4, 2017 10:45 AMJeff Moden - Monday, October 2, 2017 9:59 PMPhil Factor - Monday, October 2, 2017 10:49 AMI agree that siloed thinking is bad, but so is a lack of understanding of the tasks that your team members have to perform. To participate in any team process, whether it is building a house, producing a new soft drink, or developing software, you need to have some practical experience of the whole process. I don't mean that you should be an expert but you need to know about every role. After all, a musician in an orchestra won't be expected to be able to play every instrument, two or three maybe, but will need to know enough about what is involved to understand the constraints and limitations. The poor conductor is actually expected to know quite a lot about every instrument. An Anaesthetist has a complete medical training and experience in surgery, intensive care and pain management. In IT, by contrast, it is common to find developers who have not even the vaguest idea of multiuser/multiprocess systems and transactions, and entirely lack any knowledge of the legal constraints under which we operate. We have, to be fair, Database people who entirely lack understanding of application development. No amount of group hugs or whiteboard meetings can substitute for an appreciation of the roles and tasks of other IT disciplines.Agreed but you don't have to give up being a specialist to understand what other people are doing. Nothing says that you have to be able to do something to understand some of the things it may need. For example, I can troubleshoot C#, COBOL, and a lot of other languages if the Developer can explain things a bit. But sit me down and tell me that I have to write code from scratch in one of those other languages? That's just not going to happen any time soon.
And unless the brain surgeon has an interest, he probably has no clue how the drive train of his car works and probably couldn't replace a tail light. even though the car is very important to his job.
I think you are inventing something to disagree with there, Jeff, Phil didn't suggest that anyone should give up being a specialist, he said that overspecialisation is a problem; and it most certainly is a problem. And you clearly know that it is - why else have you have deliberately learnt things that an overspecialised SQL specialist would consider totally irrelevant to him - like how to help a developer troubleshoot his C# or COBOL or whatever - if not simply to avoid being caught up in the nasty results of overspecialisation?
You, good Sir, are probably correct in saying so. I'm a bit sensitive to the term "overspecialization" because I've been accused so many times of being over specialized. And, no... I've never learned anything about C# or Cobol prior to helping the developers that I helped.
--Jeff Moden
Change is inevitable... Change for the better is not.
October 10, 2017 at 8:56 am
Jeff Moden - Monday, October 9, 2017 12:52 AMYou, good Sir, are probably correct in saying so. I'm a bit sensitive to the term "overspecialization" because I've been accused so many times of being over specialized. And, no... I've never learned anything about C# or Cobol prior to helping the developers that I helped.
I think real specialists are always willing to learn things when they need a bit of knowledge to halp colleagues. The different thing about overspecialists is that they will often refuse to learn such things because it's outside their specialist area - an over-specialist DBA wouldn't learn to help a developer to trouble-shoot the interaction of his Cobol program with the database because how Cobol ineracts with teh database is no part of his specialty; in fact he will even refuse to learn things that are essential for him to know if he is to communicate with his colleagues, and will sometimes be able to flim-flam management into believeing this is reasonable.
For myself, being a specialist usually ended up being a generalist, partly because I was a specialist in different things at different times, partly because I like learning things, and partly because I was often considered the go to guy for resoving problems between different components/products/development teams and I had to learn both sides to handle that. For example I first learnt JavaScript when I was asked to help someone with problems in a JavaScript application which was interacting both with Active-X and with some Cisco software. At the same company I was made responsible for software licensing because I was more likely to learn the ropes quickly and properly than anyone else, That was a company where I was originally brought in to sort out database problems from outside the development group as the development people mostly didn't think knowing databases well mattered at all, so Ops Director wanted someone who knew both databases and development.
Tom
Viewing 11 posts - 1 through 10 (of 10 total)
You must be logged in to reply to this topic. Login to reply