Ask HN: Are “theoretical” concepts being lost by new engineers?

60 points by santiagobasulto ↗ HN
I've dealt with a lot of developers in the past ~4 years and I've noticed a lot of them didn't have the "basic" theoretical concepts that I considered widespread and universal about Software Engineering and Computer Science. For example, engineers putting a lot of logic in their unit tests, or choosing the wrong data structures, etc.

Maybe it's because of the advent of self taught engineers? Or maybe these concepts are just "too boring"? I'd like to know if I'm biased or not.

EDIT: I'm not implying this is a "bad thing". Just trying to assess if it's a reality or it's just me. And I'm very supportive of self taught engineers! I think it's great that people can build their own careers by themselves. We might just need to adjust our field a bit based on how it evolves.

119 comments

[ 247 ms ] story [ 3980 ms ] thread
Half of data scientists or ML engineers I work with can implement and train models but do not necessarily understand the underlying principles or math.

Most people just care that it works and not why.

Really dangerous depending on the problem and field tbh

Yes, I've noticed that in the Data Science space as well.

I guess our field is becoming more an "operational" field; we need more people to operate tools and you don't need the underlying concepts to do that.

I don't think it's a bad thing, we just need to be conscious about it.

That’s fine if they’re applied data scientists or MLEs but should not be the case for research scientists
Juniors are gonna junior.
I've noticed this myself, no theoretical computer science concepts. To be honest it's very rare nowadays that new hires actually have a computer science background and are not self taught with a totally different background.
Yes, my opinion is these problems are arising naturally because of the permission of laissez faire attitudes in the interest of saving money at all costs.
I am self-taught so I have limited understanding of the types of degrees engineers usually pursue these days. I do know that more and more universities are offering focused software engineering degrees vs traditional CS degrees.

Can anyone comment if these newer degrees are better/worse at imparting the kind of theoretical knowledge of which OP speaks?

> engineers putting a lot of logic in their unit tests

Like is there a class which is supposed to teach these things? Seems like the kind of thing you have to learn through experience.

Regarding being self-taught... I find consistently that I generally outperform other traditionally educated engineers on my teams on a theoretical level, but I think this comes from many, many years of deep reading and small, focused experiments. I also haven't worked with a team comprised of only 99th percentile engineers but I assume that's not very common.

I don't even know how all of the nuance which drives sound theoretical frameworks can be imparted to a student in a 4 year curriculum, so I wager that a lot of this is taught on the job. So my next question is, what is the average developer team environment like, is there learning on the job, is emphasis placed on "getting shit done" vs "getting it done right", etc. My career has been entirely startups and independent consulting so I also have little insight into the bulk of the industry.

Anyway, I wouldn't discount self-taught engineers. If you know a self-taught engineer who has broken into the professional scene and isn't a junior, they likely have a comprehensive skillset and deep practical knowledge which converts to theoretical knowledge. Many self-taught engineers have a lifetime of experience.

I generally agree with you that software engineering today seems less rigorous. I also wonder if the internet is just making it easier to cross-examine engineering practices across the industry, and if there's always been such a distribution of people who deeply care about getting things right vs people who simply see programming as a job that in which they should invest the minimum.

Many of sweng concepts taught at universities are desperately outdated; literally the only UML thing I ever wanted to use was sequence diagram. Waterfall/TDD/agile etc. all turned out to be fads that lost their substance over time, all that matters in the interviews these days is LeetCode-Hard and scalable system design, and most important, being likable/relatable. Theoretical computer science is now floating in its own cathedrals completely separated from the practice even in highly practical fields like distributed systems/algos. ML is just math.
IMO agile didn't turn out to be a fad. Rather it became so normalized (in some form, not necessarily a pure one) that it's just not a hot topic any more.
I'd say it got subverted and emptied, now it's just a set of silly rituals with some drummer setting the pace.
Group theory. Stream processing. Testing and quality assurance in general. Technical debt. Everything in mythical man month and code complete, which are a bit more practical than theoretical, but still.
I'm self taught and also went to a boot camp around 8 years ago. Been working since then. I think I'm a pretty decent developer but often wonder if I ought to get a computer science degree (and also constantly kick myself for not staying in school when I was younger).
The amount of free material available on the web or on YouTube is actually mind blowing these days.

