SQL Clone
SQLServerCentral is supported by Redgate
 
Log in  ::  Register  ::  Not logged in
 
 
 


The Worms-eye View


The Worms-eye View

Author
Message
Phil Factor
Phil Factor
SSCertifiable
SSCertifiable (7.5K reputation)SSCertifiable (7.5K reputation)SSCertifiable (7.5K reputation)SSCertifiable (7.5K reputation)SSCertifiable (7.5K reputation)SSCertifiable (7.5K reputation)SSCertifiable (7.5K reputation)SSCertifiable (7.5K reputation)

Group: General Forum Members
Points: 7476 Visits: 3064
Comments posted to this topic are about the item The Worms-eye View


Best wishes,

Phil Factor
Simple Talk
Jeff Moden
Jeff Moden
SSC Guru
SSC Guru (380K reputation)SSC Guru (380K reputation)SSC Guru (380K reputation)SSC Guru (380K reputation)SSC Guru (380K reputation)SSC Guru (380K reputation)SSC Guru (380K reputation)SSC Guru (380K reputation)

Group: General Forum Members
Points: 380321 Visits: 42968

"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

RBAR is pronounced ree-bar and is a Modenism for Row-By-Agonizing-Row.
First step towards the paradigm shift of writing Set Based code:
Stop thinking about what you want to do to a row... think, instead, of what you want to do to a column.
If you think its expensive to hire a professional to do the job, wait until you hire an amateur. -- Red Adair

Helpful Links:
How to post code problems
How to post performance problems
Forum FAQs
Dalkeith
Dalkeith
SSC Eights!
SSC Eights! (893 reputation)SSC Eights! (893 reputation)SSC Eights! (893 reputation)SSC Eights! (893 reputation)SSC Eights! (893 reputation)SSC Eights! (893 reputation)SSC Eights! (893 reputation)SSC Eights! (893 reputation)

Group: General Forum Members
Points: 893 Visits: 1159
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.
Dave Poole
Dave Poole
One Orange Chip
One Orange Chip (26K reputation)One Orange Chip (26K reputation)One Orange Chip (26K reputation)One Orange Chip (26K reputation)One Orange Chip (26K reputation)One Orange Chip (26K reputation)One Orange Chip (26K reputation)One Orange Chip (26K reputation)

Group: General Forum Members
Points: 26714 Visits: 3549
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.

LinkedIn Profile
www.simple-talk.com
Jeff Moden
Jeff Moden
SSC Guru
SSC Guru (380K reputation)SSC Guru (380K reputation)SSC Guru (380K reputation)SSC Guru (380K reputation)SSC Guru (380K reputation)SSC Guru (380K reputation)SSC Guru (380K reputation)SSC Guru (380K reputation)

Group: General Forum Members
Points: 380321 Visits: 42968
David.Poole - Monday, October 2, 2017 8:33 AM
I 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

RBAR is pronounced ree-bar and is a Modenism for Row-By-Agonizing-Row.
First step towards the paradigm shift of writing Set Based code:
Stop thinking about what you want to do to a row... think, instead, of what you want to do to a column.
If you think its expensive to hire a professional to do the job, wait until you hire an amateur. -- Red Adair

Helpful Links:
How to post code problems
How to post performance problems
Forum FAQs
Phil Factor
Phil Factor
SSCertifiable
SSCertifiable (7.5K reputation)SSCertifiable (7.5K reputation)SSCertifiable (7.5K reputation)SSCertifiable (7.5K reputation)SSCertifiable (7.5K reputation)SSCertifiable (7.5K reputation)SSCertifiable (7.5K reputation)SSCertifiable (7.5K reputation)

Group: General Forum Members
Points: 7476 Visits: 3064
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
Simple Talk
Jeff Moden
Jeff Moden
SSC Guru
SSC Guru (380K reputation)SSC Guru (380K reputation)SSC Guru (380K reputation)SSC Guru (380K reputation)SSC Guru (380K reputation)SSC Guru (380K reputation)SSC Guru (380K reputation)SSC Guru (380K reputation)

Group: General Forum Members
Points: 380321 Visits: 42968
Phil Factor - Monday, October 2, 2017 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.

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

RBAR is pronounced ree-bar and is a Modenism for Row-By-Agonizing-Row.
First step towards the paradigm shift of writing Set Based code:
Stop thinking about what you want to do to a row... think, instead, of what you want to do to a column.
If you think its expensive to hire a professional to do the job, wait until you hire an amateur. -- Red Adair

Helpful Links:
How to post code problems
How to post performance problems
Forum FAQs
Tom Thomson
Tom Thomson
SSC-Dedicated
SSC-Dedicated (39K reputation)SSC-Dedicated (39K reputation)SSC-Dedicated (39K reputation)SSC-Dedicated (39K reputation)SSC-Dedicated (39K reputation)SSC-Dedicated (39K reputation)SSC-Dedicated (39K reputation)SSC-Dedicated (39K reputation)

Group: General Forum Members
Points: 39493 Visits: 12889
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

Tom Thomson
Tom Thomson
SSC-Dedicated
SSC-Dedicated (39K reputation)SSC-Dedicated (39K reputation)SSC-Dedicated (39K reputation)SSC-Dedicated (39K reputation)SSC-Dedicated (39K reputation)SSC-Dedicated (39K reputation)SSC-Dedicated (39K reputation)SSC-Dedicated (39K reputation)

Group: General Forum Members
Points: 39493 Visits: 12889
Jeff Moden - Monday, October 2, 2017 9:59 PM
Phil Factor - Monday, October 2, 2017 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.

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

Jeff Moden
Jeff Moden
SSC Guru
SSC Guru (380K reputation)SSC Guru (380K reputation)SSC Guru (380K reputation)SSC Guru (380K reputation)SSC Guru (380K reputation)SSC Guru (380K reputation)SSC Guru (380K reputation)SSC Guru (380K reputation)

Group: General Forum Members
Points: 380321 Visits: 42968
TomThomson - Wednesday, October 4, 2017 10:45 AM
Jeff Moden - Monday, October 2, 2017 9:59 PM
Phil Factor - Monday, October 2, 2017 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.

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

RBAR is pronounced ree-bar and is a Modenism for Row-By-Agonizing-Row.
First step towards the paradigm shift of writing Set Based code:
Stop thinking about what you want to do to a row... think, instead, of what you want to do to a column.
If you think its expensive to hire a professional to do the job, wait until you hire an amateur. -- Red Adair

Helpful Links:
How to post code problems
How to post performance problems
Forum FAQs
Go


Permissions

You can't post new topics.
You can't post topic replies.
You can't post new polls.
You can't post replies to polls.
You can't edit your own topics.
You can't delete your own topics.
You can't edit other topics.
You can't delete other topics.
You can't edit your own posts.
You can't edit other posts.
You can't delete your own posts.
You can't delete other posts.
You can't post events.
You can't edit your own events.
You can't edit other events.
You can't delete your own events.
You can't delete other events.
You can't send private messages.
You can't send emails.
You can read topics.
You can't vote in polls.
You can't upload attachments.
You can download attachments.
You can't post HTML code.
You can't edit HTML code.
You can't post IFCode.
You can't post JavaScript.
You can post emoticons.
You can't post or upload images.

Select a forum







































































































































































SQLServerCentral


Search