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.
Yeah, the best abstractions I've built have been 3rd or 4th iterations after persistently refactoring to account for unexpected impedance mismatches.
I'm skeptical of the notion that great code is designed up-front by "clever architects". I think the best code is usually the result of dirty hackjobs, persistently refactored into clean code.
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.
> 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?
This is 100% fair as well. Some companies really do have interesting work and problems to be solved, and the work is enjoyable and satisfying. But I get that all work won't be like that, and there may be plenty of boring work as well.
in your case, i think what would be relevant is making it known that these technologies are used, and that they are configured in the best way possible to ensure they're maintainable. If it's going to be boring work, it should at least be orderly.
I think that ability to do the job and being responsible should definitely rank higher then ability to look "passionable" - which often seems to be more important.
Another issue however is that there truly are people who like fixing database, configuring LDAP and other similar practical work. I have met them. They don't find that life altering, but they dont want life altering. They want to come to work, fix stuff, do the job and go home.
There is no universal interesting work. What is interesting to me is not interesting to you or other people. I enjoyed fixing bugs in someone elses code, I found it interesting challenge, but quite a lot of people hate it. I like large long lived projects, quite a lot of people hate them. Too many people think that what they find interesting is what everyone finds interesting.
What happens in this industry is that the company has a job that requires a lot of routine, but goes out of its way to pretend the job is exciting for people who don't. Because generic idea of superstar. So they hire someone who does not fit position at all. And they would not hire that person who would gladly do the routine thing to them and would be good at it, because he does not fit the expected profile of excitement.
I feel that way about my work. It's not inherently exciting but there's a reward to being the one who can dive into any task and solve the problem. Being open minded to new things, I've ended up being a Swiss Army Knife kind of developer. Some days I'm configuring servers, some days I'm doing database stuff, one day I'm writing Python and the next it's Javascript. Many days I do all of those things. Most of my tasks aren't glamorous but being responsible for all that stuff and seeing the business come together because of my effort is really cool.
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.
One long-term benefit is a company that's alive. If I need feature X to be delivered in 12 months for because that'd benefit the company immensely, then I rather hire someone who can be productive on day one (as she knows the tech stack, has experience with similar problems, etc.) than someone who re-imagines how our tech stuff is implemented. The latter is also useful in some cases, but article somehow claims that this is the general rule. No, it isn't.
>> than someone who re-imagines how our tech stuff is implemented. The latter is also useful in some cases, but article somehow claims that this is the general rule. No, it isn't.
I guess you work in a service oriented company and not the product because this is exactly what results in a bad product.
Not always. Think of how Google has repeatedly tried to reinvent the world with their 20 messaging apps. That inconsistency combined with a lack of steadfastness and a tendency to shut down old apps has prevented their products from thriving, and hurt their reputation in the process.
Just like everyhing else, the optimum strategy varies from project to project.
The Google that released something new every week (and had beta tags everywhere) did at least seem to be able to innovate. And some of that innovation stuck (and even some of the things they probably rated as “misses” had lasting impact — witness the various Reader clones...)
I’m struggling to think of Google changes in the last few years that have made the slightest difference to me as an end user. Except maybe tweaks to search that make it less useful for any vaguely obscure query.
> 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.
See point one. It's up to you if you have oompa-loompa work to be done or are trying something entirely new. But the reality is there is a lot of talent out there - the oompa-loompas are out there too, but it's for low paying, uninteresting work (which i tried to exclude).
> 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.
no. The point I was trying to make is that we can overthink hiring, when in reality it's not that mysterious. And the reason hiring is so bad in the industry is because we think it's something it's not.
> 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
The stigma is not around "superstars", but the quest for them and solely them in our industry. We as an industry are hyper-focused on this one type of person and missing out on all other kinds of people than can bring a variety of things to the table (aka diversity). The stigma is not that superstars are anti-social, it's that non super stars have nothing worthwhile to contribute. Which is just a recipe for the classic SV echo chamber.
>> The stigma is not around "superstars", but the quest for them and solely them in our industry. We as an industry are hyper-focused on this one type of person and missing out on all other kinds of people than can bring a variety of things to the table (aka diversity). The stigma is not that superstars are anti-social, it's that non super stars have nothing worthwhile to contribute. Which is just a recipe for the classic SV echo chamber.
Diversity might be good for an established company but for a startup, it's not important at all. I encourage everyone to look for the right person and not waste their time on others. It's their startup, they are the person taking all risk. It's up to them to figure out what kind of person is best fit to solve their problem. After all, they've thought about both problems and solution and long enough to consider taking this risk. It's all or nothing game, no person who succeeded elsewhere can be deemed qualified to change their perception.
> Diversity might be good for an established company but for a startup, it's not important at all
You're right, it's not important - it's critical. Diversity means stretching boundaries, broader perspectives, and greater quality; not to mention playing a huge part in shaping the company's culture and values.
There are a lot more amateur & semi-pro basketball players in the world than in the NBA. Make sure you're playing a game that requires all star gameplay (like space jam!) before setting the bar that high. Most games just need players who are reasonably good. And likewise, beware what happens when a team is packed with nothing but allstars - they all play their own way but not together (and typically lose)
Diversity in technical backgrounds is an important value-add. There's something truly special about a team of people with backgrounds in embedded, web, traditional desktop, devops, and so on working on the same project; even if they're not currently applying their specialty directly on the work they do.
The knowledge acquired through their backgrounds will have taught them different approaches to problems, often allowing them to pick a better solution to a problem in (as an example) the development of a web application than an equally experienced web-only team would've come up with.
Diversity of skill absolutely DOES NOT MATTER in a startup. You really want to get your money's worth on a team that will not stumble and leave a project in limbo due to technical issues (which can easily kill any small company); and for that you always want to get the best possible talent.
>> 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).
Money doesn't create loyalty... it aligns interests. Most businesses aren't loyal to their employees - there is no logic as to why the inverse should be true, either.
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
"The abstract is no more than an instrument, an organ, to see the concrete clearly." —José Ortega y Gasset
"Good general theory does not search for the maximum generality, but for the right generality."—Saunders Mac Lane, who knew a thing or two about abstraction
I’ll drop one of my favorites, from Ken Iverson’s “Notation As A Tool Of Thought”:
“The utility of a language as a tool of thought increases with the range of topics it can treat, but decreases with the amount of vocabulary and the complexity of grammatical rules which the user must keep in mind. Economy of notation is therefore important.”
Jargon should be as minimally complex and extensive as needed to express the relevant concepts, given the context.
The complexity and amount of jargon is proportional to the difficulty of using that jargon, so overly complicated jargon imposes an unnecessary cost on everyone who encounters it or interacts with it.
It sounds like you are saying that jargon is good if it can more effectively express some idea than was possible before. I totally agree with this, it's a great point.
But sometimes the additional expressiveness does not compensate enough for the unfamiliarity or peculiarity, making it not worth it, and so it probably won't be adopted by others.
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.
I think it's a problem for a lot of software projects that often, simple user operations traverse too many files or components.
Obviously this kind of complex logic is written by smart people who can keep long chains of logic in their minds but it doesn't mean that it's a good thing.
A less intelligent developer would probably have a hard time keeping long chains of logic in their mind and so would be more likely to keep their code simple and readable... Which often means better code.
But it depends what kind of problem is being solved. If it's a very complex problem like working with distributed systems then complexity cannot be avoided.
It's obviously about being able to abstract computational processes and programming constructions, as done by Developers who are Hired to build software.
And yes, I've dealt with real people on all ends of this spectrum, and there's stark common denominators in their respective successes and failures. That's not to say this article is any good, but the skill of abstraction is still paramount to software development.
Sure, but phrasing it as “abstract/can’t abstract” seems reductionist and arbitrary.
By and large, the overwhelming majority of humans will bring you a cup or bottle of water if you ask them for “water”, rather than bringing you water in their cupped hands. Clearly all these humans can abstract.
If this conversation is to be meaningful in any way, it’d be helpful to use well defined, measurable properties (“can count to 10 without using their fingers”) rather than fuzzy things like “they can’t abstract” which is clearly plainly false.
Otherwise, these conversations merely devolve in “10x programmers are real and I only hire 10x programmers!” vs “anyone can be a 10x programmer given the right environment” and it just doesn’t go anywhere.
Again, you're projecting things nonsensically into non-programming fields. There are plenty of wannabe programmers out there who simply like computers or like the idea of money in the field, who regardless of age cannot muster the required abstract thinking as applied to programming to be a developer that can put out minimum-acceptable-quality code.
Regarding your last sentence, that's why I've been careful to call it a "skill", because it can be exercised, apprenticed, and gleaned. But for some people it just never gels.
This isn't the distinction between "10x programmer" and "regular programmer", it's the distinction of "has programmer skills" and "does not have programmer skills". And as much as the pointy-haired inclined hate it, software development heavily involves creativity and bespoke research, for which there's no reasonable objective skill measure besides simply doing the work.
Assuming that both groups spent the same amount of time learning programming. For most kinds of large software projects, I think that the psychologists will produce better, more readable and maintainable code.
If the project is like a game or something heavy on physics then mathematicians will have the upper hand.
I actually did a project for a professor of psychology at a university in the US. They didn't know much programming but I was impressed by the specifications document which they sent me because it didn't have any gaps or inconsistencies like most engineering specifications that I've seen before. The requirements were very clearly expressed.
Being able to share very complex ideas with a high degree of accuracy is is an extremely valuable skill.
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.
And the absence of empathy and psychology - and creativity - will give you impenetrable code with a terrible UX.
I'm not sure abstraction is the correct thing to look for.
There's an engineering joke about the difference between an engineer and a hobbyist being that anyone can build a thing for $20, but you need an engineer to build something that works just as well - or better - for 20c.
There's a lot of $20 code out there. 20c code is much rarer.
This isn't entirely related to IQ or the ability to hold a model of the entire codebase your mind, although both help a lot if someone has a talent for seeing the essence of complex relationships.
Some people get there after a few iterations, some people never get there at all, and a talented minority of developers tend to get there on the first try.
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.
I really like the idea of pairing exercises too. I’ve done an interview before as the interviewee where I didn’t actually do the typing but did all the dictating to build out a class with a TDD approach. It never felt like I was under heavy scrutiny and there was so much conversation. It’s amazing when you walk away from an interview feeling like the experience was positive/educational regardless of outcome.
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 think he's trying to get at the distinction between being able to think in abstractions versus choosing the correct abstraction for the problem at hand. The first is a prerequisite for the second, but the second is far more important.
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.
You can absolutely be good without side projects. And there are a lot of ways to be useful as a software engineer.
But all other things being equal, when looking at code, it literally comes down to practice. The more code you've written, the more things you've had to research and the more mistakes you've already made, the faster you'll be able to produce good code in the future.
Side projects help that aspect. Because there's only so much you can do and learn during your day job. You can always make up for it with other skills, experience, or just the difficulty level of the projects you've been on and nail the job anyway.
Side projects help people who DON'T have all of that nail jobs. They can go "Look, I may not have worked for Google, or I may be only a few years out of school (if I ever went to school), but I made up for it with these projects".
These are not mutually exclusive. I have a life and work on side projects at the same time.
I started the latest one during a 1 week transition between jobs. I was able to work full time on it while my SO was working. Since then, I have been working between 0 and 10h each weekends.
I usually only read (both code related and general litterature) during week days.
It’s entirely possible, just requires a bit of organisation.
you know what i hate? recklessly divisive rhetoric.
a life out of code and side-projects: the two things are not mutually exclusive. op isn't suggested he expects candidates to have written an os kernel. all op says is he/she looks for side-projects. if you were really interested in discussing the matter you would've asked some exploratory questions (e.g. what is the threshold for substantial side-project). then you would've really had an interesting conversation (because it is possible to have a life outside of programming and still be interested/engaged enough to have a couple of small side projects. and it's completely fair to expect engineers to get extra training. many many many other professions have exactly the same requirements. doctors/dentists have to regularly get re-tested on certain skills/attend conferences/etc.).
but no instead you with the one-liner. try just a little harder and maybe you'll actually change someone's mind that's blindly obsessed with side-projects.
I seemed to have hit a nerve with you. Sorry if my comment offended you. I have no interest in actually discussing what constitutes a side project and what doesn’t. Let me more clearly articulate my point:
Side projects have no bearing on the quality of an engineer.
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.
This feels reductive. Why do side projects have to be "Twitter in a weekend"?
My current side project is a Rack framework for making OpenAPI3-first APIs. "It's certainly not Twitter in a weekend." I learned Swagger/OpenAPI 2.0, so I used grape-swagger; found it frustrating and limited to OpenAPI 2.0 so now I'm using OpenAPI 3.0 and writing `Modern` to properly embed my understanding of it.
If I were looking for a job (I'm not), I would fully expect that this speaks to my understanding of and my comfort with designing and implementing good APIs.
Because cleaning it up would waste time I could be spending learning other things, and I don't want people looking at it to think I code like this when I'm getting paid to do it.
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.
They simply show a desire to learn. Too many devs are happy to reach a comfortable level and coast forever there. I’m sorry, but side projects, especially simple ones, have been a great hiring metric.
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.
> Aren't ability to abstract and experience sort of similar?
No. They are distinguishable from each other. One may feed the other, but they are separate.
> 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 are confusing abstraction with data and function hiding. In the article abstraction means the ability to meta program, translate one problem into a simpler generic problem, etc. This is a skill most of the industry lacks _in practice_. It is a skill that all 1% coders have, but it also doesn't make experience go out the window.
Experience is abstraction. You take what you've been doing for the last N years, and you develop a simplified understanding of that over many examples.
Heck, machine learning is basically abstraction as well, and it is something that arises naturally with intelligence. Good programmers must be especially good at it, but so do many other professions as well (even say doctors).
I don't feel that they're orthogonal - while one doesn't necessarily imply the other, they certainly seem correlated.
At least if I'm thinking for myself, my ability to abstract seems to have steadily increased over the years; PeterisP-10-years-ago was much worse at this and the changes were mostly driven by experience, seeing how all kinds of different systems are built, which kinds of abstraction tend to work out in practice and which seem nice at first but turn out to be horrible after a few years.
Then it serves as example of what not to do. That helps a lot too, mostly because your own abstraction is always super clear the moment you figured it out and understand it. It is when you are forced to read it after few years or when someone else invented it you realize how complicated and difficult it in reality is.
It seems we are talking about entirely different types of abstraction. Most code contains no abstractions (not talking about language abstractions which are something else entirely and can be incredibly deleterious to maintenance of the system).
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've seen this type of hiring practice, and most of the time it was to hide the desire to hire monkey coders who are micro-managed. It's a shame for the coders, as it can destroy their abstraction capability, while pretending to foster it.
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.
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.