I got a CS degree almost 30 years ago (Computer Engineering actually so a mix of hardware and software) and have spent the last 3 years diving back in and relearning things I have a much deeper respect for. Surprisingly little has actually fundamentally changed, btw, in 30 years.

But there are wonderful resources like MIT’s original SICP book at well as video lectures (in glorious 80s retro splendor no less!), the Carnegie Mellon Databaseology courses, there’s a good Advanced Programming in the Unix Environment course, Crafting Interpreters, Smalltalk-80 Bluebook, talks by Alan Kay or Joe Armstrong, etc, etc, etc…

Once you start to get a sense of your own filter, as well as YouTube’s algos getting tuned in for what you actually want… I’ve actually been truly amazed. Lately I’ve been hacking around my own simple VMs and compiler theory in a way that I couldn’t have previously imagined.

1) fewer people know how the machine and network works. This includes infrastructure experts.

2) there’s too much to learn and everyone wants to be a generalist. I’ve spent my entire career levelling up and I still don’t know enough most days.

> everyone wants to be a generalist

Weird. I'm the opposite: I REALLY love what I specialize in (idk why) and loathe almost everything else (idk why). I consider it a personal pathology that I just have to live with.

I don't think they made us write any unit tests in college. What wrong data structure are people using?
A dev I worked with though it would be a good idea to use an object in javascript to solve a problem. He made the first key 0, the second key 1, and so on. You can't use a number as a key, so there was extra logic to make sure it was cast properly into a number when needed.

I asked him why he didn't just use an array and he just kind of had a mind blown look on his face.

fun fact, all arrays in php are also associative. I once worked on code that managed to delete one of the array index keys. That was fun to debug
“The children now love luxury; they have bad manners, contempt for authority; they show disrespect for elders and love chatter in place of exercise. Children are now tyrants, not the servants of their households. They no longer rise when elders enter the room. They contradict their parents, chatter before company, gobble up dainties at the table, cross their legs, and tyrannize their teachers.” ― Socrates

What are you (you reader!) doing to support your Junior developers?

> I considered widespread and universal about Software Engineering and Computer Science

Could be relative, depending on level of experience, opportunity of hands-on implementation and retention of knowledge.

When I was at an interview from an eCommerce startup, they were all over the case of DB concepts and transactions. Then I was at an enterprise, where they swore by the design patterns and heavily pushed wrong patterns in wrong places because a senior engineer said so. Then I went to a hardware manufacturer, and they had zero concept of any best practices, it was bit manipulations and inline optimization all the way through.

Depending on where one is exposed for a long enough time, some concepts are lost, some are reinforced.

At the end of the day, theories don't bring any values, whatever gets the job done and brings in the money making the machine churn away is crucial.

New engineers are always green in some aspect. It sounds like you’re combining a number of different engineers from different programs and drawing conclusions.

Courses teach a lot, but they also miss out on tons of topics as well. There’s limited reinforcement between classes, so even if your professor covers your topic of choice, the next course may not.

Unit tests for instance are generally used by students for checking their homework assignment as they go, but it’s the (incomplete) grading rubric. I didn’t actually write many unit tests in college until my software design class which was in Smalltalk.

I didn’t use version control until I worked on a few projects with a fellow student who self hosted SVN.

I used 6-8 different programming languages in school, each for a semester at a time. There’s simply no place for repetition and mastery until you get a job, either as an intern or permanent position—and then you’re the engineer you talk about.

Every new engineer is different, depending on their program and interests, even within the same school’s degree program. They’ll all need mentoring to grow. No one is ever going to graduate and be a mid to senior level purely from school.

I’m teaching my boss git these days. He is an electric engineer with lots of years of programming experience, but somehow avoided modern version control.

At the same time, our fresh-out-of-school hire just started and with 6+ years of FOSS Rust, he is teaching everyone how to do async properly.

