[FlyingSnake]

This is what you get when you commoditise Computer Science. The article is about coding interviews and then goes on to deliver a lecture about "Computer science in plain English". Isn't it common knowledge that Computer Science and coding are like chalk and cheese?

People used to study DataStructures for a whole semester to get a deep understanding of how these work, and the time/space complexities affect system design. But now we get a pop-culture laced listicle that people will use to ace the interviews and write mediocre software. Does anyone wonder why there aren't listicles like this for Structural Engineering/Thermal Power Engineering/Mechanical Engineering etc?

No wonder we get data-breaches, password leaks, system outages, because we continue to treat Computer Science/Software Engineering as the next fad to make quick buck, and not science.

</rant>

[sgt101]

It isn't science, or engineering, because many of the things that count in computing defy measurement :

- code quality - software productivity - expected time between failure - tolerance to error - expected life in field - usefulness to users

Because the science and engineering cultures of computing have failed to address these effectively, or even create cultural norms that support their development, a craft culture has evolved instead. Coders are artizans rather like clock makers in the 16th century.

[FlyingSnake]

> Because the science and engineering cultures of computing have failed to address these effectively

That doesn't automatically make coders 'Artists'. There is a huge gamut of software outside the CRUD world of HN. Software that runs mission critical applications like Mars Rovers, power plants, Public transport systems, etc. We should have a fair amount of rigour to ensure the software being written is rock solid, and taking shortcuts to learn basics of CS is bad.

[sgt101]

Artizans, not artists. But I agree with your point, failure to understand hashtables is like failure to understand the secret nail in carpentry (I choose this as I've never understood the secret nail in carpentry and therefore do not count myself much of a carpenter).

We shouldn't delude ourselves, software (at the moment) is a craft discipline and craft disciplines can have huge blind spots. Comp-sci needs to spend real effort on the hard to do questions like working out how to make systems usable and other corner cases which are ignored in favour of reams of papers about verifiability and modular composition; note I am not against this work, but I just don't think it should be funded while the experience of watching a six year old trying to use google or a mac is as humiliating (to a professional) as it currently is... and boy is it.

[FlyingSnake]

My bad, I misinterpreted your comment.

I second the artisanal mindset that you have elaborated, and it will be better for everyone if we adopt the craftmans mindset (Which Cal Newport also talks about). I personally feel that we should model Software Engineering like the Apprenticeship model in Germany. It would be interesting to see how it fares.

[ethbro]

I had someone reply to one of my comment that they 'didn't know about the Vietnam War because they weren't born then'.

... I feel like our discipline suffers from a lot of the same problems. IBM mainframe experience doesn't translate into knowing the intricacies of React, but it does provide wisdom on systems and usability problems people coding in React are going to run into too.

Glorify the new, but be informed by that which came before. Otherwise doom, repeating, etc.

[btschaegg]

Not that I'm disagreeing with you there, but I've also seen the opposite. I've had conversations with people who know their mainframe environment inside out but have no idea how a modern computer really works.

I'm under the impression that it often comes down to a combination of Dunning Kruger and a certain unwillingness to inform oneself about "new" things (i.e. things one doesn't know about yet) - and those seem to exist in both camps. So, just maintaining Aristotle's mindset and keeping an open mind seems like a good starting point to me in that regard.

[sgt101]

quite so.

[sheldor]

Nailed it. I have a very hard time explaining to my youngster colleagues that they're neither "engineers" nor "scientists'. Now I can use your words.

[watwut]

Job offerings look for "engineers" while they mean coders. Young person who think he/she does not count as engineer will pass over that job, despite being fully able to get it and work there. "You are not actually engineer" is bad advice in current job market.

(I used to be that young person and used to pass on opportunities because of superficial reasons like that.)

[sheldor]

-

[watwut]

Better for competition who gets the job with the same qualification and skills maybe, better for you personally (in both terms of what you learn and how good jobs you get) - no.

[sheldor]

-

[JustSomeNobody]

I have an actual engineering degree and write code that controls some sophisticated hardware. Am I allowed to be called an engineer and not an artisan or whatever?

[CodeMage]

As my dad always says, "you can call me a jar, as long as you don't smash me to bits". Since Slavic proverbs don't always translate well to English, it might be best to clarify: what you call yourself is not as important as what you do.

What @sgt101 wrote about measurements is an important and insightful point. Does it mean we can't call ourselves engineers? That's a discussion that won't be resolved any time soon. Personally, I care more about the job itself, than about the label you slap on it.

[jaggederest]

I don't even have a degree and I write web stuff and I still call myself an engineer.

We "design, construct and test structures, materials and systems while considering the limitations imposed by practicality, regulation, safety, and cost."

Anyone who doesn't take a systematic approach I suppose might be an artisan, but the vast majority of software engineers I've worked with in my career at least attempt to use a systematic approach of learning and building processes.