> The problem with being self taught, at least in my experience, is that you end up being very strong in whatever areas it is that interests you

This is absolutely key. One of the main advantages of a solid undergraduate curriculum is that it forces you to work your way through things that are important, but don't interest you as much. And this path is designed and supported by people with a much better broad view of the field than you have.

Now, you'll still always gain knowledge faster in the areas that interest you most, but if you only indulge this approach you will have significant gaps.

One thing I always recommend to people self-studying (when they ask) is to find someone you trust who really knows the area and ask them for recommended courses/books. Then follow that advice.

To some degree MOOCs etc. try and do this for you by designing course progressions, but there are limitations and constraints there that can have you spinning your wheel.

Being disciplined about both breadth and depth in a new subject is difficult. One of the underlying themes of a post-graduate degree, particularly a PhD, is to give you tools to do this for yourself repeatedly. It's not impossible to gain these skills properly with little or no formal education, but it is quite difficult.

Another way of putting this: a primary function of a curriculum - university or otherwise - is to convert unknown unknowns (things you don't know exist) into known unknowns (things you are aware of but not fully versed in) and known knowns (things you fully grok). This is why we shouldn't replace college with nothing: this is an important function.

Self-study isn't exactly nothing. I do find that there are a lot of people, especially web developers, who don't understand a lot of the basics, or even the language they're using.

I got into development from doing design work, also self taught back in the 90's. I wanted to do something... spent a very rapid weekend learning JS from a very large book, then applied what I needed the next monday. Spent the next weekend finishing that book and the next month swallowing three other large books on the subject (two more on JS, one on HTML). From there was VB5 then Access & VBA... then I started working as a developer. From there I learned more about databases and data structures, dabbled in C/C++ then circled around to VB6 when it came out. From there around the end of 2001 (after 9/11) I was unemployed and no jobs to be found. While crashing at a friend's house I learned C# with the command line compiler and another large book (didn't have VS). Since then more databases and db types, more C# and when it came out Node.js (had done a lot of classic ASP in JS along the way too).

I spent about 5 years working in eLearning, writing simulations of systems for learning/training as well as courseware. Really enjoyed that time in my life as I was constantly taking in domain knowledge as well as a very varied environment. Unfortunately after a while all the context switching and constant intake took a toll and I took a few more boring jobs doing corporate/banking work.

In any case, you'd be surprised how much you can learn without a formal education, or anything really structured at all. To this day I tend to take in new stuff rapidly and get bored once I've figured out the hard parts. Currently working on learning Rust and Kubernetes, short break on rust as the async syntax gets implemented and settles in.

I think my statement was too strong; I definetely don't mean to suggest that nobody who has never followed a curriculum of any sort can ever be successful. What I mean is that in general, as a policy, it is useful to have some curriculum to shed light on the unknown unknowns.

But to respond to "self-study isn't nothing": that's true, but your self study didn't replace college, it replaced self study. What I mean is that everyone has to do that self study and job training targeted at the specific stuff they're doing. Self study is necessary to expand "known knowns" in targeted areas, which is really necessary. It's just not as good at illuminating "unknown unknowns" as a curriculum put together by a person or group of people who know the breadth and history of a field.

I think it depends on the person and the experience. It's easy to say that a particular course was helpful, because it often is. But what's the opportunity cost? What other things didn't you learn because of all that time learning about, say, OS schedulers?

Also, it assumes that you have access to a very high quality education. In lots of cases, the teaching might be mediocre (perhaps even at elite universities that care more about research grants than education).

There's a lot of value in having a standardized base of knowledge, where you learn all the things that a practicing engineer should know. But in reality, the sum of things you "should" do takes more than a lifetime. And you have to find some ways to differentiate your knowledge and expertise if you want to innovate.

Yes, nothing is perfect. But in general, it is hard to be a good guide to yourself in a new area. You can do it, but it is a skill that needs to be developed and most people don't have it (or rather, they typically have the depth-first part but not the breadth-first part, if that makes sense).

I wasn't even talking about the course quality (which as you note, is very variable) but about the curriculum.

One thing you can do as an individual teaching yourself CS, say, is to try and follow the curriculum of a known good CS program. There are issues with this, too, but at least you are getting some guidance.

The opportunity cost issue is a good point. One problem with following undergrad programs, say, is that only part of what they are doing is teaching you material, the other part is learning-how-to-learn stuff. If you are an independent learner of sufficient skill, some courses will be way too slow for you.

It would be optimal in some sense to have high level "key concept" material that you can survey efficiently and then decide when and where you need to dig deeper. It's a bit of a chicken and egg problem though, because if you are insufficiently skilled you will do poorly at the second part...

As mentioned in another comment for this post, Cracking the Code Interview is probably a good place to start in terms of reviewing some key concepts, assuming you don't have a CS degree and are largely self taught.

Of course given the libraries and systems already available, you don't practically need a lot of this knowledge, but it does help. When certain portions of an application just don't perform well, or when you hit really weird side effects of race conditions on static properties etc. I think it's also important to know the language and tools that you are working with as well as possible. It's not always possible to know everything, but you should probably read and complete at least one book on the language you are using. You can hack away in any given language for years. But until you've actually read cover to cover on a comprehensive book, you won't necessarily understand some concepts, or better still you will learn how the language does something for you, that you've been doing the hard way.

I disagree greatly, I find that the things you need to know you can often just learn on the job.

In this context we are talking precisely about the things that you cannot learn that way (at least, not efficiently).

It's obviously true that you don't need to know these things to perform your current job, but that's not what the OP was talking about.

I've been really involved in teaching people with non-traditional backgrounds (e.g. no cs degree) to program lately, and this has been my biggest struggle. There are people who are working in the field as a web dev and have been for years and can't do simple stuff like iterate. They have no understanding of what the stuff they're actually doing means or does. It's just copy and pasting snippets they see online and fiddling with it til it works.

I've taken to offering three pieces of advice to these people:

1) Go through the basic language tutorial of whatever language you use (e.g. how to declare variable, conditionals, loops)