I’m trying to come up with the right way to convey this thought and I’m not sure I’ve nailed it, but here’s my attempt:

How you feel about these engineers is how lead engineers feel about how you feel about these engineers.

It’s hierarchical; you are probably a senior dev, and as such you notice the mistakes junior devs are making, which is fine and good. However, your attitude towards those junior engineers, that they must have something wrong with them, is a terrible mistake that only a senior dev would make.

The inability to perspective take or recall your earlier career is the same kind of mistake, to a lead dev, as putting too much logic into a unit test or selecting the wrong algorithm is to you.

Unlike you however, a lead dev will understand this is just how people are at this part of their career, and know that you’re probably coachable and can learn to be better than this.

Your experience reads simply like there is a lack of practice. The discipline most definitely takes practice. It's not unsurprising that new engineers are not well practiced – that is what it means to be new.
While I tend to agree (my personal bugbear is understanding what the abstractions are hiding, e.g. containers are cgroups), as others have pointed out to me, there’s always another abstraction to peel away. Until you go back to Shockley, someone can always laugh at your moral high ground. EDIT: The irony of citing Shockley and using the phrase “moral high ground” isn’t lost on me, but hopefully for this particular point his physics work can be disconnected from his other beliefs.

That said, while I do believe that there’s a practical limit to how much depth of knowledge is required for most jobs, it’s perilously close to what is helpful to know. For example, while you don’t need to know how a B+tree works to write data into a database, knowing that the DB uses that (and in what capacity) can be enormously helpful when determining how to structure your table schema. Or at a higher level, you don’t need to know SQL to use an ORM, but it makes spotting performance problems much easier if you do.

Oh, no! Don't blame "self-taught" engineers; I'm self-taught. In my spare time, I learn assembly, and work with a bread board with an arduino. Fun stuff!

The problem is "bootcamps" and other such businesses promising so-called six-figure salaries. I think most people who find these bootcamps appealing aren't really interested in technology. They just want money. I'm sure they wouldn't learn any of this stuff in their spare time, as a hobby, having genuine fun.

"Just want money" may be a little too harsh. I'd say many are interested in technology but they don't know what they are getting into.

Even the best bootcamps are too short to go much into concepts - they turn out at best software technicians.

> best software technicians.

This here is the fundamental issue right here. There is a difference between technicians and engineers. There's a heavy emphasis on technicians, not as much on engineers. The big way to spot the difference is a technician defines themselves by their tools.

I knew what I was getting into; practical programming skills and concepts to make a career change, both for money and for more interesting work.

Fortunately, most of us work on plumbing data through web applications, so you really don't miss much by not having taken classes on compilers and assembly language.

The best engineers will always be self-directed learners. Bootcamp is just a springboard.

Boot camps are really great for self taught people that want to level up their knowledge.

About half the people in my boot camp were really into computers and got a lot from the program.

I don’t think what you’re describing is even a bad thing, do you?

If people who aren’t really interested in technology can be good enough at their jobs as programmers/developers/engineers, who cares?

>who cares? If you are hiring or working alongside programmers, you probably want those that "will" be "good" rather than those that "can" be "good enough"
I don't think that's such a sure thing.

Good enough is good enough.

Hire people who you can coach up a bit at a good value and get the job done. Hardly any job needs the best people available. They really just need to get enough out out people who are good enough.

If that's not the kind of place somebody who considers themselves a good programmer wants to work, that's fine, too.

I’m self taught and I’ve seen some of this baffling entitlement up close.

In my previous role, I had a direct report that was a talented designer who was also good and fast with React.

I put him on a project where we needed to use both Express and jQuery. He asked if there was some way to trigger when the browser has loaded everything. I got to mentor him a bit, and he’s a better engineer now, but boy howdy, we covered a lot of basics. He spent his free time living life away from screens.

He was pushing for six-figures in every other one-on-one during our last six months together.

> He was pushing for six-figures in every other one-on-one during our last six months together.

Good on him for bag chasing. Cost of living is absurd these days, shrugs

