5 ms·

I think his point was that some very important software might end up being written by those people who could not grasp the fundamentals of CS. I've seen recursi

I think his point was that some very important software might end up being written by those people who could not grasp the fundamentals of CS. I've seen recursion fail to fit into the minds of some otherwise very bright individuals. What I'm not entirely sure of is that decent financial/industrial/important software can't be written by someone who can't write an algorithm to sort an array. You don't need to know much CS to call array.sort(), only that you want the array to be sorted. Now this level of engineer might not know what to do if it doesn't work (or worse, works but badly) but if he's got enough domain knowledge otherwise, he'll know to spend some money on a few high dollar hours with someone who can fix it. I'd rather have someone who's a very good EE who didn't quite grok recursion working on my power grid software than a very good programmer who can't tell an amp from a volt. At least the EE can tell when its broken. The author was surprised that candidates came to him with actual accomplishments on their resumes but didn't seem to know the basics of CS. My counterpoint was that its probably possible to accomplish quite a lot without knowing the basics these days, and if you do it cheaply, that might be just fine.

Detrus 17y ago
Yea, there's a big trend in programming to make it simpler, frameworks and languages that let you get more done while thinking about less. It's suddenly important to understand the underlying principles? I don't think that message will get through with those distracting frameworks everywhere.
biotech 17y ago
"I'd rather have someone who's a very good EE who didn't quite grok recursion working on my power grid software than a very good programmer who can't tell an amp from a volt. At least the EE can tell when its broken." A great deal of terrible, buggy, unmaintainable software has been written due to exactly this type of sentiment. I have maintained, re-written, built on top of this type of software. The correct way to build power grid software (or any science/engineering-related software) is by having very smart software engineers (who do understand or can quickly figure out things like recursion), working closely with electrical engineers (or biologists/chemical engineers/etc). As in, they should be in constant (at least weekly) contact with each other. The software engineers learn about electricity, and the electrical engineers learn a little about software architecture. This is based on my experience developing software for engineering applications. I currently work on software in the Aerospace industry, and I communicate regularly with other engineers. My software team is full of brilliant software engineers. Smart people can learn about other fields on-the-job. If you accidentally hire one that can't, don't fret: there is always work that doesn't require an intimate knowledge of electronics, such as build scripts, support software, utilities, etc. That being said, I do think there is a place for a software engineer with a passion for other types of engineering. My degree is in Bioengineering, but my greatest experience (and greatest interest) is in software engineering. So, while I grok differential equations, control systems, and metabolism, I also understand recursion and polymorphism. And deterministic finite automaton. And closures. And I'm not the only one. My point is this: If you have a really hard engineering problem that requires really smart software, hire really smart programmers, really smart engineers, and a couple really smart people who understand both sides. Like me!

Detrus 17y ago

Yea, there's a big trend in programming to make it simpler, frameworks and languages that let you get more done while thinking about less. It's suddenly important to understand the underlying principles? I don't think that message will get through with those distracting frameworks everywhere.

biotech 17y ago

"I'd rather have someone who's a very good EE who didn't quite grok recursion working on my power grid software than a very good programmer who can't tell an amp from a volt. At least the EE can tell when its broken." A great deal of terrible, buggy, unmaintainable software has been written due to exactly this type of sentiment. I have maintained, re-written, built on top of this type of software. The correct way to build power grid software (or any science/engineering-related software) is by having very smart software engineers (who do understand or can quickly figure out things like recursion), working closely with electrical engineers (or biologists/chemical engineers/etc). As in, they should be in constant (at least weekly) contact with each other. The software engineers learn about electricity, and the electrical engineers learn a little about software architecture. This is based on my experience developing software for engineering applications. I currently work on software in the Aerospace industry, and I communicate regularly with other engineers. My software team is full of brilliant software engineers. Smart people can learn about other fields on-the-job. If you accidentally hire one that can't, don't fret: there is always work that doesn't require an intimate knowledge of electronics, such as build scripts, support software, utilities, etc. That being said, I do think there is a place for a software engineer with a passion for other types of engineering. My degree is in Bioengineering, but my greatest experience (and greatest interest) is in software engineering. So, while I grok differential equations, control systems, and metabolism, I also understand recursion and polymorphism. And deterministic finite automaton. And closures. And I'm not the only one. My point is this: If you have a really hard engineering problem that requires really smart software, hire really smart programmers, really smart engineers, and a couple really smart people who understand both sides. Like me!