2) Go read through the essentials guide to your languages (will be slightly higher level stuff)

3) Go read the sections on Data Structures, Concepts and Algorithms and Knowledge Base in Cracking The Coding Interview skipping the problems that aren't answered in chapter. Why? Because it's a solid primer for CS Concepts that people just don't pick up unless they have to, and most importantly short enough (< 100 pages) people will actually go through it. Large CS books with the dense writing intimidate people and so they never follow through.

I've had a lot of success with this method. It's not a formal cs education by any means but I've found it's enough to get people past the constant beginner part.

It is funny that people constantly mention these supposed developers who have jobs but cant program. Where are these jobs? I have a recent cs degree, did resume coaching, and worked through a couple coding interview exercise books. Still having trouble finding work. Show me one of these mythical jobs poorly trained programmers get, I will blow them out of the water. In reality I think most of those jobs have been outsourced and no longer exist.

Apply for bank outside of a tech hub, or any job outside of the major US cities. There's plenty of positions full of people riding the "expert beginner" status, blissfully unaware of how far behind they are because top performers leave for the hubs and the better opportunities offered there.

Oh, they exist, I've worked with a few. Luckily, no more than that.

We all know hiring and interviewing are basically a crapshoot. Good people sometimes don't get hired and bad people sometimes do.

Try large boring corporations, such as banks and insurance companies.

Boring corporation jobs are fantastic in these cases. The performance bar is low, and due to inertia within the org, you can usually learn faster as an IC and bounce somewhere better rapidly, versus being somewhere like a startup where the treadmill moves too fast for your own personal development needs.

Or the government. All you need to do is:

a.) Be able to pass a drug test

b.) Not have any problematic debts or associations with problematic groups (e.g. Aryan Nation, ISIS)

c.) Have a certification or degree that is related to the very specific thing they are asking for.

It's entirely clearing a checklist when they're recruiting. They have no idea how to evaluate for actual competence.

That's heavily dependent on where you are in government. It's not true any of the places I've worked.

Sounds like he’s talking about defense contractors. Many contracting firms just need “butts in seats” that they can bill out. Mediocre developers are better in some regards there: they bill out more hours since they’re slower, don’t mind 10+ year obsolete tech, and they don’t complain as much, which could endanger relations with the bureaucracy (customer.)

I am a defense contractor. That's not how it works. Every person on the contract has to be approved by the government individually.

