He (she?) has a point, but I think there's a third class: the proper engineers, those that studied not only the CS stuff (albeit not to the paper writing level

He (she?) has a point, but I think there's a third class: the proper engineers, those that studied not only the CS stuff (albeit not to the paper writing level at school), but also the economics, process and financial side of the software business and related industries. Software is a team effort, and process scaling is a hard problem. There are software techniques and principles related not just to efficiency, but to protecting the code from the developers in a sense and to be able to scale the engineering team. There are error reduction strategies that make code more resilient in large code bases and easier to update. These strategies, when used properly, help fight Conway's law and a pure CS background usually doesn't focus too much on them. Understanding and managing risk, decision making in the absence of perfect information, etc. are skills that engineers are trained for that I've found that pure CS backgrounds struggle with. They eventually learn it, but it takes them a couple of years to grasp that the problem is there in the first place (to be fair, even trained engineers struggle with the finer points). In any case, whatever your background you still need to be able to handle the trifecta: - business - science - tooling if you really are to excel at it and regardless of your background to keep perfecting yourself is sound advice.