[oaw-bct-ar-bamf]

Sometimes the Root cause for problems is buried one or two abstraction layers deeper than the "responsible team" is comfortable to work at. This is where the "lower level" expert comes into play.

At my place the abstractions start at high level user facing code, reach down into the hardware interface (driver) code and down to the actual electronic circuit design.

EVERYWHERE something can go wrong. In case the circuit deteriorates too fast you need to get the material analysts to "debug"

Rule of thumb is: there is always one layer of abstraction below you where stuff can break which feels like magic to you but is fixed with a glimpse from the lower level guy

[g051051]

I've just always considered understanding and being able to debug your environment to be a standard part of the job. As a professional software developer working in a Solaris environment, knowing how Solaris works, how to use the shell, tools, and other stuff is just basic.

Back in the 90's I worked at a company doing development on HP Apollo workstations. They were X based and used CDE for the desktop environment. When I started there, I invested some time to learn how it all hung together, how to leverage ToolTalk, and customized my system to do cool stuff.

There was another developer who had started there a month before me, and had the same workstation. They had a problem one day that they wanted my help with, so I went to their desk for the first time. I found their screen had the default X stipple pattern, and a single terminal window 80 characters wide, maybe 2/3rds of the screen tall, and placed somewhat off center in the screen.

I thought it slightly odd, but was distracted by the problem at hand. So at one point when they had some code up in the single window in vi, I asked them to open another terminal so we could do some other stuff. They just sort of sat there, so I asked again. They got agitated and snapped that they didn't know how to do that.

This was a professionally employed C programmer, with several years of experience prior to this, who had been working with this equipment for several months, and _didn't know how to open a second terminal window_. They didn't have CDE running, because when you log in you can select your desktop, and they kept picking just a plain, raw X session with the default xterm. They were completely and utterly uninterested in the capabilities of the hardware, OS, and desktop environment.

The same goes for the issue with the crashing JNI driver in my other comment. Maybe you don't know how to write your own JNI stuff, but I just expected that any developer who'd been using Java for any length of time would at least _know_ about how the JVM works in general, and what a coredump means in the context of a Java program. Specifically, that it's not your software that's causing it, and that trying to fix it by rewriting and debugging your Java code is a waste of time.

[oaw-bct-ar-bamf]

Sadly the vast majority of developers might know that there is a tool called debugger and might also know how to set a breakpoint. But that’s where it stops. No drive to see what your debugger offers you. callstack? what’s that? Conditional Breakpoints? Huh?

I hope that instead of aiming further down the abstraction layers, they instead aim up and try to get the hang of macro level stuff, metaprogramming, abstractions which I most often put off as "that’s just a fad"

If something like containerization or container orchestration sticks around for 5 or 10 years I'll maybe take a proper look at it.

Until then it is ‚just a trend‘ and takes mental space I feel spent better digging down. Because that’s where software is interacting with hardware (the real world). That’s the abstraction layer where you can 'actually move the world', where goods are created.

Not everybody is capable or experienced enough to move across different abstraction layers and have a proper mental models for each. SOMEWHERE you will probably have to draw a line.

Some people draw the line at 'writing software'. Execution target (understanding the hardware / runtime) are out of focus for effectively all programmers. I think partly because languages, tutorials, bootcamps don't bother to dig deep there because 'the compiler will take care'.

It just is not teached that way. What do you mean with Solaris? Sun? PDP? It is just a computer. Java is cross platform. How it does that? Thats the JVMs job, not my job. I just write the software.

[toast0]

> I've just always considered understanding and being able to debug your environment to be a standard part of the job. As a professional software developer working in a Solaris environment, knowing how Solaris works, how to use the shell, tools, and other stuff is just basic.

If this was a standard part of the job, it wouldn't be my superpower. Working in a team where everyone (or almost everyone) can debug is amazing!