431–440 of 564 posts
There was a point in the history of aviation where anyone who could fly a plane was also capable of constructing and designing one. I wonder if there were similar concerns at that time about a future where someone could be in a cockpit of a plane without truly understanding how the machine works from first principles? Today that type of concern would seem absurd, and we've gotten used to the idea that flying a plane…
Earlier quoted context omitted.
I completely agree here. The problem was that there was a shortage of developers, and that most universities still only had CompSci degrees, not Software Engineering degrees, coupled with those degrees were 3-4 years long... So enter the code bootcamp, where you're basically given a hammer, and taught that every problem can be solved with it.. Now those bootcamps aren't all like this, and there were and are good ones…
"and that most universities still only had CompSci degrees, not Software Engineering degrees" Is a Software Engineering degree really a thing? Perhaps outside the US? Can you point to a notable university that has this major? A quick search gives me the impression this is an online correspondence program type of thing. At UCSD in the late 90s we had a Software Engineering class but that was it. Otherwise internships…
Penn State has one.
There was a point in the history of aviation where anyone who could fly a plane was also capable of constructing and designing one. I wonder if there were similar concerns at that time about a future where someone could be in a cockpit of a plane without truly understanding how the machine works from first principles? Today that type of concern would seem absurd, and we've gotten used to the idea that flying a plane…
Mentour Pilot video on the issue: https://invidious.protokolla.fi/watch?v=e5AGHEUxLME&t=1
I think there is one interesting angle to this problem. I am someone who grew up with the technology, as the levels of abstractions were being added. I am now benefiting from all those accumulated decades of knowledge. As the IT / development world was changing, I had enormous privilege and comfort to learn the things at the pace they were happening. Being able to assimilate changes over long decades. Be a witness to…
If by "understand" you mean "have a passing familiarity with" then.. sure, but if you mean "my understanding is reflective of reality" then there's absolutely no way.
We, people who really understand the technology that the world runs on, are a slowly dying breed.
There are more people doing "low level" programming right now than were doing it a few decades ago. The only knowledge that is fading is knowledge that's applicable to legacy and/or retro systems.
There was a point in the history of aviation where anyone who could fly a plane was also capable of constructing and designing one. I wonder if there were similar concerns at that time about a future where someone could be in a cockpit of a plane without truly understanding how the machine works from first principles? Today that type of concern would seem absurd, and we've gotten used to the idea that flying a plane…
The Co-pilot of Air France 447 could fit that description. He went to fly highly automated Airbus planes as soon as possible, which means only 250 hours on different types. He didn't had a proper understanding of how stalls worked, since Airbus automation makes it almost impossible to stall the plane, unless something goes horribly wrong and it reverts to manual law, which is what happened in that flight. When the ca…
Earlier quoted context omitted.
It is not elitist to point out the flaws in modern web devs who don't know what an HTTP protocol is and the structure of an HTTP request (headers vs body etc). I interview a lot of them who cannot explain the difference between a form submitted directly vs through Ajax but they surely know how to send a POST request through node/express.
I strongly believe tech interviews should be about seeing _how_ a candidate works and less about _what they know_. Everyone has holes in their knowledge, but can easily be filled by training or on the job experience if they have excellent problem solving skills. Maybe they never needed to know the protocol level but can deliver excellent ux results regardless. I've started nearly every position in my career in a diff…
I do get your point but depends on the role you are hiring for. I have had candidates get upset at me (for example: bootcampers) because they couldn't explain how to submit a basic HTML form but wanted me to look at their github "portfolio" that was done during the bootcamp with React/Express Code and what not. Their title was "Front end React Developer". That is a problem and I usually wouldn't hire those people.
"Abstraction" is a misnomer. This word has its useful meaning in math and art, but in software engineering, all what we call "abstraction" is automation in disguise. When you write a piece of "abstract" code, you only delegate writing the piece of concrete code to your compiler or run-time type deduction. And as soon as this is clear, the attitude follows. Should you know how every aspect of your code is compiled or…
This is a useful insight, but I think that many automations really are based on solid, honest-to-goodness abstractions of the same type you would find in math. Furthermore, that's good and important! It's true that a compiler is merely translating a high-level language into the actual machine code, but it's simultaneously true that you can (generally) talk sensibly about the high-level language, and maybe even prove…
You see, there is no such thing as a "good abstraction" or a "bad abstraction". In math, algebraic systems are either isomorphic or not. There is no qualitative quality to a fact. It is only in software, abstraction acquires this immeasurable quality of goodness, or leakyness, or even fashionability.
"Automation in disguise" is not a good term either. But I find it slightly less misleading and such as it brings less false promises in the connotations.
Let's not try to excuse the mess in IT by appeals to the aircraft industry until we have a semblance of their professionalism, dedication to safety, and history of handling faults and errors and learning from the process.
Abstractions are like tech debt. When you consume an abstraction, you also get all the klocs (thousands of lines of code) that it represents, they have a price. When you have multiple sources (as in suppliers) of that abstraction this greatly lessons the risk. As does have an abstraction which is total. The post and the url reminds me of the Unix Hater's Handbook. https://web.mit.edu/~simsong/www/ugh.pdf The problem…
It’s enough to make a technologist erect a silo.
I think there needs to be a clearly defined difference here between professionals and experts. You can be a professional in the field, but until you understand all the layers of abstraction, you aren't an expert. You can't diagnose those deep problems and fix them. Professionals are paid to work in an area, and are thought to know enough not to be horribly dangerous. Experts, on the other hand, are supposed to unders…