I've worked with all kinds - from windows devs who can't figure out how to install visual studio - to people who understand Windows, Linux, and macOS - as well as basic system administration for each platform. The people who are most successful at rapidly developing good high quality software are more in the later group.

Would you trust a RF engineer who couldn't troubleshoot his own radio designs? why would you troubleshoot a software engineer who can't troubleshoot his own software as deployed in a real world environment?

I feel the same. Someone who isn't willing to investigate issues with their own work machine or spending some time configuring it is more likely than not to be less of a continuous learner (imo).

Looking at it short term a well paid developer troubleshooting all issues on their work laptop could be seen as a waste of resources but for me software development is a beautiful craft. I also wouldn't trust a carpenter who can't obsess over wood or tools. If I overhear two developers comparing notes on their tmux setup somewhere I mentally upgrade them into the interesting category right away.

I recently questioned someone about this very subject. They wanted to hire a "CSS expert" because the "developer" didn't have a grasp of css after having developed the project in JS/HTML. I was so confused as to how that's possible.

There's a large gap between basic understanding of CSS and actually creating good CSS. Personally I avoid touching CSS as much as possible.

I suck at CSS and do a lot of js/html, but most of my work is on the back end. I can do ok with CSS but it will definitely take me longer than someone who knows what they're doing. Usually we contract out the design/CSS for a few pages and I adopt that for the rest of the website.

CSS is not consistent and complete like a programming language. As someone else mentioned, doing things the correct way in CSS (responsive, cross-browser) is actually very hard, and often requires memorizing weird hacks.

In fairness to the folk who can't install Visual Studio - it's a genuine pain in the butt.

Last time I tried, half of the download links were absolutely non-functional. Their documentation didn't help much, either, since they pointed to the non-functioning links. I got a lot of shit for that one, but felt completely vindicated when it happened to someone else a year later.

> In fairness to the folk who can't install Visual Studio - it's a genuine pain in the butt.

It takes a while but I've never found it to be a pain in the butt and I've used it, off and on, since version 6 in the late 90s.

If the install errors out it gives you an error message, you google for it, figure out what the problem is (most common messages are easy to find solutions for), fix the problem, reinstall, done.

Then you were lucky.

I remember on the first day of a new job being given a folder containing all the MSDN subscription disks in the mid-2000s and being told to install visual studio.

I'd only ever used notepad as an editor before.

This is a massive stack of DVDs with multiple disks, but worse there are a bunch of cds listing different versions of a thing called "visual studio".

After 15 minutes of struggling and surreptitious googling because I didn't want to look stupid on my new job, a colleague walked by, went "oh", picked out the right disk and said "that's the one you need". And I had to do the same for multiple new starters.

Even today when you have to install something from MSDN, you search for "Office" and get a bunch of irrelevant language packs listed at the top which is definitely not what you want, then also have to know what x86 and x64 means, something a novice will not know, and know what "SP" means and that "SP2" is better than "SP1".

> Then you were lucky.

I worked in 3 Microsoft dev shops and 1 that had a mixture. As far as I know I hadn't heard of anyone having issues getting it installed except for the rare, occasional error that could be Googled and fixed. I'm not sure I'd call that luck, sounds like you just had a bad experience.

But yeah back in the day it was a stack of discs (I think the last disc version I used had 2 discs for visual studio and 4 for the msdn) but they were always clearly labeled. One for Visual Studio, one for additional add ons and stuff and the rest for MSDN documentation.

¯\_(ツ)_/¯

There were 40 DVDs in a MSDN subscription in 2004, so not sure what you're talking about, you might have had the cheapo one?

I've worked on VS since VS 2003.

The first versions (200X) had some challenge at times. Starting from locating the installer for the right edition and the license. Then minimal setup to have a working environment was split in 5 different installer/projects to be executed in orders (one VS pack per language + the Windows SDK + the debugger kit + the ATL/MFC package + the driver kit [if you dev drivers] + the DirectX SDK [if you need it]). Then configure some PATH and libraries to link together all of that.

