[aikah]

> We've hired several devs out of bootcamp, and they're all taught how to code, but not how to solve problems using code...

Frankly any Algorithms & Data structures book should do the trick. Choosing the right data structure is often half the solution when solving a problem. That plus SICP and a book about Discrete Math should be enough for 90% of the daily problems.

[jakobegger]

I'm not sure Algorithms & Data Structures will help you all that much in the real world. In most modern languages, all the algorithms and data structures are already implemented in the standard library, and while having heard of them is beneficial, you won't get a lot of value out of knowing how to do a binary search.

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.

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.

I'm not sure what my point is. Software development is hard, a bootcamp and an Algorithms book is probably a good start, but after that you need to still put in a lot of effort to reach your full potential.

[AtheistOfFail]

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.

[dmos62]

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.

[jholman]

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?

[leshow]

> 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.

[flukus]

> 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.

[busterarm]

Pretty much this. I show/tell people all the time that most of solving the problem is how you structure the input data. `Rock, Scissors, Paper` is perhaps the best simple demonstration of this.

That said, I don't think it's something that correlates to being a bootcamp grad. I'm usually the one `solving problems with code` and the closest thing that I have to an education in this industry is the boot camp I attended (lifelong programmer regardless). I know other boot camp grads who are the same way.

I encounter developers from all backgrounds who know how to code but can't solve problems. There's just _a lot_ of bootcamp grads right now.

[will_pseudonym]

FYI, it's spelled 'discrete math.' I know this only as someone who spent years incorrectly spelling 'discreet' as 'discrete' because of my math background.

[sulam]

It's very discreet of you to use a pseudonym!

[hatsix]

I agree that it would do the trick... but given that Problem Solving is such a basic skill, I would hope that someone could have figured out how to do it without requiring years of college math and csci.

(for reference, my real concern is my cousin is in a csci-150 course, having trouble because her prof isn't used to teaching to students who haven't been programming for years... nobody has bothered to figure out how to teach problem solving, and they're left to teach themselves or drop out)