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.
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).
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.
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.
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.
- Data structures were fundamental before ( perl's hashes-of-arrays-of-hashes-of-hashes, anyone ? ) and with the rediscovered FP paradigm, those are fundamental again. Once you figure the proper data model, the algorithm becomes much clearer ( https://www.amazon.com/gp/product/0131997467/ )
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
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.
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?
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.
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
15 comments
[ 3.3 ms ] story [ 46.7 ms ] threadIs 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.
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).
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.
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.
- Data structures were fundamental before ( perl's hashes-of-arrays-of-hashes-of-hashes, anyone ? ) and with the rediscovered FP paradigm, those are fundamental again. Once you figure the proper data model, the algorithm becomes much clearer ( https://www.amazon.com/gp/product/0131997467/ )
- Recursion, which importance is very well discussed on this blog post: https://www.joelonsoftware.com/2005/12/29/the-perils-of-java...
- Graph theory also was invaluable over the years ( http://www.maths.lse.ac.uk/Personal/jozef/LTCC/Graph_Theory_... and https://freevideolectures.com/course/3019/graph-theory ).
( hope that helps... )
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
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.
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?
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.