Not having the time to learn science/engineering

2/10.

Get fucked

Computer SCIENCE is way more about "useless" theory than it is about programming. That's why it isn't called IT. I remember having a few programming classes and everything else was "useless" theory because that's the whole point of the degree. Computer science is not about programming any more than civil engineering about laying bricks. Eat shit and die faggot.

sorry mate but keep memorizing very important to regurgitate some trivia

You shouldn't study computer science if your goal is to become a professional programmer. There are programming courses that exist for the purpose of teaching basic level programming logic and subsequently common business application programming, systems design and structured development. The purpose of computer science isn't any of these things.

Wow that comic is so geeky xDDD *shares on instagram with filter applied*

Then tell me what Computer Science is about if it isn't about practical application? You're just arguing semantics. Being a great programmer implies that you have a deep knowledge of CS -- how a computer works underneath the hood, data structures, and plenty of well tuned internal heuristics to guide you in developing larger projects.

Take away the practical element of CS and what are you left with? Certainly not a job...

ITT someone who doesn't know how to program anything more than macros and a bunch of if else statements talks about how advanced algorithms and data structures are useless theoretical bullshit.

Have fun writing slow, bloated bullshit code that runs in O(n^2) time. I used to think comp sci was a waste and I knew what I was doing too. But you're never going to be more than an office code monkey, easily replaced by an H1B, if you don't understand how things work on a low level and how to exploit the system for more performance and such.

I'll have you know I graduated top of my comp sci department and write the dankest code your puny C# mind could never understand. Enjoy your bubble sorts and O(n^2) algorithms, the real programmers are making important things.

Mate, can you read?

What I'm saying is that much of these desirable properties ie fast, compressed, and semantically pleasing code can only be achieved only by people who -- guess what -- program! Not neccessarily those who can hand simulate X algorithm on paper. The point is that a degree is not enough, experience is what most grads lack.

The shit flinging started when

suggested that mathematics was a pure prerequisite to programming. If you're a professional programmer, you will learn CS and any required math as you go. It's as simple as that. Dumb people think becoming good at something is top-down -- but if you're the right kind of person, bottom-up works just as well, if not better.

And no, I won't retract "useless" from "theory" in

because how many times have you used graph algorithms in your professional life? MST? Dijkstras? SCC? At some point the theory diverges from practicality (due to the top-down approach) and what you've memorized in Uni fades in relevance.

False. Being an effective and experienced programmer has no correlation to your knowledge in fundamental CS theory; being a trained computer scientists has no correlation to how "readable" and "maintainable" is your computer program solution. I really do not care if a computer scientist has terrible programming skills. What I do care is that the same scientist is able to model real world problems into mathematical models and then give me all kinds of mathematical properties about the problems.

What normally happens is that experienced programmers develop an intuitive understanding of computation over time. Now these programmers cannot succinctly describe this theory as a computer scientist would - they haven't be trained in the theory. Neither can they systematically describe all the implications of different forms a computational solution. I would hardly call an intuitive understanding of computation as "deep knowledge". Their knowledge is undoubtedly good to have, but that knowledge is incomplete in comparison to a trained computer scientist.

False. I asserted that mathematics is a prerequisite to computer science. Computer science is not the same as programming - it is a common mistake to conflate the two subjects as the same subject.

I use graphs and trees all the time in my system design and analysis. I write formal proofs whenever I design computations (that are intended to solve a given problem). I can design "distributed" systems and algorithms that are "reliable": I model my systems as mathematical objects then apply all kinds of mathematical logic to prove why my algorithms exhibit certain desirable properties and why it avoids certain undesirable properties. When I find that my algorithm has a fault through this process, I will update my algorithm to remove the faults. I do all this without ever touching a text editor or any computer. Whenever I implement my algorithm into a computer program, I have a very strong confidence that the algorithm is solid and that any implementation problems I encounter is not related to the algorithm i.e. the problem is a programming implementation problem. Computer science is not the same as computer programming.

The point of computer science is about the theory of computation. The theory of computation is not programming. Programming computers for information technology is one application of computer science. However, this is not the essence of what is computer science. Computer science is a discipline of mathematics and is concerned with the mathematics of computing data and the mathematics of the algorithms used to compute data.

If you want a job do not go to college: you go to college because you want to take up a study for education. You should study computer science in college in the same vein that you would study humanities or history: it's a discipline that you want to take. If you want a job, go study at a vocational school - these are schools that are especially intended to teach people about how to do a certain job.

It correlates, though. The kind of abstract thinking needed to understand and design algorithms is not very far from the one needed to design a sane program.
You don't need nor it helps if you just want to pajeet you way in the entreprise world.

You're right and that would be true if, on the whole, employers weren't looking for college degrees over vocational degrees because it covers their asses if the employee in question doesn't perform correctly after the hire.

In this situation, if you hire the Harvard/Stanford/4-year state uni grad, your ass is covered if it doesn't work out.

Thanks for the reply. Enlightening to know that your field really is that intense mathematically.

