Ask HN: Is learning data structures and algorithms less important now than ever? - philonoist
======
cimmanom
Maybe 20% of tech jobs are in actual technology companies.

The other 80% of the jobs out there are about tech-enabling non-tech
businesses. As in writing CRUD front ends for fairly straightforward
workflows.

For 90% of the work in those jobs, the most you'll need from a formal CS
background is the ability to choose between data structures.

For another 9% you'll need to be able to evaluate whether your nested loops
will cause performance problems and to understand recursion.

1% of the work in those jobs requires the ability to write new algorithms.

You can almost certainly find a job and even career in programming that you
can do well without any CS background. And at least 50% of the jobs out there
can be done well with not much more than a basic understanding of a few core
concepts.

And on the other hand, there are broad swaths of problems that require a deep
understanding of algorithms or kernels or CPU architecture or whatever.

So it really depends on what your goals are and what areas interest you.

------
annywhey
You can get more done knowing less now, but essentially, all you do by using
other people's code is gain some leverage towards a specific problem. When
your leveraging tool fails you and you have to debug or extend it, a strong
sense of CS topics lets you distinguish the map from the territory.

The downside of absorbing CS wisdom is in being sophomoric about it and trying
to apply the most powerful, generalized and optimized technique you have ever
heard of to a problem you have encountered for the first time, writing a giant
edifice of code while misunderstanding what the technique actually does.

It's always been possible to get very far in programming with crude techniques
and a large amount of persistence, and you will be a more grounded programmer
for attempting an approach that is wary of abstraction - abstraction in the
language, in libraries you use, in the way you try to extend code. Try writing
excessively primitive code until it becomes painful - simple assignment,
branching, arrays and lookup tables, maybe a function call - then gradually
sprinkle in the abstractions, and you'll have the right balance.

------
blablabla123
You can get quite far without knowing them. But to be honest, I think this
wasn't super different 20 years ago. I mean there was Basic, Delphi and people
were writing software without knowing what they were doing - of course me
included :-). Today people attempt to do this with React or App programming.
People get somewhere but without _any_ understanding how this stuff works,
usually a wall gets hit after a certain complexity emerges.

Without understand how a computer works, programs can becomes ridiculously
unmaintainable und slow. The bare minimum is probably knowing that there is a
thing called complexity, that there are Hash maps, sorting algorithms, things
like discs, memory, networks, all operating at different speed. Even if you
don't do the implementations of these things yourself - who does? - you don't
get far if you have no clue or you know the facts but ignore them.

Disclaimer: I didn't study CS, had it as minor subject though and when through
interviews where they asked this stuff

------
Jtsummers
Yes and no. It's a lot easier to get good-by-default implementations of a lot
of data structures and algorithms in an increasingly large number of
languages. However, without an understanding of them and the theory behind why
one has better performance or behavior than another, you can't make your
selection properly.

You'll also be unable to, or have much greater difficulty, working in
languages or environments where the standard library or common packages aren't
as fleshed out. I work in embedded systems, we have to implement a lot of
things by hand. A developer who didn't understand algorithms led to a number
of poor implementation choices that required major rewrites of critical code.
This increased the risk of the project (hundreds to thousands of lines of
changing code increases the chance for bugs, and the rework threatened
scheduling delays).

------
astrodev
Sure, then complain that all you get to do is glue together some crappy
middleware :)

------
dronescanfly
Another take on this subject: Once your manager comes around looking for
someone that could help / take on a highly low level task / project, you won't
be the right fit if you don't feel comfortable or have the required knowledge.
(chicken or egg problem) You don't get to work on the fun stuff because you
don't know the fun stuff

------
ainiriand
Fair question. I would say depends.

Is your goal to be able to understand confidently the innards of some complex
tool? Do you think you might need to build a new tool being completely
confident on how it works and all its downsides?

On the other hand you dont need it for most jobs. You can build a successful
career without it. But at least you need to know what they are all about.

------
slipwalker
i strongly disagree. Solid foundation on CS is the most fundamental skill for
anyone writing code for living... obscure details of this or that technology
or library is just that, obscure knowledge on soon-to-be-obsolete tool. The
basics are "portable" between different "technologies-du-jour", or at least,
it has been like that for me, by the last 20+ years.

~~~
arthev
What aspects of a solid CS foundation have been particularly useful to you?
And how?

I'm currently a student, and most of the courses seem shallow, so I'd
appreciate a data point to re-calibrate my plans for learning foundations on
my own.

~~~
Jtsummers
Algorithm analysis. Similar to my other post, I've gotten speed ups on the
order of 100x or more by changing the algorithms used to accomplish the same
work. One example was a data analysis tool, the original author wrote a
correct (produced the right stuff) but naive implementation. It took about 3
minutes to perform its work, I got it below 5 seconds without being clever
(read: hard to read/write, but fast). I changed the order of some of the data
processing, and switched to a smarter data structure (built-in hashmap versus
whatever he'd chosen). The final version was readable and maintainable by non-
CS folks (it was used by engineers, mostly).

I knew of optimal sorting networks which let me optimize a hotspot in an
embedded system and improve throughput in a real-time system. It seems like a
miniscule savings (versus whatever sort they'd used before, insertion I think)
since it was only a handful of items. But its execution time was one of the
dominating factors in the system, and reducing the number of comparisons and
branches to a minimum was a significant improvement.

Familiarity with declarative languages like Prolog informed the design of data
analysis tools (that could've been done better in Prolog but that wasn't an
option). So I wrote a specialized program that, internally, was halfway to
being a Prolog implementation.

Parsing. I've not written any compilers, but I have needed custom parsers over
the years. Understanding the difference between different types of languages
(regular versus context-free in particular) meant I could choose the right
tools for the job. Additionally, understanding what needs to be done in a
parser leads to better structuring of the code.

Programming language theory. You don't need real, formal theory here, but if
you understand how ideas map between languages and what some languages excel
at (compared to others), you can write idiomatic code in more languages.
Versus my predecessors, who could "write Fortran in any language". You can
also understand the tradeoffs between the different kinds of languages (why do
people support OO, FP, and others; why do they choose each). Additionally, you
can borrow ideas from some languages and import them into others, with some
care.

Understanding abstraction, which I'll admit was generally not taught well in
my program, I got it more from my math background. This can lead to generic
code and programs that operate on a wider variety of problems and data types.

------
mhh__
You can get away without, but I don't think you can reasonably call yourself a
programmer if you don't understand how your software works.

Being able to write rigorous proofs (of algorithms, lets say) will help you
write correct code on a more consistent basis, and just generally train your
mathematical thinking skills.

What is proven, is forever: How long does your average library last?

------
InternetXtream1
I believe it's actually opposite that's the way of the future it's everything