Are you the exception or the rule?

I'm not "blaming" self-taught engineers, I actually support self-taught (instead of blowing $100K on a traditional school).

But I'm wondering a few things:

a) is this universally known for all self taught engineers? Like, are bootcamps explicitly telling people: "Look, we're just giving the operational basics, there's a lot you have to cover on your own".

b) Is it easy for self-taught engineers to find the correct resources to bridge these gaps? In traditional software university, you have a career path and courses and books "pushed" onto you. So there's no way around that. I HAD to learn Prolog and the Logic paradigm cause otherwise I'd not pass. How do self-taught engineers manage to learn these things today?

---

Also, I'm not implying this is only an issue with self-taught people. Maybe our field is becoming more complex and even universities are "ditching" the theoretical concepts in favor of more "practical skills".

Perhaps also an exception, but most of the best devs I met in my teens and early 20's were self-taught.

Most were working for large companies before college age

Some eventually went on to complete CS degrees after many years in industry, but seemingly only as a formality, out of curiosity, or for a break from the grind

I'm self-taught as well. Dunno if I'm the one to say, but I'd consider myself in the upper-quartile of programming breadth as a result. There are lots of talented programmers though from a host of different backgrounds.

I've mostly learned from books, man pages and a string of interesting problems[1]. I think in general you tend to learn in a different way if you learn through self-directed problem solving. Like you get much deeper understanding of the theory, because that's the only way to get anything done. It's a much harsher standard than having to pass a test.

Though I think there's a lot of survivorship bias involved in making self-taught programmers competent. The ones who didn't have a knack for it are doing something else now.

[1] e.g. 15 years ago I built a 6502 emulator with a weird fantasy base 3 architecture, which eventually included a C compiler for this weird architecture. (I guess I was Terry Davis before it was cool.) More recently I'm working on an internet search engine I've built from scratch in vanilla Java bespoke index, bespoke crawling, bespoke everything.

(comment deleted)
Yeah, the self-taught concern is really missing the target in my experience too

Given how many tertiary courses are becoming increasingly vocationally focused - and feed into jobs which are extremely narrow in focus - the self-taught aspect is probably the most consistent distinguishing factor I see in exceptional engineers.

Doesn't matter if they're self-taught from zero, or self-taught on top of some technical degree - it seems to result in more breadth and depth of experience than a degree and a lack of passion does.

That said, perhaps "self-taught" is an overloaded term?

There's self-taught in traditional "autodidact" sense of: experimentation, reverse-engineering, and hundreds of small personal projects - potentially then exposed to informal expertise via usenet & BBS discussions

Then there's self-taught in the sense of: did a vocationally oriented bootcamp in 6 months and all experimentation was related to coursework

Perhaps we need to distinguish between "self-taught" and "self-guided"?

This is what I tell people that ask if it's possible to break into the field without a degree as well, which basically amounts to "what do you mean by self taught".

There are all different kinds of self taught. The highest performers in any discipline are naturally going to tend to be self taught (for a variety of reasons, and not exclusively, many have formal education or training as well, and without exception they will have had some form of mentorship). But so are the lowest.There is a huge range of skill level among the self taught, including a lot of people that are so far ahead academically that they would get nothing out of doing the typical university education thing.

> Oh, no! Don't blame "self-taught" engineers; I'm self-taught. In my spare time, I learn assembly, and work with a bread board with an arduino. Fun stuff!

But did you learn proper software engineering? Don't get me wrong, they also don't teach that in school.

I'm self-taught, and I absolutely did learn proper software engineering. And relearned it a few times as what was considered "proper software engineering" has changed (and continues to change) over time.
In my experience, at least, self taught are typically better than title owners. Not 100% of the time, but at least a solid 80%. My explanation is that self taught really LOVE the topics.
This has been my experience as well, and I think the reason for it is what you state.

But I'll break it down even more: what makes someone highly skilled in an an area is a combination of learning everything they can about the field, and spending countless thousands of hours practicing.

