ya … people

A friend of my daughter’s was exasperated one day, started out with the idea of saying “I’m surrounded by you idiots” but is by nature too polite and it came out “ya … people”. The longer I live in the world of management, the more this phrase pops into my head, but I refrain because it’s unfair and just too crabby. One thing that is clear though, is that in our profession, people really matter.

I have the pleasure to work with a great group of IT and business people. I have for the first time in my life been able to assemble a group of people together who have a compatible set of skills with me and with each other. While we came from widely different backgrounds in terms of languages and style, we have some more fundamental things in common that have made it all work. Today I was reading an interview of Peter Denning at ACM Ubiquity where his “Great Principles of Computing” are discussed. For a long time I have been trying to both understand what is unique about my own background that has enabled me to do as well as I have (my educational background is in music theory and composition). Of course I have been through all the basic undergrad level courses in CS, but so have most people in the field. My thinking has led me to the not so revolutionary conclusion that it’s the breadth of understanding that’s lacking, and that the most important concepts missing for developers are in systems and troubleshooting. The people I have pulled together have the ability to troubleshoot, which in turn requires a fundamental understanding of how systems work. Without those skills, everything else in the development process falls apart. In my time searching for new hires, I have serious trouble finding developers that know systems and can reasonably expected to troubleshoot their own problems, much less troubleshoot larger systems problems that arise as a direct or indirect consequence of programming/design decisions. It’s almost impossible to find systems specialists who have an interest in and especially any experience in working closely with developers in maintaining systems. Network people tend to live in the gray fog where nothing happening in the devices connected to the network are of any concern. Throughout my career, in large organizations, these three groups tend to eye each other suspiciously and clamor for protected turf primarily to limit the variables they have to deal with and frankly, to help make themselves look good.

In smaller businesses, the most typical story is that the organization has incomplete coverage of these basic areas. To the extent that security is seen as an additional separate concern, security problems fall into the same difficulty where nobody in the business fully understands the issues. In my small business, we have addressed this by collapsing the separate disciplines into more generic, overlapping roles. All developers are system administrators. All developers can do a code release, a patch update, be expected to solve a performance problem, tune a database query, identify dns/naming problems. A system includes the software interface the OS provides, so if I ever hire a full time system administrator, I would fully expect that person to understand COM+ security, the logging techniques of every package on the system, what network accesses each process uses, scheduling issues, and the normal operational understanding a user of these applications would have. I can eventually envision hiring a system administrator so I have someone with the ability to configure my SAN, replace a network card in a cluster and maintain MS Exchange. I wouldn’t expect a sys admin to be able program in c#, though perl would be a plus. I would expect a network specialist who knows Cisco IOS to also understand both bind and active directory based DNS, understand every protocol in use on the network, what applications use each protocol, what the nominal traffic levels are for each protocol and how to view logs, traces etc. that support or refute evidence that a sniffer has identified. I would expect that person to understand enough of the computer OS and the processes running to know which ports are in use by each server and why, and the consequences of enabling or disabling any of them.

What is the conclusion? I totally resist the tendency to specialization of roles. At the same time, I accept that individuals have different skills and that no one person will have all the skills required to accomplish all the tasks necessary to serve all an organization needs. But the difference is in skills, not the core understanding. In any organization, the “system” is a combination of computers, networks, applications and people and if you ever expect to have all these things cooperate to achieve the system’s goals, they better have a shared understanding of what a system is, what can be expected of it, what can’t be expected of it, and how to identify and solve problems within the system. I found it interesting how this was expressed in the educational goals of the Great Principles of Computing. Without going into specifics, I could reasonably expect all people I hire to have a common set of practices and principles according to Peter Denning’s terminology.

Advertisements

One response to “ya … people

  1. I agree completely about the pitfalls of specialization… looking back at my career now, I can’t imagine how far behind I would be if I had stayed at a certain “global transportation and logistics company” in town, instead of going on to positions that would actually challenge me to learn multiple disciplines.

    One of the biggest problems I have faced in my career is being viewed as a ‘jack of all trades, master of none’, simply because I’ve done the high level design and implementation work on both the server and network side of the house. Either I’ve ended up at smaller consulting companies that value the diversity, but can’t challenge me; or at larger organizations that really don’t care if I know anything outside my predefined duties and responsibilities. When you factor in salaries, it’s a tough call to make.

    My friend Nic and I worked together doing tech support for a printer manufacturer back when I lived in Minneapolis. I always admired his understanding of all the Windows and Mac junk we had to deal with, plus his knowledge of Unix systems and basic software development. I thought it was a great mix of skills, particularly in the tech support world. Fast forward six years, and the guy I still call for Unix help is writing software, managing test systems and making presales calls for a company that makes replication software. I still admire the hell out of him.

    I wish more people could figure out this “system” concept, and stop the bickering and political BS involved with the “software development is responsible for this, net ops is responsible for this” approach. It’s insanity, I tell you.