Often "approved" by people who have very little idea about what they actually need in a hire. And even they're measured on how well they can keep things staffed and they're often requesting requirements for roles that are unreasonable or downright ridiculous at the pay rates they expect. So they end up with people who are good at formally ticking the right boxes, but have no Godly idea about how to enable the mission or be aware of the broader purpose behind the tasks set out for them.

It depends heavily on your COR and government leads, but the good ones are few enough that they don't get to send the norm. There are enough people who are sufficiently checked out that contracting/staffing firms can get away with murder. Indeed, it might just be impossible for them to do a good job based on what sorts of requirements they're expected to adhere to.

I worked at a defense contractor for years. Some of the guys I knew could barely program, despite years of experience, but looked good on paper. Approving them individually doesn't mean that they're not a "butt in seat" kinda person.

> Show me one of these mythical jobs poorly trained programmers get, I will blow them out of the water

Unsolicited feedback: I think it should be pointed out that your attitude probably isn't helping in your job search.

It's always a real shock to get an elite CS degree and then be told we aren't as smart as the people who got their job because they were friends with someone at the company and just happened to know Java.

> However, I didn't know how to write a for loop. > If you had asked me what "for...in" was, I > wouldn't have had a clue. And forget about > asking me how setTimeout has to do with > the call stack.

I'm self taught, I started with the C64 in the early 80s. By the time I was 15 I was working in assembly, had an excellent knowledge of what we would now call embedded software development and a working knowledge of algorithms.

I'm glad that you took the step to get a proper education. With the modern internet it's extremely easier and the quality is incomparably better than my experience of the UK educational system. Between Coursera, MIT and the vast number of excellent books it's a dream.

It's an eye-opener to me that someone can be self-taught and not understand something as basic as loops. It has been my experience hiring developers that the self-taught type are considerably stronger than those who are purely college educated. I've also noticed that the self-taught type who consider themselves software engineers all went through a two year period of intense studying of computer science and software engineering in their own time. The combination of a real working understanding of software creation with passion is an extremely strong combination.

What I've noticed is that your type don't get scared of technical changes because you're basically able to learn anything. The "college career" type tend to scare easily and also jump into management the second they get a sniff of it.

All of this said, if I was 18 now I would strongly advise myself to do 3/4 STEM A-levels (Math, Physics and something else) and then go study Computer Science at a university which has a good program. By good program - one where I'd write a compiler from scratch, learn the theory (finite automata etc), machine learning, linear algebra and hopefully something fun like building a 3d engine or game engine or something. You can do it all yourself but a three-year program certainly makes life a lot easier, plus you get to make friends and network. AND you have a nice piece of paper.

I'm self-taught since age 16. I've been able to write a for- loop since age 16. Maybe it helps that I'm self taught in a pre-google, pre-stackoverflow world. Any beginning programming book will teach for-loops.

I do have gaps in my knowledge but if I lose internet access I can still be productive. I mostly google for how to optimize when some API is slow or remind myself some method name.

I just wanted to pipe up because the top comment is "I couldn't write a for-loop" and I don't want all of us who are self taught being lobbed into that category.

At my last job I regularly had to help colleagues (some who held degrees) solve issues. Strangely they had trouble starting from scratch on something new vs maintaining old code. They found the latter easier. They also sometimes chose the wrong data structures (e.g. looping through an array every time you want an item with id=x instead of just using a hashtable)

> (e.g. looping through an array every time you want an item with id=x instead of just using a hashtable)

Huh, I had almost the exact same experience with senior devs here - they were checking if elements were in a (huge) list in nested loops, instead of using a set. Switching brought the runtime from around 2 hours to 2 minutes.

> The problem with being self taught, at least in my experience, is that you end up being very strong in whatever areas it is that interests you, and whatever areas of CS are relevant to the projects you're working on day-to-day.

Which is not necessarily a bad (for whatever definition of bad) thing.

For the startups you worked at, your ability to write code was far more valuable than your understanding of underlying CS concepts.

Kudos to you for having the maturity to acknowledge the gaps in your education and to address them in a manner that complements your life.

> The problem with being self taught, at least in my experience, is that you end up being very strong in whatever areas it is that interests you, and whatever areas of CS are relevant to the projects you're working on day-to-day.

I think this is the case even if you receive a formal CS education. I picked the most difficult or interesting classes and got As in them, and barely passed everything else in order to graduate in 4 years. Many students avoided the hard professors to protect their GPA, so it was really easy to register for them since 25% of students might drop the class.