If you're doing a thing because you love it, you'll naturally do both without even realizing that's what you're doing -- because to you, what you're doing is play. You're having fun.

If you're learning a thing because you want to earn a living doing it, but have no special love for it, you're less likely to spend nearly as much time learning about it expansively or actually practicing, because what you're doing isn't play, it's work.

I have 2 degrees, and I do consider myself - for the most part - self-taught. The degrees offered mostly guidance and support, but ultimately it was what you made of it.

Everything presents an opportunity, you just have to decide to unfold the fractal [1].

[1] http://paulgraham.com/greatwork.html

It's a tricky problem: a lot of people who find bootcamps appealing are self-taught like you and me, but don't have the elusive "experience" to put on a resume.

There is no reasonable way to differentiate between the two, despite that being the entire point of accreditation.

Maybe instead of acting like there are 100 million open six-figure-salaried positions and nothing else, we can actually give inexperienced devs a mediocre place to start.

(comment deleted)
What I have experienced is that engineers without a degree learn in their free time the “fun” stuff: Golang, K8s, assembly, hacking, frameworks, sql, etc. They usually don’t learn things like context-free grammars, logic, mutexes, the kind of stuff you learn at university.

People with degrees and who also learn in their free time (like me) get to learn both: the fun stuff (now) and the foundations of computer science and software engineering (back then).

(comment deleted)
Welcome to the era of the burger flipper developers. 2 months ago they were at the grill, then entered some code academy (or sourcery as it's fashionable) and now welcomes you. If he survives a year in the industry - it's even worse, as "experience" kicks in.
I think that we just need to realize that we exist to make money for companies. Customers don't care about how a CPU cache works, or what the runtime of an algorithm is. They care about software that solves their problem. Sometimes you need to know the theory side to solve customer problems, but more often than not you really don't. Most of us are not actual computer scientists, even if we have a grad degree in the subject.

On top of this, if you're not flexing the "theory" muscle often, it's easy to forget a lot of the details even if you have formal education. I think this applies to a lot of us who have been out of school for a bit.

I love theory, would love to work on it for a living, but here I am.

Many developers today don't have basic theoretical concepts. Many developers 4 years ago didn't. Many developers 10 years ago didn't. Etc. This is not new. What have you done to improve this situation in your current company though?
In general, I think the quality is your average developer has gone down significantly in the last 5-10 years.

The market wanted a lot more developers and there weren't enough immigrants to fill those positions, so tons of companies lowered the bar for entry.

Your average dev these days is just so much worse which leads to a lot of the observations you have.

From my broad sample over the years, most of the good software engineers and architects are - and always have been - 'self-taught', even if many also happen to have classical CS degrees.

My experience is that good engineers getting things done is something that happens in engineer-led companies that pay well. If you're increasingly seeing the not-so-effective engineers then it's perhaps possibly a reflection that the company is one that doesn't try to or can't attract talent?

This doesn't make it a bad place to be. All that matters is that people are happy and worklife is enjoyable.

> Software Engineering and Computer Science

These are not necessarily the same thing (depends on the school), and many people who program computers are neither engineers nor scientists in any field, let alone in computing and software.

In all fields, not only programming, if you hire people without formal training, you get people without formal training. Sometimes they will acquire the same learning organically over many years (and maybe even surpass their capital-E Engineer brethren), sometimes they won't. You may even prefer them to not have the rigidity of formal training.

Moreover, this is not a new thing, nor, necessarily, a bad thing. The Wright Brothers weren't trained engineers. Qualified engineers of the time would have considered them woefully under-educated even for simplistic design work, and yet they built a working plane when no one else had.

Same questions here.

This other day I was interviewing with a recruiter for a Go dev position, then she asked "what is a map?", couldn't believe such a basic question was being asked, proceeded to explain, then asked her why such a basic question; she said most applicants couldn't tell her what a map was (shock face).

Next question was "what is a hash table?", even more shock...

I'm a Computer Engineer who started to program when I was 12 in a 286.

I’ve used Project Eulers Problem 001 as an interview filter and more than one senior developer failed it… not surprised they don’t know what a map is too