When Did IT Practitioners Lose Their Curiosity?

One of my readers sent me an interestingly sad story as a response to my importance of fundamentals rant. Here it is… enjoy ;)

2017-01-14: Updated with a different viewpoint

I've been at a new job for about 3 months now, in charge of the somewhat neglected network and am finally getting to the point where I ask my colleagues, "Does anyone know why I sometimes get a useless IP address from some other DHCP server on the Ethernet connection on my laptop here in the office?"

"Oh, yeah, that happens to other people sometimes."  Followed by dead silence and no exhibited curiosity or desire to fix the problem.

A bit of time rummaging in forwarding tables and looking at DHCP traffic with tcpdump, and I found that someone decided that bridging the Ethernet and WiFi networks on a teeny computer in a conference room that's used to drive the big, mobile display would be a good idea. Have to ask him what problem he felt he was solving and why he has that much faith in spanning-tree.

To make things more interesting, there are multiple such mobile display workstations, and I rather suspect that if more than one of them is plugged into Ethernet at the same time, we depend very heavily on spanning-tree to keep our network running.

So in my opinion there’s another even more fundamental job attribute: a sense of curiosity about why odd and less than wonderful things are happening. That you should know how to interpret traffic in tcpdump/wireshark is right up there too.

And here's a sad view from another perspective (also kept anonymous for obvious reasons):

I know from experience, most (skilled) techs have a will to create elegant and working long-tem solutions. What is elegant is different from tech to tech, though.

In Germany there's a great deal of work consolidation happening for years. At least in IT. This means, whenever someone leaves the company for whatever reason, his work will be allotted to coworkers. This goes on until an boss-accepted equilibrium of work quality, backlog and employee-cost is reached. Complaints about too much work will be patiently listened to. The answers are usually, "you need to better organize yourself" or "delegate more". But you don't get more hands and heads to not only get the work done but get a chance to innovate though automation, which also lowers human-induced errors.

Since no one likes to be fired, people work like mad to keep up with the all-time present and pressing backlog by just trying to keep up with the demands. Perhaps as a challenge. The overloaded techs try to make the right compromises between more backlog vs. more botching (but at least can pretend to get things done) and so a fragile house of cards is built in months and years. I'm still awaiting what happens first: Big IT bangs everywhere when the cardhouses crash. Or companies will increasingly fast running out of knowledgeable employees because everyone suffers from psychological illnesses from such an environment.

Not every company enslaves their staff like that but a general direction is visible according to statistics from health insurance companies.

Here's another one from a LinkedIn comment:

A while ago, I needed to fill one slot within my team. Got lots of nice CVs, but only one guy out of 6 was able to explain me what is an ICMP Redirect. Some people who have configured one IP interface in the area 0 think they suddenly become OSPF experts.

Based on my experience:

  1. You cannot develop your skills in switching/routing if you don't look closer at the packet flows
  2. You cannot conclude something doesn't work if you don't know how it really works ;-)
  3. As I often repeat to my Engineers, a problem description starts with:
    • What did you do?
    • What did you see?
    • What did you expect to see?
    Notice the last question... It usually reflects the expertise of the Engineer who is escalating :-)

Finally, if you need even more depressing thoughts read this.

8 comments:

  1. In the business environment, where you need to deliver something on time, you see MANY issues you simply skip. Why? Not because you are not curious but you do not have time to think about them.

    When you deliver a product you do not do all possible tests - you simply test it against requirements. You do not fix every issue - you fix only those which affect the features you deliver.

    I know that sometimes the issue you see may have impact on other parts of the network.
    TIME is MONEY. MONEY rules. Theoretically we should think think about long term goals but we don't. Quick fixes win;) Sad.
    Replies
    1. Yes, such approach is perfect recipe for "technical debt", which will require resolving at some stage. Problem is when you add such debt on top of "ways around" other problems. That ends up in messed up project, which eventually will die or will require 2, 3 and sometimes 10 times more man power to resolve or simply can't be resolved at all. Example Maximum Path Length Limitation in Windows = 260 ???????? where "NTFS supports paths up to 32,000 Unicode characters long", just simple mess in code somewhere in Windows, which can't be resolved)
  2. Yep, some people don't understand simple thing: "Do it right way" and I would add ",first time".
    But it's easier to do something, which is "kind of working" and then quietly wait for somebody, else to figure it out and fix it for you. Plain laziness mixed with lack of respect to others, closely followed by stupidity. Welcome to IT world.
    Replies
    1. Working for networking business for 25 years I am little bit sceptic about "do it right way" and "first time". The complexity is huge of the big project. We use so many devices from many vedors and want to integrate them. We see them like 'lego block' but we cannot anticipate feature interaction. At some point in the system development you see that there are more issues then we expected / seen during Prove of Concept phase. Vendor cannot something fix within our timeframe so we need to resort to quick fixes many times.

      The problem is the the World is NOT perfect. We cannot make the vendor fix something to release something on time. If we could fix all issues ourselves...
  3. Doing plain stupid things is overall bad. To search for the perfect solution may in some cases take ages and thus turn out to be even worse than a half baked thing.
  4. https://www.cio.com.au/article/65115/all_systems_down/
    lack of curiosity can lead to catastrophic outages. This isn't about resources always being limited, or there always being priorities, it's about we have smart expensive people in these roles for a reason, and that reason is their judgment (in light of both intelligence and education) in the decisions they make, whether big decisions or the day to day little decisions.
  5. The business case is king (the prince2 good stuff). An engineering department that has spent some time studying and understanding an organization's business case, model and strategy is always ahead of the feature request curve.
    If a capability request takes the department by surprise it is not part of the organization's competitive advantage.
  6. Relative to the Million Man Month book Ivan referenced in a post last year..
Add comment
Sidebar