Probably the most important thing a formal CS education does is expose you to CS fundamentals, but in my experience you end up having to be self-taught in a university setting anyway. Most of the professors I had were more interested in research than in lecturing - many lectures were completely incomprehensible. And even with amazing lecturers, I would still have to spend hundreds of hours reading and practicing on my own.

One of those classes I barely passed was algorithms, since my other workload was too great. I eventually had to self-study this subject years later to pass the tech interview torture chamber.

College was mostly an exercise in self-learning or learning how to learn for me - something I am still reaping the benefits of today.

> College was mostly an exercise in self-learning or learning how to learn for me

Definitely agree with this.

I think my data structures professor spent more time talking about chess rather than data structures.

What kind of coding did you do for 6 years if after that time you couldn't identify a for-loop?

Maybe they're was using Coffeescript with jQuery, and jQuery has some built in looping functions like .each that don't exactly look like a for loop.

A Haskell developer?

I'll bet a choklate bar that 100% of all developers who spent 6 year using Haskell knows what a for-loop is.

"for" is not that complicated, it's just mapM with its arguments pre-flipped: http://hackage.haskell.org/package/base-4.12.0.0/docs/Contro...

I don't know why you want to call that a "loop", but, sure, you do you, you crazy imperative programmers.

Because it is a loop in any sane language ... you overheaded functional programmers ..

edit: Sigh. I was jockingly mocking.

Haskell just enforces iteration through recursion.

How did he solve the iteration problem? A for loop is just syntactic sugar for a while loop.

I doubt there are many Haskell developers (or one at all) without a academic background ..

I'm a self-taught developer with haskell in my arsenal, although that being said I have an MSc in theoretical physics which probably helps me appreciate the power of its paradigm.

So you do have a academic background (especially math)..

Hi. Not an academic. Currently fiddling around with OpenGL on Haskell, for reasons.

There definitely are! Eg Jezen Thomas. Hopefully in the future also myself :)

You are sure he was never at a university? And why are you drawn to Haskell? For me I only had to deal with it a bit at university and I found the concept interesting, but could not imagine non math people to use it for anything as a language of choice

I'm not sure he never was at university, I just assume not [1].

> why are you drawn to Haskell?

I just want my programs to work. I've seen too many null pointer exceptions and other runtime errors. Runtime errors = bad. Compile errors = good.

[1]: https://news.ycombinator.com/item?id=20112065

"I just want my programs to work"

Me too ...

And I think imperative languages are way more easy and clear to read and write.

I allways imagined that you have to be a math nerd to prefer Haskell, but apparently this guy is not a math guy, but loves Haskell .. so ok, good counterpoint.

> And I think imperative languages are way more easy and clear to read and write.

Because it's what you've had exposure to. Perhaps, they're even objectively easier to read and write, I don't know. It's also completely besides my point.

My point was that I want my programs to work as desired. That's orthogonal to how easy it is to read and write. I don't want runtime exceptions where I could've gotten a compile-time error.

But I had exposure to math functions much earlier. And I never liked their syntax. I did understood the math, but the math language made it harder for me.

And null pointer exceptions? They only happen to me very rarely, when I quickly hack something together and then it is a "oh forgot - and fixed" problem. The problems I do struggle with are non reproducable race condition fun etc. and I doubt haskell could help me with them. Or I struggle, because I do not really understand my problem, or a certain libary ... or, because I misunderstood existing code.

So how on earth are correct programms orthogonal to how easy it is to read and write them?!? Did you ever had to use someone else code? Or your own that you wrote 5 years ago (or sometimes 5 days)?

With any bigger project it is all about how easy it is to read and write them.

> And null pointer exceptions? They only happen to me very rarely, when I quickly hack something together and then it is a "oh forgot - and fixed" problem.

And you never run into NPEs in production? It's something you always discover during development? How?

> The problems I do struggle with are non reproducable race condition fun etc. and I doubt haskell could help me with them.

In a pure system, thread race conditions are impossible. You can still get race conditions for your external effects, which is unavoidable.

Ouch.

Any functional language, pretty much.

They use enumeration (list/array traversal) to process a list/array of inputs.