I'd guess though that as a whole, most people who get a CS degree are looking to become full time programmers, so the general case likely stands.

Addressing your question,

Science and engineering are fantastically vague terms. Do you have a more specific idea of what you're interested in?

Math is necessary in most fields to one degree or another.

First half is obviously accepting that you can only learn as much as you have time for, not more. If you are financially unable to subsist without a demanding job, you won't have much time, so you can't learn as much as you could have full time. Just have to deal with it.

Second half is about that upper bound being almost attainable in theory, but falling far too short in practice to the point that everything falls apart and you can't motivate yourself to study anything because it seems like such an overwhelming mountain of material that you'll never get through. Like I said, as much as you have time for... But sometimes it's impossible to say how much time it will take.

The solution is "do the best you can". Most people understand that they must structure their learning in a way that is terminally-optimal, ie. when they are finished learning a set of material, they can look back and confidently say they couldn't have learned more by using a different approach. Time is the limiting factor in how much knowledge you can acquire, and it's already a bottleneck, you don't want to waste it.

The useful insight is the optimality condition. Your learning should not be guaranteed optimal only if you finish the plan. If you get interrupted before the plan is done (due to things that come up, loss of motivation, subject turns out less interesting, unexpected difficult concepts slow you down etc) you should still come out thinking that if you had planned to have only the time you have ended up having, you would still learn in the same way, so you are still optimal.

This is a recursive model. Learning trivial unit of knowledge dk takes trivial time or effort dt. If your learning objective is trivially small, all you need is to summon dt effort at any given and presto, you're done. Literally easy as 1-2-3. If the goal K is bigger you identify K_0 = K_1 + k_0 where k_0 is "as small as possible". Ideally infinitesimal, but in practice knowledge cannot always be infinitely subdivided, and it is rarely necessary to have such fine grain if you have the discipline to regularly summon non-trivial but still small energy (eg. spend half an hour studying 3 pages of material).

Obviously this comes down to breaking down K into small chunks k_i. Terminal optimality requires only that chunks are well-selected, their order is irrelevant, since a terminal condition is necessarily path independent. But we want constant optimality, so we must carefully order k_i from most interesting to least interesting, though respecting also dependencies. Under this diminishing returns regime, even if we have to abort the learning project prematurely, we're still okay because we've learned all the best parts anyway. Then fear of not having enough time or motivation to complete a learning project ceases to cause psychic resistance to undertake that project, since even if you don't complete it, it will have been time well spent.

(cont)
How to order k_i? Most learning resources do not order their contents by importance, for various reasons. So identity function as sorter is out. I like to use a graph approach: As you learn, take notes of concepts and prerequisites (don't forget graph root showing how K breaks into each layer of k_i). Some overhead must be allowed for constructing this graph as opposed to linear learning, that's the no free lunch. But in practice I find analyzing even unfamiliar knowledge into dependency graphs is easy and comes naturally to intelligent, educated humans so the overhead has never been a big problem (and when it is it's my red flag for a project with unrealistic scope).

Once the graph is done, the "learning problem" can be represented as finding the shortest paths to a set of nodes/concepts, ie. the learning goal. If the learning project is comprehensive (ie. learn all of calculus - a futile enterprise, but learning all of a specific calculus textbook is more manageable) then all of the nodes are colored as targets. You then apply your favorite algorithm.

Most people instinctively try depth first search. A good example is the infamous "wikipedia link rabbit hole". A simple modification is to prefer breadth FS. Again, you do need to put in the effort to explicitly make the graph (I like yEd, paper or text files) and you do need to be disciplined and follow BFS. This already will massively cut down on distractions that slow your progress. One step further is Dijkstra or A*. In practice it looks like this:

This helped me be more efficient at how I learn in my free time, and also really helped with the anxiety to the tune of "what's the use even starting, I'll never finish learning this and it'll be a waste of time" because I literally aim from the outset to make sure it can't possibly be a waste (and the planning process also helps me see this explicitly, identify best and worst payoff areas etc). It also allowed me to do a sort of lazy learning, where I'll plan a big project, but then not actually learn most of it, because it turns out that most of it can be put off until it's actually necessary. Very nice performance gains similar to Haskell's lazy eval.

Let me clarify. This lazy learning is possible because two requirements are fulfilled:

- I am explicitly examining the dependence structure of the knowledge I am intending to learn, including importance of every unit to me, and have the confidence to easily decide what is optional and what is mandatory (eg. when reading a textbook linearly, you are often left to guess if the current chapter is a dead end that won't affect understanding everything else, or if it's a crucial dependencies)
- I follow a strict rule of recording the learning plan (including the graph), which can be easily saved and left to sit for a very long time depending on the vagaries of life and my learning resources

tl;dr: Don't try to learn X by reading the textbook about X start to finish. Break down the goal into small chunks that you can easily commit to. Identify dependencies. Annotate each chunk by how interesting to you it is per se. Then start with the most interesting part.