Last I checked, in 201X editions. A lot have been regrouped in a single setup. That's enough for most developments. And the optional packages have auto detection (and it ain't fucked it you run it twice).

OHHH

So the MSDN subscription is different. The MSDN subscription is the full Microsoft catalog of software. Every version of Visual Studio, every Windows, Office, MSDN documentation; it's literally everything.

The parents above were talking about just installing Visual Studio. When you purchase Visual Studio it was usually 2-6 discs in my experience (most containing the MSDN documentation). But the MSDN subscription is a very different beast. Granted there should have still been a Visual Studio disc for a specific architecture that you were using and your group should have known if they're using Professional, Team, etc as you'd likely need the same.

That was a fun misunderstanding though :)

MSDN subscription has (almost) all Microsoft software - its tangential to Visual Studio. MSDN Documentation is seperate and was only a few CDs.

`choco install VisualStudio2015Professional`. ;)

After all--we're all developers. Automate!

I'm a quite good programmer who is a pretty terrible sys admin.

Of your 11 points, I understand 1-10 quite well, but I'm not great at 11.

I think the skill sets are quite different, despite the fact that a lot of people have both. I was never really that "into computers", but I have a burning passion for building large software systems fast and well.

Metaphor: I love to travel to exotic locations across the planet. That doesn't mean I'm also interested in building airplane engines.

To be clear, I'm not bragging. It would be great if I was good at this stuff.

I don't think the OP is talking about low-level OS stuff like perhaps a flaky hard drive, but about installing the things that turn a vanilla machine into your working environment, plus being able to sort out things when something goes wrong with that environment. If you're in IDE Foo all day every day, you should know your tool enough to fix it when it goes wrong.

I've not had them myself, but I have talked to other sysadmins who've had devs that couldn't install their own IDE. These people weren't seniors, admittedly, but they were still drawing pay...

> the difference between virtual memory and physical memory

For my defense (I'm a dev), OSes don't make it clear. Mac OS becomes extremely slow when I load a big virtual machine and yet displays "Swap 450Kb, 500Mb RAM free". Or with a sole text editor open after a long session it may say "Swap 750Mb". In both cases my logic tells me the swap and free memory should display the opposite, so I can't match my knowledge with the OS behaviour. Then comes Java which adds another layer of memory limitations.

> how many devs deal with such a level of ignorance

I can talk because I was 4 years ignorant, then met the right teams. It's impossible to learn and gain trust in your learnings if you start ignorant, and ignorant devs know it. We constantly need help and don't understand how ticking a weird checkbox in Eclipse makes the compilation different: Without directly executing the original command line, you can't learn anything, and architects in those kinds of companies give you too many proxy tools ("SDK") that you can't improve. You're on an old 14" screen anyway. Also, Windows is so inconsistent and weird that you just assume sysadmin is for people from another planet. My skills only took off 4 years later when I installed Linux, then Mac, and was thrown in open-source libs. It was so easy, in retrospect, and I'm so happy having been in the right context.

It's more than just swap. Second answer has more detail: http://stackoverflow.com/questions/4970421/whats-the-differe...

Udacity has a pretty good OS summary course. I had personally forgotten what a TLB was until I watched watched it.

The list of things to learn is endless. The only way we can get anything done on a daily basis is to gloss over the magic being done somewhere else in the system.

But most of the outstanding ones are renaissance people.

> The list of things to learn is endless.

yes, however there are items that are more important (ACLs, AD, Security, OID ... etc) that are a little more important than the new shiny JS framework.

I'd rather burn brain cells learning Haskell than trying to understand why so much effort is being spent on JS.

I've been a consultant on large projects and the vast majority of money that I've seen flushed down the toilet was on

1) Building the wrong piece of software/end-users not having enough influence on what get's built.

2) Lack of delegation, having people make technological/feature decisions about a product they only spend 5% of their time thinking about.

3) Organizational incentives not aligned correctly.

4) Not following software engineering principles that were discovered in the 70's(they also don't follow any software engineering principles discovered since then, but I'll give them a pass)