And it entirely makes impossible the off-by-one error.

I am happy if I never have to see a for-loop again. (Even in JS, I use iteration/enumeration constructs as much as possible.)

I find it hard to believe a beginner with no theoretical CS background would pick up a functional language first. So the question still stands.

How strange. Why would you find it hard to believe?

It is one of several programming paradigms, after all. Am I missing something?

The "advanced intro CS" class at Cornell (CS 212, at least at the time) used Scheme.

Maybe I should become a high school CS teacher, because I would not curse anyone with a procedural language.

The parent said they didn't know what for-in was, which implies they were using a language like C for their side projects which only has for (i=0;i<n;i++) loops.

You can google that in 2 seconds. A CS degree isn't going to help you there if you have not covered a language that uses iterators.

Any self-respecting computer science degree education should cover at least one language that has iterators or enhanced enumeration.

My CS degree (2002-2006) did not explicitly cover "for x in y" iterators. But it did cover an understanding of algorithms and data structures well enough that I could implement one.

Which is better? YMMV.

That was probably before they were really in style e.g. C# didn't add foreach / iterators until ~2005 with v2.0 and your curriculum probably lags a bit behind the industry state-of-the-art unless it was Ivy league

It has not been very long since CS degrees were taught entirely in C89 or C++98, and there are a lot of us who won't touch Python or Java unless forced to.

exactly - I had a similar learning curve (and no CS degree) where I could never remember what certain methods did but I knew exactly what to google for the answer

That or they only used `while` (and friends if available in the language) loops.

Sounds like you didn't read the parent post carefully? He wrote:

> I didn't know how to write a for loop

If

Is Project Euler better than LeetCode for "gut checking"?

I've probably done 300 or so LC, and do some every week, mostly as an insurance policy for technical interviews if I ever opportunistically interviewed in a short time frame.

They're geared towards different goals. LC is for interviews: solving small scale problems of the scale you might get asked in an interview or come up against every day in a software job. PE is more of about curiosity and personal intellectual development. It asks something that you might never have heard about and might never see again but is often very interesting, and will stretch your ability to develop your own algorithms or to apply learnt methods to unfamiliar scenarios.

I'd recommend LC to someone who has an interview in a month, PE to someone who has one in a year.

Speaking of LeetCode, don't overlook the discussions for each problem. I think a lot of people just solve the problem, and then move on to another problem.

In the discussions many people post their solutions, and those often have bugs in obscure cases that the LeetCode grader doesn't hit. Another common thing is for the posted solutions to always give the correct answer, but miss the time or space constraints that the problem statement asked for.

I've found that reviewing those other solutions to find those issues to be quite instructive. Also, there will sometimes be a solution in there that is better than mine, which is also instructive.

I would say for technical interviews you should stick with LeetCode. Project Euler is more mathematics oriented.

