I'll disagree with this.

Algorithms and data structures can actually be great not because you implement your own but because you can find out why your N^3 algorithm is slow (give you three guses) and why iterating through your data is slow (since you used the wrong data structure)

I like Bootcamps for what they are, a tool to fill Junior level positions for people to begin working their way into a career and I love teaching the people who graduate and are interested in continuing their career, but there is more to programming than paying for a Bootcamp and spinning up a Rails/React app.

PS: Forget anyone who says "I already know how to code, I don't need to learn this". Those people are fucking boat anchors, they just sink.

I'm inclined to disagree as well. Organization of large scale programs/problems is straightforward if the composing parts are sensible. The datastructure is root of all. A proper explicit structuring of the data is crucial to constructing a good abstraction. I usually accent reading others' programs or solutions, with objective of finding new ways to see the problems. Of course it's important that said programs are good quality. Inspirational properties of elegant programs should not be underestimated. To me, most influential such readings were classic textbooks (Norvig's PAIP), classic algorithms (like qsort) and others' kata solutions. Also, another thing that I find is very important is if you work on very complicated stacks like web or native apps, to step back from time to time and do some cleaner programming in simpler environments. This helps maintain curiosity. What I do is write small programs, and I don't implement actual stack calls (like filesystem calls or dependency calls), just stub them. This let's the mind feel free. When I'm done, if I want to have it functional, I'll implement the calls. Point here is not to burden self.

As an algorithmist, I strongly agree. Algorithms are of value, but they are not a high priority for junior devs. For a tiny fraction of problems, algorithms knowledge is absolutely essential, and often cannot be picked up at the time of need. But for almost all problems, especially the problems facing junior-to-intermediate devs, there is rarely any algorithms work. As you said, code organization. Long lists of things to remember to take into account (e.g. what areas require one to stop and get a security expert). Etc.

I think the best thing you can say for algorithms training is that, without it, you often don't notice that you need to get an algorithmist.

When people say, as my sibling commenters do, "find out why your n^3 approach is slow", or "do a substring match", I wonder what problems they're solving. Has this shit actually come up in your career, or is it just something that you imagine will come up? How many times has a cubic algorithm actually been the problem? As compared to doing five hundred DB queries, instead of one query that JOINs properly and returns a 500-row result set, which I see juniors and students do all the time, and is not an algorithms problem at all (it's the same asymptotic complexity, btw!). How many times have you tried to figure out a fast approach to substrings, and how rude was your code reviewer when they pointed you at the standard library?

> The problems that I see most junior devs struggling with are at a much higher level. How do you organize large scale programs? How do you make sure that different parts interact flawlessly? A book about design patterns could help here, but without experience you won't appreciate what the patterns are good for.

I couldn't disagree more. Algorithms are the base level that you build on. Anything non-trivial you will have to understand what is available to you and create something new. Take something common, doing a substring match on a list of items. If you don't have algorithms knowledge I'd bet your solution is going to adversely affect the final program.

Good choices of data structures, and solid understanding of algorithms are the units of composition in creating software. IMO

> But by far the most difficult part to wrap your head around is concurrency. How do you make sure your assumptions all hold up when multiple threads / processes / users are all doing stuff in parallel? That's really hard to understand, and you need a combination of theory and experience to master this.

Or use Rust and have the compiler check it for you, so you don't have to be a wizard.

> How do you organize large scale programs? How do you make sure that different parts interact flawlessly?

All junior (and many senior) devs struggle with that. This is solved with experience, not training.