The problem is most people get abstractions wrong. Abstracting too much can lead to Architecture Astronauts. (https://www.joelonsoftware.com/2001/04/21/dont-let-architect...) And not abstracting enough can be a mess in your code and make a product dull.
By focusing too much on abstraction, you’ll get a really lopsided team. And remember it only took one really abstract thinking Willy Wonka and a bunch of oompa loompas to make really great candy. Too many Willy Wonkas and nothing would ever get done.
Lastly, most people only get abstractions right with experience. So there is still some value in experience.
I often get abstractions wrong the first time through. Usually the second or third attempt (often days later) I'll come across something concrete that can be put into production. So while I agree abstraction in and of itself is not a silver bullet, the ability to iterate on abstraction(s) is immensely valuable.
Also the plain desire to seek a better abstraction despite a "working solution" is a powerful trait when kept in check. The desire to continually do better that is.
remember it only took one really abstract thinking Willy Wonka and a bunch of oompa loompas to make really great candy
An interesting difference between software and mass-produced physical goods is that a single Willy Wonka can do a fair without needing oompa loompas. It’s not an especially fashionable way of doing things right now, but don’t dismiss the possibility.
> Ideally all our interview problems should be built in a way that even a non-technical person with highly developed abstract thinking could answer.
why is this any kind of ideal? What about reality?
> your current technology stack is also irrelevant, the right candidate with great cognitive capacity will be able to adapt fast, pick up new things and bring new ways and ideas, breaking your team’s or company’s tunnel vision. Their fluid thinking and almost extreme ability to identify and extract patterns will exceed anything you have expected.
Hire a superstar that will steamroll your existing developers - great advice. Let's not worry if they're collaborative.
> I can’t stress enough that hiring based on your current technology stack or domain is extremely wrong. Never do it. Never. If the only reason you are bringing on board new developer because he has a lot of experience in your domain or with the CMS, programming language or framework that you are using, then you are making a kind of mistake it is very hard to recover from.
don't hire them for any real reason you might have? Sounds like real sage wisdom.
This post is classic silicon valley. Out of touch with reality, and discriminatory towards diversity. People are different. No person is more than one person.
I have a lot of experience with hiring software developers. This is mostly drivel.
You want to hire talent? Offer good pay, interesting work, and freedom to do it. That's step one. Step two is finding people who can do the work in the given domain(s) of your organization, and step three is finding people who can do said work with your team. There is no step four.
> You want to hire talent? Offer good pay, interesting work, and freedom to do it.
How about just offer good pay and don’t pretend like email archival or configuring LDAP or trudging through poorly-designed databases is sexy, exciting work because it isn’t?
Bad news: most work isn’t interesting, and I absolutely loathe when companies, even “exciting” startups that are “changing the world”, pretend that configuring their Jenkins server is somehow life-altering, fulfilling work.
Most work isn’t interesting, and that’s fine. I don’t mind configuring Jenkins, or setting up LDAP, or fixing crappy databases, or writing Yet Another Feature. I’m good at those things, and a job well-done is certainly satisfying, but let’s not pretend that my 9 to 5 is anything more than a job. I get excited about my job like I get excited about going to the dentist: it’s something I have to do to maintain a good life, and while I am certainly more than willing to do it, I don’t try to pretend like it’s particularly fun or special.
I think the topic is more complex than just finding an oompa-loompa for your current technology stack. If you think about long-term benefits for the team and company as a whole, it will be highly beneficial to bring highly able, rational and driven people on board.
I'm guessing what you probably have in mind is consultancy, where you need a highly specialized individual to complete this, one, particular project, which is very different from full-time employees.
Also we need to carefully start destructing and eliminating this stigma around people who are being perceived and labeled as "superstars". Great mental capacity and ability does not imply bad social skills. This marginalization hurts the industry.
Great note about collaboration! This post doesn't cover an entire hiring process, just one aspect of it. Collaboration and communication skills are definitely a must.
>> You want to hire talent? Offer good pay, interesting work, and freedom to do it.
As someone who has hired a lot of people and offered a 1M+ salary to some of them, they'll take your salary and start their own business with it. Pay what market will bear, never regret again. People are not that loyal no matter what you pay. Even if you pay someone lot more than what they worth, they'll attribute it to their talent and will never feel indebted or loyal to you. (as you might be thinking).
Perhaps I'm misunderstanding what the author means by "no connection to the real world", but good abstractions should be deeply connected to reality.
Wikipedia describes abstractions as:
> a conceptual process where general rules and concepts are derived from the usage and classification of specific examples, literal ("real" or "concrete") signifiers, first principles, or other methods.
> Conceptual abstractions may be formed by filtering the information content of a concept or an observable phenomenon, selecting only the aspects which are relevant for a particular subjectively valued purpose.
"Being abstract is something profoundly different from being vague … The purpose of abstraction is not to be vague, but to create a new semantic level in which one can be absolutely precise." - dijsktra
OP is confused about what abstraction is actually for
If somebody cannot abstract, then they will not be a good software developer, period. Code will be copy-paste, genetically engineered, and not understood even by the author why it does or does not work, meaning an inability to document it or even explain it to coworkers.
Assuming people can keep fully in mind about 7-10 things at once, a person who can abstract can keep entire constructed systems in mind as one of those "things". A person who cannot abstract will only be able to hold that many immediately tangible source-code level concepts in mind, having a hard limit on the amount of complexity they can have in their projects before their mental organizational capabilities collapse, in the same way people throw up their hands and give up at math problems that are beyond them.
It's a necessary but not sufficient skill; as you mention, social tuning and business mindedness tend to round out effectiveness from just raw skill.
And if somebody's being an Architecture Astronaut in their "abstraction", then they're not abstracting what they're doing in context of making a workable system; they're just rote copy-pasting architectural memes that they think matches a pattern, just like the ineffective programmer.
Lots of jobs can be considered a social activity, including programming, but at the end of the day empathy and psychology aren’t going to write your code.
I think there can be different reasons to hire someone.
If I'm running a project and I'm having all kinds of problems to get my node.js performance to an acceptable level I'd look for a programmer that knows how to tweak node.js and all parameters associated with it (scripts, server, OS).
If I'm starting a project and I already have a node.js specialist aboard and I need to hire someone for the long term I can basically hire anyone with the right talents.
But it's a very different story depending on the parameters.
I generally agree with this article and wanted to just post some thoughts I’ve had on this when it comes to hiring juniors out of boot camps when the expectations of CS knowledge would be tough.
1. I think they need more than 1 project, either in your domain or multiple domains better yet. To me this is one way of demonstrating abstraction capability.
2. Ask a problem that involves modeling several objects where a hierarchy might be involved. Ie modeling a service like Instacart, that has both customers and employees, but maybe are all types of Users. Do they catch on to these common traits? A question like these can even extend to more senior roles it may just be a matter of how much hinting.
3. I still believe some sort of whiteboard challenge has value, but make it fair. A lot of O(n) type problems are straight forward looping over array and doing work type things. These aren’t killer gotcha problems intended to haze or assess depth of CS skill, they are for stimulating dialogue. I was anti whiteboard for a while, particularly because I felt like I was hazing, even when I gave lots of time and did everything I could to make the candidate comfortable. But without it I feel something is missing. So my new principle is just don’t make it tricky.
> [not] intended to haze or assess depth of CS skill, they are for stimulating dialogue
This 100%. We do an in-person 'pairing exercise' where they work on a simplified tax calculator. We expect people to solve the problem, but really what we're looking for is their thinking and to see _how_ they solve it. By gradually ramping up the requirements/difficulty, and by asking more questions we're able to learn a lot about the applicant.
Funny, I see where the author is coming from and agree to an extent: capacity for abstract thought is marked by ability to mentally manipulate concepts, not things.
But in software engineering, I think the ability to analyze the information which constitutes a domain and then synthesize ergonomic abstractions out of that information is more relevant. Martin Fowler would call it domain modeling, I just call it software design.
Of course I also obsess over names of things, interface design, and mental models, so I’m biased!
I have done countless developer interviews. I did bad hires and made good hires. Two things I learned:
1. Get them to write code (using their language of choice and google searches allowed when stuck)
2. Did they do any projects on the side?
A lot of people who sound great on paper can’t write code. Or write shitty code. People who are passionate about their work read a lot and do side projects.
Side projects are not a reliable metric. I have worked with fantastic developers -- ones who I'd love to work with again -- who did not do side projects.
These were generally people who did really great work while using normal hours, but who would put in the hours when necessary, such as during a deadline push. Often their organizational skills and general engineering hygiene helped keep the crazy hours at bay.
At night these people went home to their families and led their lives. Some were good woodworkers or were into other hobbies, some did sports, some taught classes. Oh, a few wrote code [I do], but not that many.
Don't get me wrong: Side projects can be an interesting window into how a candidate works and thinks. But if you use them as a hard requirement then I'm pretty sure you're missing out on some great talent.
I've loved to code since I learned how on my C=64. I don't have a github full of side projects. The code I write at home is one off stuff for learning and keeping up, not some rehash of "twitter in a weekend".
Some company that doesn't want me because I don't have side projects, that's fine, they saved me the trouble.
Side projects are the "White privilege" equivalent of developer culture. The only ones who can do them are young, super-passionate programmers who have a lot of time on their hands. If you have a passionate social life, external interests besides coding, or a family, your time and energy are severely limited.
I never, ever ask for side projects because it biases for younger programmers with lots of time and against all others.
The ability to abstract surely is important. However, I find the "four levels" a little strange. The first three aren't even abstractions! Abstract is the opposite of concrete. Abstraction is by definition not a concrete object.
And there's at least one extra level: the ability to think about things that can't be imagined.
It's not that difficult to visualize a hyperbolic plane and learn to visualize hyperbolic space. It's much, much harder to visualize the real projective plane, and essentially impossible to visualize a quaternionic projective space. Yet these can still be worked with using geometric and topological intuition in a way that feels (to me) fundamentally different from manipulating abstract formulae or matrices.
The author of the article has enlarged the meaning of the word abstraction. It's just the wrong definition. It would make more sense if he described it as 'important cognitive skills'.
My definition of abstraction is moving from specific examples to more general systems. I definitely remember the process as I was teaching myself programming through my childhood of learning and improving my software abstraction skills in particular ways.
One type of abstraction that took a bit of practice to get good at when I was starting out like eight years old was recursion. I got better at using this type of abstraction by specifically practicing with the goal of converting loops to recursion.
Another type of abstraction is creating classes in order to reuse your code. This was something I learned about and gradually got better at over the years through practice and initially from a few books like Turbo Pascal Disk Tutor when I was in middle school.
Sure there are some innate abilities but I think it's not quite so cut and dry as the author makes it out to be with innate versus learned ability.
I was thinking something similar. The first few levels of "abstraction" seem to me to be more about visualization skills and spatial reasoning. For example, we'd expect a painter to be particularly good at those, but not necessarily good at math or monads. The 4th level seems like a totally different kind of category from the first three.
Which, come to think of it, matches my personal experience. I have zero spatial ability---back in the 80's in California they actually gave us standardized tests in elementary school including a spatial ability section, and my scores were always like 90+%-ile math, verbal, and like 20%-ile spatial. Never been able to draw for shit. But was always advanced in math, 99th percentile lsat (logic-heavy) scores, top grades in stats, etc. So am I at the 4th level but not at all at the first three?
Just have a senior software engineer or two supervise mathematicians (or to an only so slightly lesser degree, physicists). The latter are excellent at abstraction, usually pick up programming languages in no time, and can readily get steered towards using software best practices by their senior peers provided the latter can articulate a rational explanation as to why this or that best practice is just better.
I hope you're joking. I've worked with these kinds of academics and while they tend to have excellent capability for abstract thought, they also tend to not give a shit about practical matters like usability or even just shipping code.
If you step back for a moment it will be obvious that the idea that experience is worthless is just plain wrong. Many times I have had to deal with the work of supposedly genius coders that is either a complete reinvention of some standard way of doing things for no benefit or overly complicated because they weren't aware of known simpler solutions.
A humble strong programmer who stands on the shoulders of the aquired knowledge of their whole industry and has learned from his failures and successes will always beat the arrogant but naive 10x super abstracting genius.
Aren't ability to abstract and experience sort of similar? I don't really consider the ability to write a generic function (instead of copy-paste) to be the same as the ability to abstract. To write a good abstraction you need to understand both the underlying system and the consumption pattern to avoid abstraction leaks, boilerplate, hiding of useful features, etc. You can't really be sure that you're writing a good abstraction without at least having some idea of what are alternative approaches and what are their strengths and weaknesses.
Does every discussion on hiring need to turn into discussion about 'ageism' ?
"I want to say that I can’t stress enough that hiring based on your current technology stack or domain is extremely wrong"
"This is especially useful when you are hiring junior developers. You are not looking for hard practical skills, instead you are looking for the potential."
Experience is not worthless but it doesn't necessarily correlate to skill. I've worked with developers who have been at it for 25 years who were mentally inflexible and wrote awful, un-maintainable spaghetti code. I've also worked with experienced older devs with astonishing skill levels.
I see abstraction as the ultimate misconception of modern software engineering / development.
There's so much abstraction nowadays, software developers have not the slightest clue what they are doing anymore besides copypasting some framework.
We're basically at the point of developers competing in abstraction without any fundamental understanding. "I can do this with only two lines of code."
In terms of the article, those people getting hired, are not necessarily the ones especially good at abstraction. They just have experience in what others have abstracted for them, to use as a tool.
[+] [-] cyberpanther|8 years ago|reply
By focusing too much on abstraction, you’ll get a really lopsided team. And remember it only took one really abstract thinking Willy Wonka and a bunch of oompa loompas to make really great candy. Too many Willy Wonkas and nothing would ever get done.
Lastly, most people only get abstractions right with experience. So there is still some value in experience.
[+] [-] ben_jones|8 years ago|reply
Also the plain desire to seek a better abstraction despite a "working solution" is a powerful trait when kept in check. The desire to continually do better that is.
[+] [-] heisenbit|8 years ago|reply
- Ability to abstract.
- Ability to communicate their abstraction.
- Ability to reuse abstractions.
- Ability to accept and work with colleagues abstractions.
[+] [-] dasmoth|8 years ago|reply
An interesting difference between software and mass-produced physical goods is that a single Willy Wonka can do a fair without needing oompa loompas. It’s not an especially fashionable way of doing things right now, but don’t dismiss the possibility.
[+] [-] meesterdude|8 years ago|reply
why is this any kind of ideal? What about reality?
> your current technology stack is also irrelevant, the right candidate with great cognitive capacity will be able to adapt fast, pick up new things and bring new ways and ideas, breaking your team’s or company’s tunnel vision. Their fluid thinking and almost extreme ability to identify and extract patterns will exceed anything you have expected.
Hire a superstar that will steamroll your existing developers - great advice. Let's not worry if they're collaborative.
> I can’t stress enough that hiring based on your current technology stack or domain is extremely wrong. Never do it. Never. If the only reason you are bringing on board new developer because he has a lot of experience in your domain or with the CMS, programming language or framework that you are using, then you are making a kind of mistake it is very hard to recover from.
don't hire them for any real reason you might have? Sounds like real sage wisdom.
This post is classic silicon valley. Out of touch with reality, and discriminatory towards diversity. People are different. No person is more than one person.
I have a lot of experience with hiring software developers. This is mostly drivel.
You want to hire talent? Offer good pay, interesting work, and freedom to do it. That's step one. Step two is finding people who can do the work in the given domain(s) of your organization, and step three is finding people who can do said work with your team. There is no step four.
[+] [-] throwawayeoi9|8 years ago|reply
How about just offer good pay and don’t pretend like email archival or configuring LDAP or trudging through poorly-designed databases is sexy, exciting work because it isn’t?
Bad news: most work isn’t interesting, and I absolutely loathe when companies, even “exciting” startups that are “changing the world”, pretend that configuring their Jenkins server is somehow life-altering, fulfilling work.
Most work isn’t interesting, and that’s fine. I don’t mind configuring Jenkins, or setting up LDAP, or fixing crappy databases, or writing Yet Another Feature. I’m good at those things, and a job well-done is certainly satisfying, but let’s not pretend that my 9 to 5 is anything more than a job. I get excited about my job like I get excited about going to the dentist: it’s something I have to do to maintain a good life, and while I am certainly more than willing to do it, I don’t try to pretend like it’s particularly fun or special.
[+] [-] rinchik|8 years ago|reply
I think the topic is more complex than just finding an oompa-loompa for your current technology stack. If you think about long-term benefits for the team and company as a whole, it will be highly beneficial to bring highly able, rational and driven people on board.
I'm guessing what you probably have in mind is consultancy, where you need a highly specialized individual to complete this, one, particular project, which is very different from full-time employees.
Also we need to carefully start destructing and eliminating this stigma around people who are being perceived and labeled as "superstars". Great mental capacity and ability does not imply bad social skills. This marginalization hurts the industry.
Great note about collaboration! This post doesn't cover an entire hiring process, just one aspect of it. Collaboration and communication skills are definitely a must.
[+] [-] xstartup|8 years ago|reply
As someone who has hired a lot of people and offered a 1M+ salary to some of them, they'll take your salary and start their own business with it. Pay what market will bear, never regret again. People are not that loyal no matter what you pay. Even if you pay someone lot more than what they worth, they'll attribute it to their talent and will never feel indebted or loyal to you. (as you might be thinking).
[+] [-] IncRnd|8 years ago|reply
Quoted for truth.
[+] [-] dwaltrip|8 years ago|reply
Wikipedia describes abstractions as:
> a conceptual process where general rules and concepts are derived from the usage and classification of specific examples, literal ("real" or "concrete") signifiers, first principles, or other methods.
> Conceptual abstractions may be formed by filtering the information content of a concept or an observable phenomenon, selecting only the aspects which are relevant for a particular subjectively valued purpose.
https://en.m.wikipedia.org/wiki/Abstraction
[+] [-] platz|8 years ago|reply
OP is confused about what abstraction is actually for
[+] [-] jondubois|8 years ago|reply
They might overengineer things and make them more complicated than they need to be and it just slows down everyone else in the team.
Good engineering is really all about empathy and psychology.
[+] [-] white-flame|8 years ago|reply
Assuming people can keep fully in mind about 7-10 things at once, a person who can abstract can keep entire constructed systems in mind as one of those "things". A person who cannot abstract will only be able to hold that many immediately tangible source-code level concepts in mind, having a hard limit on the amount of complexity they can have in their projects before their mental organizational capabilities collapse, in the same way people throw up their hands and give up at math problems that are beyond them.
It's a necessary but not sufficient skill; as you mention, social tuning and business mindedness tend to round out effectiveness from just raw skill.
And if somebody's being an Architecture Astronaut in their "abstraction", then they're not abstracting what they're doing in context of making a workable system; they're just rote copy-pasting architectural memes that they think matches a pattern, just like the ineffective programmer.
[+] [-] unknown|8 years ago|reply
[deleted]
[+] [-] sheepmullet|8 years ago|reply
I disagree.
I'll give you a team of psychologists and I'll take a team of mathematicians and we can see who can build the better software.
Empathy and psychology are game changers only when they are built upon a broad and deep base of analytical thinking and problem solving.
[+] [-] booleandilemma|8 years ago|reply
[+] [-] dep_b|8 years ago|reply
If I'm running a project and I'm having all kinds of problems to get my node.js performance to an acceptable level I'd look for a programmer that knows how to tweak node.js and all parameters associated with it (scripts, server, OS).
If I'm starting a project and I already have a node.js specialist aboard and I need to hire someone for the long term I can basically hire anyone with the right talents.
But it's a very different story depending on the parameters.
[+] [-] kylnew|8 years ago|reply
1. I think they need more than 1 project, either in your domain or multiple domains better yet. To me this is one way of demonstrating abstraction capability.
2. Ask a problem that involves modeling several objects where a hierarchy might be involved. Ie modeling a service like Instacart, that has both customers and employees, but maybe are all types of Users. Do they catch on to these common traits? A question like these can even extend to more senior roles it may just be a matter of how much hinting.
3. I still believe some sort of whiteboard challenge has value, but make it fair. A lot of O(n) type problems are straight forward looping over array and doing work type things. These aren’t killer gotcha problems intended to haze or assess depth of CS skill, they are for stimulating dialogue. I was anti whiteboard for a while, particularly because I felt like I was hazing, even when I gave lots of time and did everything I could to make the candidate comfortable. But without it I feel something is missing. So my new principle is just don’t make it tricky.
[+] [-] madeofpalk|8 years ago|reply
This 100%. We do an in-person 'pairing exercise' where they work on a simplified tax calculator. We expect people to solve the problem, but really what we're looking for is their thinking and to see _how_ they solve it. By gradually ramping up the requirements/difficulty, and by asking more questions we're able to learn a lot about the applicant.
[+] [-] booleandilemma|8 years ago|reply
Hiring Lawyers: look for the ability to abstract and not for experience.
Hiring Mechanics: look for the ability to abstract and not for experience.
What is with this industry and its strange disdain for experience?
[+] [-] pixelperfect|8 years ago|reply
This technology is more than a century old and is called an "IQ test."
But giving IQ tests is legally dicey, so SV companies use algorithmic challenges instead.
[+] [-] cjcenizal|8 years ago|reply
But in software engineering, I think the ability to analyze the information which constitutes a domain and then synthesize ergonomic abstractions out of that information is more relevant. Martin Fowler would call it domain modeling, I just call it software design.
Of course I also obsess over names of things, interface design, and mental models, so I’m biased!
[+] [-] rco8786|8 years ago|reply
[+] [-] aytekin|8 years ago|reply
1. Get them to write code (using their language of choice and google searches allowed when stuck)
2. Did they do any projects on the side?
A lot of people who sound great on paper can’t write code. Or write shitty code. People who are passionate about their work read a lot and do side projects.
[+] [-] kabdib|8 years ago|reply
These were generally people who did really great work while using normal hours, but who would put in the hours when necessary, such as during a deadline push. Often their organizational skills and general engineering hygiene helped keep the crazy hours at bay.
At night these people went home to their families and led their lives. Some were good woodworkers or were into other hobbies, some did sports, some taught classes. Oh, a few wrote code [I do], but not that many.
Don't get me wrong: Side projects can be an interesting window into how a candidate works and thinks. But if you use them as a hard requirement then I'm pretty sure you're missing out on some great talent.
[+] [-] rco8786|8 years ago|reply
[+] [-] JustSomeNobody|8 years ago|reply
Some company that doesn't want me because I don't have side projects, that's fine, they saved me the trouble.
[+] [-] pfarnsworth|8 years ago|reply
I never, ever ask for side projects because it biases for younger programmers with lots of time and against all others.
[+] [-] tasuki|8 years ago|reply
[+] [-] SAI_Peregrinus|8 years ago|reply
It's not that difficult to visualize a hyperbolic plane and learn to visualize hyperbolic space. It's much, much harder to visualize the real projective plane, and essentially impossible to visualize a quaternionic projective space. Yet these can still be worked with using geometric and topological intuition in a way that feels (to me) fundamentally different from manipulating abstract formulae or matrices.
[+] [-] ilaksh|8 years ago|reply
My definition of abstraction is moving from specific examples to more general systems. I definitely remember the process as I was teaching myself programming through my childhood of learning and improving my software abstraction skills in particular ways.
One type of abstraction that took a bit of practice to get good at when I was starting out like eight years old was recursion. I got better at using this type of abstraction by specifically practicing with the goal of converting loops to recursion.
Another type of abstraction is creating classes in order to reuse your code. This was something I learned about and gradually got better at over the years through practice and initially from a few books like Turbo Pascal Disk Tutor when I was in middle school.
Sure there are some innate abilities but I think it's not quite so cut and dry as the author makes it out to be with innate versus learned ability.
[+] [-] paultopia|8 years ago|reply
Which, come to think of it, matches my personal experience. I have zero spatial ability---back in the 80's in California they actually gave us standardized tests in elementary school including a spatial ability section, and my scores were always like 90+%-ile math, verbal, and like 20%-ile spatial. Never been able to draw for shit. But was always advanced in math, 99th percentile lsat (logic-heavy) scores, top grades in stats, etc. So am I at the 4th level but not at all at the first three?
[+] [-] jrochkind1|8 years ago|reply
[+] [-] mixmastamyk|8 years ago|reply
[+] [-] ddebernardy|8 years ago|reply
[+] [-] potta_coffee|8 years ago|reply
[+] [-] guelo|8 years ago|reply
A humble strong programmer who stands on the shoulders of the aquired knowledge of their whole industry and has learned from his failures and successes will always beat the arrogant but naive 10x super abstracting genius.
[+] [-] lhorie|8 years ago|reply
[+] [-] simula67|8 years ago|reply
"I want to say that I can’t stress enough that hiring based on your current technology stack or domain is extremely wrong"
"This is especially useful when you are hiring junior developers. You are not looking for hard practical skills, instead you are looking for the potential."
Clearly he is talking about keyword based hiring
[+] [-] potta_coffee|8 years ago|reply
[+] [-] Bucephalus355|8 years ago|reply
[+] [-] s0mesayitsluck|8 years ago|reply
There's so much abstraction nowadays, software developers have not the slightest clue what they are doing anymore besides copypasting some framework.
We're basically at the point of developers competing in abstraction without any fundamental understanding. "I can do this with only two lines of code."
In terms of the article, those people getting hired, are not necessarily the ones especially good at abstraction. They just have experience in what others have abstracted for them, to use as a tool.