This is interesting, but I don't think it's the norm for self-taught devs to not recognize a for..in. I would find that surprising. (I'm also a self-taught developer, and now I work at a larger corporation.)

Right on! Plenty of people can teach themselves to code without a university education. But the degree gives you a broad exposure to parts of CS that you may never explore as a self-taught developer. And it gives employers confidence that you have the skillset to handle whatever they throw at you.

> And it gives employers confidence that you have the skillset to handle whatever they throw at you.

Blindly having confidence in someone with a degree vs. someone with no degree is a bad mistake in this industry, IMO, sadly it happens.

It really comes down to the person, self taught or not, if you don’t pursue continuing education (which is a must in this industry) whatever CS knowledge you learnt with your degree will only take you so far.

Also said “broad exposure” can be well… self taught as well, algorithms, data structures, OS, etc… all things you can learn and "master" with no CS degree.

With all that said, I do agree CS education is essential to become a better developer. As a self thought myself, learning CS has made me a way better developer for sure, and I would advise all self taught devs to do the same, it will pay off immensely and best of all no student loan to repay.

I think you’re missing the point your parent was making...

In a good CS program you will be presented a series of challenges below your “depth”....

“wait, you want me to WRITE a data structure? I usually just use a good one from a library”

“wait, you want me to fix a compiler? I have only ever run a compiler”

“wait, you want me to write code that CREATES processes out of nothing? I am used to letting the OS create processes”

... etc. These provide you a series of epiphanies, “wow, I can build a compiler from scratch, that means I could fux with LLVM if I had to”.

Ideally, these programs are designed to take you all the way down to the bottom of the machine. For some students, the end result is confidence in their ability to “dive in” to a problem anywhere in the system.

If your point is that you can teach yourself that outside of school—absolutely. But... well, in my case I doubt I ever would have. It wasn’t fun, I was pushed to do things I would never have followed through on if I was just casually teaching myself about programming languages or operating systems.

And if your point is that students can get away without learning the material—well, also yes. Of course.

But you are wrong to dismiss the idea that a CS degree is just another few things to learn. This business of “get all the way down to the bottom and challenge yourself at every step” is kind of the whole point of a CS degree, and the world outside is not going to encourage you to do it the way your profs will.

I have seen plenty of CS grads that can barely code or put together a real solution to a problem. There is no guarantee just because someone was able to muddle through a CS degree that they can do these things. In almost all cases, you really need to evaluate whether an individual shows the aptitude to solve your problems you need solved and crank out good well thought out practical solutions that fit the scale of the business problem. The degree paper is not all that important. I would give bonus points to a candidate if they came from an accomplished but different background than CS that shows they are capable of success/mastery in multiple areas, they are adept at learning and researching new material, and they have the matching technical prowess to spearhead a real project. For instance I have known many engineering (of the physical paradigm) types that are self-taught with no CS degree that I would trust to tackle a project over any random CS degree candidate.

I did a CS degree from a good school while doing none of those except the top cause I stuck to theoretical and math electives

I've met people with Masters degrees who couldn't reason themselves out of a paper bag. It's not a guarantee.

Self taught, I remember loops were the last thing I learnt as a kid when I was working on my own Tibia servers using Lua. I remember the day it finally clicked. It helped having a forum where you could ask more experienced people to explain it plainly.

Self taught from ages 9-18, Qbasic -> C -> C++ -> PHP

I did go to college and learned Java and UML and a few other esoteric things - until I got into my data structures classes. If a self-taught software engineer feels like something is missing, take a few data structures classes. That helps a lot.

But yeah, self taught can take you pretty much anywhere unless the job reqs prevent it.

Nice to see that reference about projecteuler. Although I study Computer Engineering, which is very close to Computer Science with Electrical Engineer grade, I really focus too much in the subjects which interests me.

BTW, I reforce a lot of aspects about analysis, optimization and programming with ProjectEuler by doing Polyglot programming with some friends: https://github.com/DestructHub/ProjectEuler

i agree. i'm happy to have some CS students point me to some areas which are useful even if they are not interesting for hobbyists. There's also a lot of value in learning academic methods of investigation and research (if you are at a good university). A lot of self-taught learn a lot about computers or some programming languages, but a CS degree like any degree also teaches a lot of other valuable competences which can be hard to come by from own inspiration / initiative.

Another thing is that following and completing a degree is a practice in going from start to finnish in a multi-year project which the degree is, which is also very valuable in life in general. being able to see fruits in the distant future of your current work, and having that motivate and drive you.

A lot of people i meet who are self-taught will give up more easily due to this. not that they are quitters, but they tend to lean towards their interests, which is not always in their best interest :)

Formal bs/ms ee here as well. Started off wanting to do hardware and looked at programming as an afterthought. After a few years of working in embedded and realizing how many gaps there are in my knowledge, and how beautiful the field is, considering a doctorate in CS.

But didn't you read the core docs for the language, for loops are one of the basic idioms.

I think a lot of people learn a given language by hacking away at something they either want to create of modify. For example, in web development, I'd say most developers haven't ever read a cover to cover book on JavaScript.

I've tended to take the opposite approach, read first so I can at least grasp what I need to look for, then start applying. This of course is a mixed bag for rapidly changing/evolving tech and newer languages.

I take the same approach you do. When mentoring new developers I also start them off by assigning them tasks to read the docs for the core of the language we are working with.

I'm a bit confused at how you were able to be a successful developer, even if leveraging frameworks, without understanding loops?

Enumeration is way better than for-loops. No off-by-one errors possible. Just sayin'. ;)

I'm a doctor. No medical degree.

the real question is: are you self-taught or not?

I am! But even so, they won't hire me or let me provide services. I guess the medical industry also needs to be disrupted.