> # Teach Yourself Computer Science
>
>
>
> If you’re a self-taught engineer or bootcamp grad, you owe it to yourself to learn computer science. Thankfully, you can give yourself a world-class CS education without investing years and a small fortune in a degree program 💸.
>
> There are plenty of resources out there, but some are better than others. You don’t need yet another “200+ Free Online Courses” listicle. You need answers to these questions:
>
> - Which subjects should you learn, and why?
> - What is the best book or video lecture series for each subject?
>
> This guide is our attempt to definitively answer these questions.
>
> ## TL;DR:
>
> Study all nine subjects below, in roughly the presented order, using either the suggested textbook or video lecture series, but ideally both. Aim for 100-200 hours of study of each topic, then revist favorites throughout your career 🚀.
>
>
>
>
>
> Subject Why study? Best book Best videos Programming Don’t be the person who “never quite understood” something like recursion. Structure and Interpretation of Computer Programs Brian Harvey’s Berkeley CS 61A Computer Architecture If you don’t have a solid mental model of how a computer actually works, all of your higher-level abstractions will be brittle. Computer Organization and Design Berkeley CS 61C Algorithms and Data Structures If you don’t know how to use ubiquitous data structures like stacks, queues, trees, and graphs, you won’t be able to solve hard problems. The Algorithm Design Manual Steven Skiena’s lectures Math for CS CS is basically a runaway branch of applied math, so learning math will give you a competitive advantage. Mathematics for Computer Science Tom Leighton’s MIT 6.042J Operating Systems Most of the code you write is run by an operating system, so you should know how those interact. Operating Systems: Three Easy Pieces Berkeley CS 162 Computer Networking The Internet turned out to be a big deal: understand how it works to unlock its full potential. Computer Networking: A Top-Down Approach Stanford CS 144 Databases Data is at the heart of most significant programs, but few understand how database systems actually work. Readings in Database Systems Joe Hellerstein’s Berkeley CS 186 Languages and Compilers If you understand how languages and compilers actually work, you’ll write better code and learn new languages more easily. Compilers: Principles, Techniques and Tools Alex Aiken’s course on Lagunita Distributed Systems These days, most systems are distributed systems. Distributed Systems, 3rd Edition by Maarten van Steen 🤷‍
>
> ## Why learn computer science?
>
> There are 2 types of software engineer: those who understand computer science well enough to do challenging, innovative work, and those who just get by because they’re familiar with a few high level tools.
>
> Both call themselves software engineers, and both tend to earn similar salaries in their early careers. But Type 1 engineers grow in to more fullfilling and well-remunerated work over time, whether that’s valuable commercial work or breakthrough open-source projects, technical leadership or high-quality individual contributions.
>
>
>
> Type 1 engineers find ways to learn computer science in depth, whether through conventional means or by relentlessly learning throughout their careers. Type 2 engineers typically stay at the surface, learning specific tools and technologies rather than their underlying foundations, only picking up new skills when the winds of technical fashion change.
>
> Currently, the number of people entering the industry is rapidly increasing, while the number of CS grads is essentially static. This oversupply of Type 2 engineers is starting to reduce their employment opportunities and keep them out of the industry’s more fulfilling work. Whether you’re striving to become a Type 1 engineer or simply looking for more job security, learning computer science is the only reliable path.
>
>
>
>
>
> ## Subject guides
>
> ### Programming
>
> Most undergraduate CS programs start with an “introduction” to computer programming. The best versions of these courses cater not just to novices, but also to those who missed beneficial concepts and programming models while first learning to code.
>
> Our standard recommendation for this content is the classic Structure and Interpretation of Computer Programs, which is available online for free both as a book, and as a set of MIT video lectures. While those lectures are great, our video suggestion is actually Brian Harvey’s SICP lectures (for the 61A course at Berkeley) instead. These are more refined and better targeted at new students than are the MIT lectures.
>
> We recommend working through at least the first three chapters of SICP and doing the exercises. For additional practice, work through a set of small programming problems like those on exercism.
>
> For those who find SICP too challenging, we recommend How to Design Programs. For those who find it too easy, we recommend Concepts, Techniques, and Models of Computer Programming.
>
>
>
> [Structure and Interpretation of Computer Programs](https://teachyourselfcs.com//sicp.jpg)
>
>
>
> ### Computer Architecture
>
> Computer Architecture—sometimes called “computer systems” or “computer organization”—is an important first look at computing below the surface of software. In our experience, it’s the most neglected area among self-taught software engineers.
>
> The Elements of Computing Systems, also known as “Nand2Tetris” is an ambitious book attempting to give you a cohesive understanding of how everything in a computer works. Each chapter involves building a small piece of the overall system, from writing elementary logic gates in HDL, through a CPU and assembler, all the way to an application the size of a Tetris game.
>
> We recommend reading through the first six chapters of the book and completing the associated projects. This will develop your understanding of the relationship between the architecture of the machine and the software that runs on it.
>
> The first half of the book (and all of its projects), are available for free from the Nand2Tetris website. It’s also available as a Coursera course with accompanying videos.
>
> In seeking simplicity and cohesiveness, Nand2Tetris trades off depth. In particular, two very important concepts in modern computer architectures are pipelining and memory hierarchy, but both are mostly absent from the text.
>
> Once you feel comfortable with the content of Nand2Tetris, our next suggestion is Patterson and Hennesy’s Computer Organization and Design, an excellent and now classic text. Not every section in the book is essential; we suggest following Berkeley’s CS61C course “Great Ideas in Computer Architecture” for specific readings. The lecture notes and labs are available online, and past lectures are on the Internet Archive.
>
>
>
>
>
> ### Algorithms and Data Structures
>
> We agree with decades of common wisdom that familiarity with common algorithms and data structures is one of the most empowering aspects of a computer science education. This is also a great place to train one’s general problem-solving abilities, which will pay off in every other area of study.
>
> There are hundreds of books available, but our favorite is The Algorithm Design Manual by Steven Skiena. He clearly loves this stuff and can’t wait to help you understand it. This is a refreshing change, in our opinion, from the more commonly recommended Cormen, Leiserson, Rivest & Stein, or Sedgewick books. These last two texts tend to be too proof-heavy for those learning the material primarily to help them solve problems.
>

> (continues in next comment)

[2 of 4]

• How curious are you? Do you have more ideas then you can execute? What are your curiosities about? What are your ideas about - is it environmental or conceptual, and can you please elaborate?
  
  • I think this is something I struggle with on a daily basis. I like many things, or so I like to believe. Like I feel that everything’s interesting and everything is connected somehow through symbols. I like thinking about these symbols and connections constantly. So my ideas are about concepts mostly. I can’t remember facts if I can’t attach them to concepts that make sense to me.
    
  • This has been my latest conflict I have to say. I started a career in EE, and then I shifted to computer science. I’ve wanted since I was an undergrad to start a research path, but I’ve been struggling to find something I really really love. I am not good at taking decisions, but an academic path looks now like my best bet for not working in a desk never again (I like having my own desk at home, though).
    
  • I’m confident everything will be good at the end, and I am confident I can do almost anything. Not trying to be cocky, is just that I know I’m physically and mentally capable of learning anything (in the realm of normal stuff, of course I won’t build a heavy falcon myself), so unless that does not change, I’m good. On the other hand, being so certain about that backfires at me, filling my head with “what ifs”
    
  • I have this bad habit of reading (and most of the time not finishing) books in parallel, now I’m reading about
    
    • Carl Jung (https://www.amazon.com/Jung-Short-Introduction-Anthony-Stevens/dp/0192854585 mostly motivated by understanding this mbti thingy)
      
    • About network science (https://www.oreilly.com/library/view/complex-network-analysis/9781680505399/ and https://www.amazon.com/Networks-Introduction-Mark-Newman/dp/0199206651 because network analysis can be applied to almost anything)
      
    • Machine Learning (http://shop.oreilly.com/product/0636920052289.do) because is what the cool kids do in IT now or so I’ve learned, I’m more into software architecture though, and
      
    • EGB (https://www.amazon.com/G%C3%B6del-Escher-Bach-Eternal-Golden/dp/0465026567) which is a beast and I wanted to get my feet wet about cognitive science and semiotic. I am at about 40% of all of them,
      
  • I pick a chapter until I finish it, and then I move on to the next book, when I have time. I’ve lost interest in reading fiction, I get that from reading graphic novels and manga, mostly. If it matters something, currently ongoing mangas I like are Hajime no Ippo, One Piece, Vinland Saga and The Promised Neverland.
    
• Would you enjoy taking on a leadership position? Do you think you would be good at it? What would your leadership style be?
  
  • I’m not very good at getting stuff done so I would probably suck as a leader of anything. But hey, I am good listening to people and helping them improve. I also don’t think I’m a good teamplayer. I’m bad at following instructions if I don’t trust them. During college I was the guy that ended redoing the work of others during group assignments, because I either I was not satisfied with their work or I was not good at giving instructions. I didn’t know at that moment I was being a dick and I know now, and it’s not something I’m proud of. I'm working on it.
    
• Are you coordinated? Why do you feel as if you are or are not? Do you enjoy working with your hands in some form? Describe your activity?
  
  • I used to draw more when I was younger, and did a bit of woodwork also. I had plants. I like to cook, and have strong opinions on food. I like creating stuff with my hands, I consider myself a creative person. In short, I am coordinated, but not so with team activities like team sports.
    
• Are you artistic? If yes, describe your art? If you are not particular artistic but can appreciate art please likewise describe what forums of art you enjoy. Please explain your answer.
  
  • It’s hard to pin down what kind of art I like, I just know I like something after I’ve seen it or told about, with no particular topic. I don’t understand sculpture, and I vaguely get poetry. Regarding drawing, I appreciate the flow and light in shapes. I was into human figure for some years, and I did a lot of drawings that were good.
    
  • I know a bit of guitar and ukulele, but I never played for others than girls I like. I am too shy of my voice, my singing and technique, I know it needs improving. I took singing classes once but with only the gist of it I got it’s something that requires more discipline and time than what I’m willing to spend.
    
• What's your opinion about the past, present, and future? How do you deal with them?
  
  • uhm, now I strive to live a life that maximises happiness and minimizes regret. At my age I think I know enough about the things I can control, and play along with that hand, always with the best intentions, and I am optimist about the future.
    
  • Sometimes I regret not being like this in the past, however, and I see myself revisiting things I would have done better, like studying more, eating better, loved more.
    
• How do you act when others request your help to do something (anything)? If you would decide to help them, why would you do so?
  
  • I always help, I believe in karma as a thing (I mean, not religiously) and that life has been really good to me. I don’t help when I know I can’t help, or when I’m being ordered to or asked in a bad way i.e. makes me feel bad. I have trouble noticing these situations though.

Scott Meyers made Effective Modern C++ which has a lot of changes in the language documented and documented well. If you're proficient in C++ I highly recommend checking it out. (Or watch: https://youtu.be/xnqTKD8uD64)

The big one is ownership semantics leading to smart pointers.

The general rule of thumb is you should never use a raw pointer, except when you're not transferring ownership. Also, consider weak_ptr, and references, always references.

SFINAE in class, really? I'm impressed. Use constexpr if instead when you can (90% of the time). SFINAE should really only be used for firmware and library engineers and is on its way out, if concepts ever get finished.

Metaprogramming in C++? More like dark magic, taking advantage of C++17 plus SFINAE. No, I think you mean meta template programming, most likely. Meta template programming has been replaced with constexpr if as well. Don't do it, unless you like pranking your coworkers. You can write meta template programming to crashes IDEs when they try to read the file.

>data structure/algorithms (arrays/linked lists/trees/maps/stacks/queues/searching/sorting/graph searches and efficiency considerations)

That's more data structures than algorithms. I personally think algorithms are more important, but I digress:

std::deque is important, and no it's not a doubly linked-list. All the different hash and tree structures like std::unordered_multiset are super helpful to know, even if you never use them. Understanding sets and tuples too. None of this is specifically modern C++, except that most of these data types didn't exist or were incomplete 'till C++11. cppreference is super helpful and imho should be used regularly.

Oh and C++ has a whole slew of algorithm functions and classes now. Check them out on cppreference, but imho they're not super helpful like they are in Python or R. Really, learning how to make an algorithm is more important.

Oh, I've been rambling about old stuff. Okay back to modern: the different kinds of bracket initializations are important. Previously initialization had a lot of () in it, so auto foo = Bar(0);, should that be a () or a {}? Looking at it I can tell you it most likely should be auto foo = Bar{0}; but it's not a guarantee. I'd have to look at Bar's source code to verify.

There are modern idioms that should be considered, like aaa or almost always auto, and should be followed when possible and reasonable to do so.

Lets see, what else.. nullptr instead of NULL. A lot of the pre processor can be replaced with constexpr and constexpr if.

Ranges is definitely worth learning but that's a C++20ism. std::expected is super helpful to know but that's a C++20ism as well. (Just to know there are more ways to handle exceptions and which to use.)

They teach perfect forwarding in classes you go to? What classes are you taking? That's impressive. I'd say std::move is super important to know and understand, but it's a given if you understand ownership semantics.

Oh, there are new keywords. default and delete should be used liberally when creating a new class, in conjunction with the 0,3,5 idiom. override is important on the inheritance front, and imho should be enforced using a compiler flag.

Oh! Threading and file handling have had a complete over hall. Now C++ does it instead of using the OS' libraries. Threading is a bit of a sinkhole and should be known inside and out if you're working on your own project. If the project is large enough the framework should handle all of the threading for you. Otherwise, it is important. (eg, lockfree programming is kind of important in most situations.)

And of course lambdas. Super useful. No more void *. I can't believe I almost forgot them. Pass code around, not variables.

RVO is important when considering ownership semantics. Basically, don't std::move on return unless necessary. Don't return a pointer or a reference unless necessary.

Gosh there was something else..

Let's see, inheritance isn't taught right in any book or class I've seen. There is a prerequisite of understanding how to make types. This is important for quant work, because you'll probably be using custom types everywhere. Learning how to make them in C++ is important, not just use them, because it builds the prerequisite conceptual understanding for multiple inheritance.

Inheritance in Haskell terms is subtyping or abstract typing. Abstract classes (not necessarily fully abstract, just not concrete) are a type of class, sometimes called a subtype or abstract type. Inheritance isn't just for gluing code together. It's for having types of classes, or categories of classes. This is something understood on a senior level, but because it is so difficult to understand modern languages tend to just ban multiple inheritance out right. C++ has it, so understanding the thought process to not doing it right, but thinking about it right, is important.

I'm sure there is more. Oh, there is a new syntax Herb Sutter has been pushing which is pretty great, if the whole code base has it. .... and I can't find the video. The skinny is int foo(double bar) becomes auto foo(double bar) -> int. The philosophy is the function name should be as far as possible to the left hand side to make code more readable, because types can get stupidly long sometimes. The C++98 equiv, which thankfully most of the code bases I've worked on do:

int
foo(double bar)

Oh and std::variant combined with constexpr replaces unions.

Basically, if it's in C there is a C++ equiv. Use that instead. The exception is native types, and functions. Even loops have changed to range based for loops eg for(auto it : foo) and with std::for_each, though C style loops are still useful and used sometimes. Oh and structs are still around and can be popular, but std::variant or std::all might be a better option depending on what you're doing.

And the most important saved for last. Read http://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines learn it, love it. For example, checkout F.15. Super helpful. This is official, so you can use it for coding disputes and what not.

phew \>.\<

You have a long journey ahead of you, but here goes :D

Beginner

C++ Primer: One of the better introductory books.

The C++ Standard Template Library: A Tutorial and Reference: Goes over the standard template library in fantastic detail, a must if you're going to be spending a lot of time writing C++.

The C++ Programming Language: Now that you have a good idea of how C++ is used, it's time to go over it again. TCPPL is written by the language's creator and is intended as an introductory book for experienced programmers. That said I think it's best read once you're already comfortable with the language so that you can full appreciate his nuggets of wisdom.


Intermediate

Modern C++ Design: Covers how to write reusable C++ code and common design patterns. You can definitely have started game programming by the time you read this book, however it's definitely something you should have on your reading list.

C++ Templates: Touches on some similar material as Modern C++ Design, but will help you get to grips with C++ Template programming and how to write reusable code.

Effective C++: Practical advise about C++ do's and dont's. Again, this isn't mandatory knowledge for gamedev, but it's advice is definitely invaluable.

Design Patterns: Teaches you commonly used design patterns. Especially useful if you're working as part of a team as it gives you a common set of names for design patterns.

Advanced

C++ Concurrency in Action: Don't be put off by the fact I've put this as an "advanced" topic, it's more that you will get more benefit out of knowing the other subjects first. Concurrency in C++11 is pretty easy and this book is a fantastic guide for learning how its done.

Graphics Programming

OpenGL: A surprisingly well written specification in that it's pretty easy to understand! While it's probably not the best resource for learning OpenGL, it's definitely worth looking at. [edit: Mix it in with Open.gl and arcsynthesis's tutorials for practical examples and you're off to a good start!]

OpenGL Superbible: The OpenGL superbible is one of the best ways to learn modern OpenGL. Sadly this isn't saying much, in fact the only other book appears to be the "Orange Book", however my sources indicate that is terrible. So you're just going to have suck it up and learn from the OGL Superbible![edit: in retrospect, just stick to free tutorials I've linked above. You'll learn more from them, and be less confused by what is 3rd party code supplied by the book. Substitute the "rendering" techniques you would learn from a 3d book with a good 3d math book and realtime rendering (links below)]


Essential Mathematics for Game Programmers or 3D Math Primer for Graphics and Game Development: 3D programming involves a lot of math, these books cover topics that OpenGL/DirectX books tend to rush over.

Realtime Rendering: A graphics library independent explanation of a number of modern graphical techniques, very useful with teaching you inventive ways to use your newly found 3d graphical talents!

Android team lead here, I've been working with Android commercially since 2009 (before Android 2.0 was released) and have worked at, or done work for, some big companies (Mozilla, Intel, Google, HTC...). I was in a very similar situation to you in that I was a web development and was bored, I'd been playing with Android in my spare time; I got my first break by volunteering to do an android app at the company I worked for, and went from permanent employee to contractor fairly quickly after that and have been doing it ever since.

First thing to say is that if you can get your currently company to pay you to learn android and stay with them, that's a win win for both parties (you get to learn something new without a drop in salary and don't have to interview and they don't lose a good member of staff).

In terms of moving company, I don't know where you are based, but here in the UK I often see junior Android contract roles coming up for £200-300 a day. Failing that it's just a case of applying for lots of poisitions and really knowing your stuff.

What I would look for in a junior is to have read, understood and put in to practice Clean Code (https://www.amazon.co.uk/Clean-Code-Handbook-Software-Craftsmanship/dp/0132350882) and Design Patterns (https://www.amazon.co.uk/Head-First-Design-Patterns-Freeman/dp/0596007124). I would expect you to have a good understanding of basic Java and OOP; a working understanding of MVP or MVVM (https://news.realm.io/news/eric-maxwell-mvc-mvp-and-mvvm-on-android/, https://www.linkedin.com/pulse/understanding-difference-between-mvc-mvp-mvvm-design-rishabh-software); understand threading; know about all the major parts of Android (Services, Broadcast receviers, Activities, Fragments etc); know how to write a custom view; be able to efficiently design a layout in XML and correctly apply styles and themes; understand the support libraries - what they contain, why they exist and what they are used for (and also when you don't need them); understand the difference between unit testing and integration testing and know what makes for a good test; the Gradle build system is a really nice way of defining your project build - knowing the fundamentals is essential.

A few of the main libraries I'd expect you to know and have used would be OkHttp (https://github.com/square/okhttp), Retrofit (https://github.com/square/retrofit), Butterknife (https://jakewharton.github.io/butterknife/), Picasso (https://square.github.io/picasso/) or some other image loading library, GSON (https://github.com/google/gson) or Moshi (https://github.com/square/moshi) or some other json parsing library

If you want to level up then there are loads of advanced topics surrounding Android. Any of these following topics will take a while to learn, but will be worth it and will look good in interviews and on you CV:

• RxJava (http://blog.danlew.net/2014/09/15/grokking-rxjava-part-1/) - This is the new hotness in the mobile world (including iOS) at the moment. Version two of rxJava has just been released and knowing this will probably land you a job super quick.
  
• Dagger (https://www.youtube.com/watch?v=Qwk7ESmaCq0) - Dependency injection library. I actually find it super confusing to setup because of some overloaded annotations and lack of clean documentation, but lots of places use and expect you to know it, so it'd be a good idea to at least get a basic understanding of it.
  
• Kotlin (https://developer.android.com/kotlin/resources.html) - The new Android language - not many places are using in production but learning it now would be a great way to invest in the future (and it's fun)
  
• Clean Code architecture (https://fernandocejas.com/2014/09/03/architecting-android-the-clean-way/, https://fernandocejas.com/2015/07/18/architecting-android-the-evolution/, https://github.com/android10/Android-CleanArchitecture) - A great architecture that I use in my current projects - being able to mention this and talk about it would super impress me from someone with your experience.
  
• An understanding of different architectures (https://github.com/googlesamples/android-architecture) - A great resource for learning, it's a simple todo app but build in lots of different ways
  
• Room & the other new Android architecture libraries they've recently announced (https://developer.android.com/topic/libraries/architecture/index.html)
  
  There's so much more - this is a large topic and it's easy to feel overwhelmed (I know I did & do) but the sheer amount of stuff to learn, but take it slowly and it'll come. The best way that I found to learn all of this stuff is to have a personal project which I was working on (I started doing an app which teaches you how to play guitar - never released it but learned so much). Get the fundamentals down and them start looking at some of the more advanced things. A good test app would be to write a Reddit client (they have open APIs: https://www.reddit.com/dev/api/) - this will get you up to speed on networking, background services (to poll the API to see if you have any messages) etc
  
  Let me know if this helped or if you want to chat about stuff. Happy to help.

Firstly, I wanna say sorry for your losses. You've had a rough life but good shit trudging through it 3Head, although you've arguably lost the best years of your life (Chester Bennington Who? Robin Williams Who?)

Now, I don't give a fuck if you were #1 or #777 in your programming class at your trashy school. You didn't get my point that however well you do in school doesn't matter, because regardless, you're bounded to solely that school, you're not nationally or internationally ranked (Being an analogy Andy, the #1 runner in my high school runs a 16:30 5K which is pretty good, but is no where near the international Olympiad level; the same is true with you and your trash-tier programming ability, you haven't accomplished anything in that field outside of school [and don't blame this on your illness, if you realized you were intelligent in high school, you would've been something back then, before your chronic disease emerged])

Also, those are the most fundamental basics of a multi-paradigm programming language, I learned Object-Oriented, exception-handling, recursion, generics, use of external libraries, methods, events, pointers, e.t.c. in 7th grade and there are hundreds of kids who'd done so at a much earlier age than me. Anyone with a somewhat quantifiable amount of intellect can understand that shit, that's the basics. You never truly got into programming, I can tell, as if you did, you would've instead listed the more complex theorems that actually require intellect to be able to derive and truly understand (algorithms and data structures) such as Computational Geometry and Shortest Path Algorithms(BFS, DFS, Dijkstra, Floyd Warshall, Prim, Kruskal), Computational Number Theory, Hashing, Trees, Data Structures(segment tree, fenwick tree, disjoint sets, Heavy-Light Decomposition). The list is endless; although you're 30 and pretty far behind, if you're at all interested in truly understanding these algorithms, their proofs and derivations (if you want to work at google, apple, e.t.c you need to learn), here's a link to an introductory book written in Pseudocode: https://www.amazon.com/Introduction-Algorithms-3rd-MIT-Press/dp/0262033844

(I may be immensely toxic, but just trying to help you out if you're still trynna stay on the CS path)

Also, you don't understand the problem-solving I was referring to. The questions you are referring to, given in school, require very basic problem-solving skills that don't truly captivate the beautiful art of problem-solving. True problem-solving is when you're faced with the most difficult and complex ad-hoc (One subdivision of programming problem topics contains problems for which there exists no general technique or algorithm, i.e. no well-studied solution. These are known as ad*-hoc problems. Each* ad*-*hoc problem is unique, and requires a specialized approach) problem ever, where you have to manipulate it to devise an innately beautiful algorithm which beautifully merges a bunch of previous theorems that seem unrelated to creatively take a shortcut to the solution in a truly brilliant manner(this is easy to explain to others who understand problem-solving, but it's kind of hard to generalize it so sorry for the butchered explanation, here's a link that you can explore to learn more: https://artofproblemsolving.com/ )

Here's a programming question (from the final round of the USA Computing Olympiad for the brightest programmers across the nation, which I successfully solved). It may seem simple at first due to its short length, it's actually immensely complicated and requires immense critical thinking+IQ to come up with a unique algorithm which solves every possible test case; in my eyes, it truly captivates the art of problem-solving. If you're at all interested in seeing it here's a link: http://www.usaco.org/index.php?page=viewproblem2&cpid=950 (and don't lie and tell me you solved it, I know you can't because it requires knowledge of the complex Gauss-Bonnet theorem in topology/computational geometry taught far after Multivariable Calculus: https://en.wikipedia.org/wiki/Gauss%E2%80%93Bonnet_theorem )

TWITCH: And no, your remark about finding another way in was pretty retarded, of course, everyone would think of doing that, that's simple ban evasion. I'm obviously not gonna create a new twitch account to fucking chat, I already stream myself programming on my main twitch account so I'm not gonna go and make a whole new account to just chat, I'll donate someday and get unbanned from Felix's channel. Furthermore, I'd have to resub and build up my sub-streak all over again so not worth.

Also, I highly doubt I would've committed suicide if I were in your shoes because I would still have something going for me, the fact that I can and will make a meaningful contribution to society. And I know why you "weren't good enough for your interview," because you couldn't problem solve, most interviewers for companies such as Google and SpaceX ask questions that are slightly easier than those found in competitive programming competitions.

And bill gates and zuckerberg were dropouts because they were entrepreneurs, they could've easily finished college but it wasn't worth it because their companies started rapidly growing; they have skills that you don't, you're just a random dropout for no reason, most dropouts that make it big drop out because they see another vision for themselves. The main reason I want to go to a top university isn't for the education, I could learn all that I want from edX and Coursera, it's to meet others top students in hopes of creating our own successful business from our dorm.

If you're still interested in becoming a dev, hope that helped (although I'm half your age so I don't see why you'd listen to a zoomer like me regardless).

Edit (Didn't see your edit, I'm boutta go hard for disrespecting me): You're fucking retarded lmfao, your reddit is filled with gaming related shit (you're 30 and you game for a living, sad life) so I scrolled down to see the first post not in r/xqcow or r/letitidie and your age was there, I didn't see any sad shit you posted.

And yes, I do actually help others and inspire those invested in my field that I find in school and other communities, if I realize that they have recognizable talent and intellect to be something, but I'm not gonna be a soyboy cucklord who tells someone they can do it when they're realistically not smart enough to, I won't hold their hand and tell them they're worth something when they're really just an average andy that doesn't have the unique ability to ever do anything meaningful; I'll gladly shit on others who aren't smart and sit in a corner studying all day for the SAT because they can't naturally do well; I'll gladly tell them to kys, as talent outweighs hard work heavily.

I'm not privileged, I started at the fucking bottom (Kapp -> low middle-class) and reached the top myself, if you can't do it and are complaining, then natural selection retard.

(Also, Iostux is dogshit, I'd roll him in a 1v1 Kapp)

Sure, there are a few directions you could go:

Algorithms: A basic understanding of how to think about and analyze algorithms is pretty necessary if you were to go into combinatorial optimization and is a generally useful topic to know in general. CLRS is the most famous introductory book on algorithms, and it gets the job done. It's long, but I thought it was decent enough. There are also plenty of video lectures on algorithms online; I liked the MIT OpenCourseWare of this class.

Graph Theory: Many combinatorial optimization problems involve graphs, so you would definitely want to know some graph theory. It's also super interesting, and definitely worth learning regardless! West is a good book with lots of exercises. Bondy and Murty and Diestel also have good books, which are freely available in PDF if you do a google search. Since you're doing a project on traffic optimization, you might find network flows interesting. Networks are directed graphs, where you think about moving "flow" across the edges of the graph, so they are useful for modelling a lot of real-life problems, including traffic. Ahuja is the best book I know on network flows.

Linear and Integer Programming: Many optimization problems can be described as maximizing (or minimizing) some linear function subject to a set of linear constraints. These are linear programs (LPs). If the variables need to take on integer values, then you have an integer program (IP). Most combinatorial optimization problems can be formulated as integer programs. Integer programming is NP-hard, but in practice there are methods that can solve most IPs , even very large ones, relatively quickly. So, if you actually want to optimize things in real-life this is a very useful thing to know. There's also a mathematically rich field of developing methods to solve IPs. It's a bit of a different flavor than the rest of this stuff, but it's definitely a fertile area of research. Bertsimas is good for learning linear programming. Unfortunately, I don't have a good recommendation for learning integer programming from scratch. Perhaps the chapters in Papadimitriou - Combinatorial Optimization would be a good introduction.

Approximation Algorithms: This is about algorithms which quickly (in polynomial time) find provably good but not necessarily optimal solutions to NP-hard problems. Williamson and Shmoys have a great book that is freely available here.

The last book I'd recommend is Schrijver. This is the bible for the field. I put it here at the end because it's more of a reference book rather than something you could read cover to cover, but it's REALLY good.

Lastly, if you like traffic optimization, maybe look up what people are doing in operations research departments. A lot of OR is about modelling real problems with math and analyzing the models, so this would include things like traffic optimization, vehicle routing problems, designing smart electric grids, financial engineering, etc.

Edit: Not sure why my links aren't all formatting correctly... sorry!

> Someone said I might be "destined for grad school" which is fine, but I'd rather know the ins and outs before I get my mind wrapped around the idea.

Depends what you want to do. If you want to work in some very focused area, the MS might help. If you just want one of the multitude of SWE jobs where you get paid big bucks to contribute to a really cool project, then just get a job after your BS. You can always get an MS later, without quitting your job even.

> From talking about it in passing, it has to do with turning it into bits and the usage of an assembly language?

More or less, but to be pedantic, everything is always bits, and it's more about machine language the assembly language (which is a human readable version of machine code). The NAND to Tetris course I mentioned will make this all extremely crystal clear to you, possibly moreso than any class you actually take at school.

> Based on what you say later on, is it safe to say that abstraction is just the idea of isolating a piece of code, presuming it works, and letting it do its thing while you work around it to produce something better?

Not just code, but any physical resource. When you connect to a website over the HTTP protocol, your entire interaction with that web server is defined by that protocol. All you know is that there are certain commands you can send it, and certain responses it will give you back (you personally don't send these commands, your web browser does it for you). That web server is a fairly complex system in itself, but for your purposes, it's just a thing that takes requests and returns responses. It's no different than a method in a piece of code. This is what abstraction is, and it allows extremely complex projects to be managed understandably, by individuals or by teams.

At the same time, to be a competent computer scientist, you should know how a web server works... roughly speaking. But as a programmer sending it requests, you don't have to burden yourself with thinking about it.

> If you could change one thing about the order that you learned things, would you first learn about how a computer works before you began programming? And if so, how far in-depth would you go before you would be satisfied?

Honestly, I'd like to have had a better bottom-to-top view of computers before getting into all the super focuses classes that each teach a single aspect, but require cursory knowledge of the others. In addition to the book I mentioned already, another great one is CODE by Charles Petzold. It's lighter reading, and has no projects/assignments. It reads more like a novel and is really written for anybody, but at the same time it can explain a lot to a new CS student or even to a CS grad who got no good "high level" view in his classes.

> I'd love to read "From NAND to Tetris" based on what you describe it as, provided it doesn't require a heavy foundation of computer architecture. I myself have always wanted to know how a computer is built, what parts make simple functions like moving the cursor and key input work, how memory is stored, etc. Would "From NAND to Tetris" teach me those types of things and beyond?

Yes. The author says there are no prerequisites except knowing a programming language. It's a 12 chapter book that starts off with boolean gates (the basic building block of a microcircuit) and ends with Tetris. Each chapter in between builds something on the results of the previous chapter. Essentially, by the end of the book, you've built a video game from boolean gates. But thanks to the abstractions at each level, you don't have to concern yourself with transistors when writing your game; you only have to think about how a Tetris shape can move. Each chapter has a project, and they're not easy. But I loved, loved, loved those projects. I did all of them in about 2 months, in a pretty addictive approach. Basically, you learn about things like compilers, operating systems, etc, and you build simple "toy" versions of each one, but seeing how all of these connect together, eve with toy versions, is IMO more useful than a course that teaches you how to build a real compiler, but without a good understanding of how that compiler works in a larger system. Here's the book: https://www.amazon.com/Elements-Computing-Systems-Building-Principles/dp/0262640686

> Would it be safe to say that CLRS is meant for seasoned veterans or those who are fascinated by DS&A, rather than someone like me who just wants to understand how they work and when I could use them in a program?
> Would Skiena's book be something to read after my DS&A course, based on your description of it?

I don't know who CLRS is intended for. Probably beginners. I actually don't like the book that much and really haven't read the whole thing, but I've looked up certain algorithms in it just to see how they're presented. It's not bad by any means, just not my style.

And yeah, I'd read Skiena at some point in your progression. Whenever. I've actually read it twice... both times when preparing for really tough job interviews, based on this famous post... and it paid off.

Hey! I can relate exactly to where your'e coming from. I, some years ago, decided I wanted to get into building synths. I ended up getting a job at a pedal company and have spent more time learning to build and repair pedals than synths. I don't work there anymore, but it gave me a lot of perspective into the field as we also made euro-rack modules.

First up: I don't want to scare you off from this, but just want to give you a realistic perspective so that you go into this knowing what you are getting into. Making synths is hard and it's expensive. As far as electronic projects go, making a synthesizer is up there on the list. I've repaired powerplant turbine controller circuitboards that were simpler than some of the synths I've owned. This isn't to say, "don't do it!" but, expect to learn a lot of fundamental and intermediate stuff before you ever have something like a fully-featured synth that you built in your hands.

It's also expensive. A cheap synth prototype is going to cost a couple hundred bucks, easy, while a more fully-featured prototype could cost into the thousands to produce, and that's just to build one working prototype. If you want to make a run of products you're going to need money up front, and not a small amount. So, just be prepared for that inevitability.

One final note is that my perspective is broad (digital and analog) but is rooted in analog electronics because that's where I started. This isn't the only path you can take to get to where you want to go but honestly in my opinion, even if you're going to go mostly digital later, you need to understand analog.

If you have never messed with electronics much before I highly recommend the Make: Electronics book. I'm a hands-on person and this was the most effective book I found that let me study electronics fundamentals the way I wanted to; by making stuff! No matter which direction you go on (digital, analog, hybrid, DSP, SID, etc) you're going to want to know how to pick the right resistor, or how to pop an LED into a circuit, and this book will teach you that.

Solid follow-up books from there are Make: More Electronics, Practical Electronics for Inventors, How To Diagnose and Fix Everything Electronic, and The Art of Electronics. All of these books are good books that touch on different concepts you will find useful, so I encourage you to look through them and decide for yourself which of these interests you.

Around this same time, I'd encourage you to start getting into kits. Honestly, before you build anything synth, I'm going to recommend you build some pedals. Effects pedals are fun and rewarding to build without being too hard. Start with a distortion circuit and work your way up from there. Once you can build a delay pedal without freaking out, move on to euro-rack kits, or other synth kits. While you're building these kits, don't just build them, play with the circuits! Try swapping components where you think you can, or adding features. One of my first kits was a distortion pedal with a single knob, but by the time I was done tweaking on it it had five knobs and two toggle switches!

Once you're feeling somewhat comfortable with electronics, then you can dive into the holy grail of analog synth design: Make: Analog Synthesizers this amazing book was written by the brilliant Ray Wilson who recently passed away. His life's goal was to bring the art of building analog synths into the hands of anyone who wanted to learn, and there is no better place to receive his great wisdom than this book. You should also check out his website Music From Outer Space along the way, but the book covers so much more than his website.

If you make through most or all of those resources you are going to be well-equipped to take on a career in synth-building! I'm personally still on that last step (trying to find the time to tackle Make: Analog Synthesizers) but hope within the next year or two to get that under my belt and start diving in deep myself. It's been a fun journey of learning and discovery and I wouldn't trade the skills I've gained in electronics for much.

Hope this helps, good luck!

I've posted this before but I'll repost it here:

Now in terms of the question that you ask in the title - this is what I recommend:

Job Interview Prep

1. Cracking the Coding Interview: 189 Programming Questions and Solutions
   
2. Programming Interviews Exposed: Coding Your Way Through the Interview
   
3. Introduction to Algorithms
   
4. The Algorithm Design Manual
   
5. Effective Java
   
6. Concurrent Programming in Java™: Design Principles and Pattern
   
7. Modern Operating Systems
   
8. Programming Pearls
   
9. Discrete Mathematics for Computer Scientists
   
   

   Junior Software Engineer Reading List
   

   
   

   Read This First
   

   
   

10. Pragmatic Thinking and Learning: Refactor Your Wetware
    
    

    Fundementals
    

    
    

11. Code Complete: A Practical Handbook of Software Construction
    
12. Software Estimation: Demystifying the Black Art
    
13. Software Engineering: A Practitioner's Approach
    
14. Refactoring: Improving the Design of Existing Code
    
15. Coder to Developer: Tools and Strategies for Delivering Your Software
    
16. Perfect Software: And Other Illusions about Testing
    
17. Getting Real: The Smarter, Faster, Easier Way to Build a Successful Web Application
    
    

    Understanding Professional Software Environments
    

    
    

18. Agile Software Development: The Cooperative Game
    
19. Software Project Survival Guide
    
20. The Best Software Writing I: Selected and Introduced by Joel Spolsky
    
21. Debugging the Development Process: Practical Strategies for Staying Focused, Hitting Ship Dates, and Building Solid Teams
    
22. Rapid Development: Taming Wild Software Schedules
    
23. Peopleware: Productive Projects and Teams
    
    

    Mentality
    

    
    

24. Slack: Getting Past Burnout, Busywork, and the Myth of Total Efficiency
    
25. Against Method
    
26. The Passionate Programmer: Creating a Remarkable Career in Software Development
    
    

    History
    

    
    

27. The Mythical Man-Month: Essays on Software Engineering
    
28. Computing Calamities: Lessons Learned from Products, Projects, and Companies That Failed
    
29. The Deadline: A Novel About Project Management
    
    

    Mid Level Software Engineer Reading List
    

    
    

    Read This First
    

    
    

30. Personal Development for Smart People: The Conscious Pursuit of Personal Growth
    
    

    Fundementals
    

    
    

31. The Clean Coder: A Code of Conduct for Professional Programmers
    
32. Clean Code: A Handbook of Agile Software Craftsmanship
    
33. Solid Code
    
34. Code Craft: The Practice of Writing Excellent Code
    
35. Software Craftsmanship: The New Imperative
    
36. Writing Solid Code
    
    

    Software Design
    

    
    

37. Head First Design Patterns: A Brain-Friendly Guide
    
38. Design Patterns: Elements of Reusable Object-Oriented Software
    
39. Domain-Driven Design: Tackling Complexity in the Heart of Software
    
40. Domain-Driven Design Distilled
    
41. Design Patterns Explained: A New Perspective on Object-Oriented Design
    
42. Design Patterns in C# - Even though this is specific to C# the pattern can be used in any OO language.
    
43. Refactoring to Patterns
    
    

    Software Engineering Skill Sets
    

    
    

44. Building Microservices: Designing Fine-Grained Systems
    
45. Software Factories: Assembling Applications with Patterns, Models, Frameworks, and Tools
    
46. NoEstimates: How To Measure Project Progress Without Estimating
    
47. Object-Oriented Software Construction
    
48. The Art of Software Testing
    
49. Release It!: Design and Deploy Production-Ready Software
    
50. Working Effectively with Legacy Code
    
51. Test Driven Development: By Example
    
    

    Databases
    

    
    

52. Database System Concepts
    
53. Database Management Systems
    
54. Foundation for Object / Relational Databases: The Third Manifesto
    
55. Refactoring Databases: Evolutionary Database Design
    
56. Data Access Patterns: Database Interactions in Object-Oriented Applications
    
    

    User Experience
    

    
    

57. Don't Make Me Think: A Common Sense Approach to Web Usability
    
58. The Design of Everyday Things
    
59. Programming Collective Intelligence: Building Smart Web 2.0 Applications
    
60. User Interface Design for Programmers
    
61. GUI Bloopers 2.0: Common User Interface Design Don'ts and Dos
    
    

    Mentality
    

    
    

62. The Productive Programmer
    
63. Extreme Programming Explained: Embrace Change
    
64. Coders at Work: Reflections on the Craft of Programming
    
65. Facts and Fallacies of Software Engineering
    
    

    History
    

    
    

66. Dreaming in Code: Two Dozen Programmers, Three Years, 4,732 Bugs, and One Quest for Transcendent Software
    
67. New Turning Omnibus: 66 Excursions in Computer Science
    
68. Hacker's Delight
    
69. The Alchemist
    
70. Masterminds of Programming: Conversations with the Creators of Major Programming Languages
    
71. The Information: A History, A Theory, A Flood
    
    

    Specialist Skills
    

    
    In spite of the fact that many of these won't apply to your specific job I still recommend reading them for the insight, they'll give you into programming language and technology design.
    
    

72. Peter Norton's Assembly Language Book for the IBM PC
    
73. Expert C Programming: Deep C Secrets
    
74. Enough Rope to Shoot Yourself in the Foot: Rules for C and C++ Programming
    
75. The C++ Programming Language
    
76. Effective C++: 55 Specific Ways to Improve Your Programs and Designs
    
77. More Effective C++: 35 New Ways to Improve Your Programs and Designs
    
78. More Effective C#: 50 Specific Ways to Improve Your C#
    
79. CLR via C#
    
80. Mr. Bunny's Big Cup o' Java
    
81. Thinking in Java
    
82. JUnit in Action
    
83. Functional Programming in Scala
    
84. The Art of Prolog: Advanced Programming Techniques
    
85. The Craft of Prolog
    
86. Programming Perl: Unmatched Power for Text Processing and Scripting
    
87. Dive into Python 3
    
88. why's (poignant) guide to Ruby

The resource seems very extensive such that it should suffice you plenty to be a good software engineer. I hope you don't get exhausted from it. I understand that some people can "hack" the technical interview process by memorizing a plethora of computer science and software engineering knowledge, but I hope you pay great attention to the important theoretical topics.

If you want a list of books to read over the summer to build a strong computer science and software engineering foundation, then I recommend to read the following:

• Introduction to Algorithms, 3rd Edition: https://www.amazon.com/Introduction-Algorithms-3rd-MIT-Press/dp/0262033844. A lot of people do not like this classic book because it is very theoretical, very mathematical, and very abstract, but I think that is its greatest strength. I find a lot of algorithms books either focus too much about how to implement an algorithm in a certain language or it underplays the theoretical foundation of the algorithm such that their readers can only recite the algorithms to their interviewers. This book forced me to think algorithmically to be able to design my own algorithms from all the techniques and concepts learned to solve very diverse problems.
  
  
• Design Patterns: Elements of Reusable Object-Oriented Software, 1st Edition: https://www.amazon.com/Design-Patterns-Elements-Reusable-Object-Oriented/dp/0201633612/. This is the original book on object-oriented design patterns. There are other more accessible books to read for this topic, but this is a classic. I don't mind if you replace this book with another.
  
  
• Clean Code: A Handbook of Agile Software Craftsmanship, 1st Edition: https://www.amazon.com/Clean-Code-Handbook-Software-Craftsmanship/dp/0132350882. This book is the classic book that teaches software engineer how to write clean code. A lot of best practices in software engineering is derived from this book.
  
  
• Java Concurrency in Practice, 1st Edition: https://www.amazon.com/Java-Concurrency-Practice-Brian-Goetz/dp/0321349601. As a software engineer, you need to understand concurrent programming. These days there are various great concurrency abstractions, but I believe everyone should know how to use low-level threads and locks.
  
  
• The Architecture of Open Source Applications: http://aosabook.org/en/index.html. This website features 4 volumes of books available to purchase or to read online for free. It's content focuses on over 75 case studies of widely used open-source projects often written by the creators of said project about the design decisions and the like that went into creating their popular projects. It is inspired by this statement: "Architects look at thousands of buildings during their training, and study critiques of those buildings written by masters."
  
  
• Patterns of Enterprise Application Architecture, 1st Edition: https://www.amazon.com/Patterns-Enterprise-Application-Architecture-Martin/dp/0321127420/. This is a good read to start learning how to architect large applications.
  
  The general theme of this list of books is to teach a hierarchy of abstract solutions, techniques, patterns, heuristics, and advice which can be applied to all fields in software engineering to solve a wide variety of problems. I believe a great software engineer should never be blocked by the availability of tools. Tools come and go, so I hope software engineers have strong problem solving skills, trained in computer science theory, to be the person who can create the next big tools to solve their problems. Nonetheless, a software engineer should not reinvent the wheel by recreating solutions to well-solved problems, but I think a great software engineer can be the person to invent the wheel when problems are not well-solved by the industry.
  
  P.S. It's also a lot of fun being able to create the tools everyone uses; I had a lot of fun by implementing Promises and Futures for a programming language or writing my own implementation of Cassandra, a distributed database.

Yes! Also, quite honestly I don't know that many CS majors who took linear algebra at my school for whatever reason.

Where do you get started?

• If you're the type of person who likes an organized class to learn concepts, consider checking out coursera or other similar websites which offer free online learning courses! Check out their CS offerings and start from the intro.
  
  
• I must be known for spamming this SR with this, but check out CLRS, it pretty much contains most of the "CS math" you need to know for algorithms. As well as pretty much all you need to know about Algorithms and Data Structures for any basic job.
  
  
• REALLY make sure you understand your Algorithms and Data Structures, nearly every interview for a basic position centers around these topics. As well as some others, depending on the company: Bit manipulation, multi-threading, TCP/IP, etc.
  
  
• You want to learn some mainstream language as a lot of other people mentioned: C++, Java, C#, Python are a few that come to mind (though there are more like Ruby!). Side Note: Some people have differing opinions on whether C++ is good to learn as a first language. I don't know C# (but from its apparent similarity to Java) I would say C++ is probably the most difficult language to learn of the four I listed, but I feel that it also provides the most flexibility, because once you understand C++ it's easier to trainsition from C++ to Java, than say Java to C++ (similar for the other languages).
  
  
• Practice! Start working on some Project Euler problems, or other practice problems. Bonus: Someone in another thread mentioned that they made a blog post for each problem they solved and explained every one of their design decisions. This seemed like a bit over the top, but it really is a good practice for an interview and a job! You can even put a link to this on your resume to share.
  
  
• Find an Open Source to contribute to, come up with your own projects and post them on your github! This can show off your skills to a potential employer!
  
  Bonus for programming:
  
  
• When coding alone it's easy to get lost and start "hashing" together code. When you get to big projects, you'll find that this causes a lot of problems (and when working with other people it can cause even more). Some things to keep in mind when coding:
  
  
• Make sure your code is maintainable.
  
  
• Make sure your code is scalable.
  
  
• Test, test, test!
  
  Maintainable kinda means that your code is easy to test, easy to comprehend (by others) and easy to modify. Read up on different design patterns to learn more about this.
  
  Scalable is something you'll learn more about later, but basically it's kind of thinking about whether your code will be "good" enough to handle a lot of users (how fast is it how much memory will it take up)
  
  Testing is very important when coding. You want to try to write small pieces of code then test it (i.e.: make sure it works).
  
  All three of these things show up a lot in interviews, and if you can relate why you made your code the way you did to one of these three points (or something else) you should be pretty well off :D
  
  How do I land an interview?
  
  
• In your resume make sure to list any CS projects you want to mention, a link to your website (if you have one) or to other work. As well as Operating Systems you're familiar with (Linux is a big plus, but not absolutely necessary), IDE's you're familiar with (things like Eclipse, Visual Studios), and Languages you know. If you can, make sure to relate those three bullets to your project and work somehow to reiterate your experience with each language.
  
  
• A lot of recruiting is done on-campus, but there are other options, like applying online or even better...
  
  
• Network your way in. This gets your resume through the massive HR screen
  
  
• Edit, edit, edit (ask friends who are in the industry).
  
  How do I study for an Interview?
  
  Typcially, an interview will have you and the interviewer. The interviewer will first ask questions about you, what you're majoring in. And then maybe ask questions about your previous projects, and then he'll throw you a programming problem. Sometimes these can just be questions like "Which is faster: quicksort or mergsort?" or something like that, but other times they'll have you code something. If the interview is online, this will either mean you'll need to tell them the code you're writing or you'll code online on some collabarative envirionment (i.e.: you type the code online). If it's in-person they may have you write on a whiteboard. There are other formats of interviews as well, so make sure to research. Typically, for most larger companies, they won't care what language you code in (hopefully though it's mainstream!), but if you don't code in a language which they use, they may test you later for proficiency in one of their languages.
  
  
• As I mentioned before, Algorithms and Data Structures are usually go-to's for interviews, but other topics may come up so check out the req's for each job specifically.
  
  
• It may have been a while at this point since you studied your material, to brush up on interview questions, Cracking the Code Interview is a great book to brush up on your topics for an interview, it also has some resume advice, etc. if you choose to follow it.
  
  
• Be sure to practice talking out loud while you're coding, as this can help you during interviews. If you're stuck but your thought process is good an interviewer can help push you in the right direction.
  
  
• If you struggle with interviews, try having a friend who you know has experience and having him ask questions, better yet if you know a friend at the company, ask him to mock interview you.
  
  
• If you have time ALWAYS make sure you run test cases through your code mentally, and mention the test you're running and what it's supposed to catch (expected behavior) to your interviewer! If you have time and choose to ignore these, it can give the interviewer a wrong impression :\ (it also makes you look really good if you come up with all the boundary cases)
  
  Sorry, not sure if this helps or not!
  Good luck!

It depends on what you already know.

​

Do you have any prior programming experience? If not, start there. My no. 1 recommendation here would be Allen B. Downey's free Think Python book. Others might come along and recommend something like SICP, which is a good book, but perhaps a bit hard for an absolute beginner. Downey also has a version of his book that uses Java, so if you know for a fact that this is the language your introductory programming class will be using, then that could be a better option (Python is a simpler language, which makes it easier for you to focus on the actual concepts rather than the language itself, but if you know that you'll be using Java, you might as well kill two birds with one stone).

​

If you do have prior programming experience, you have all sorts of options:

• You could learn a functional language, like a Lisp (Clojure, Racket, Scheme, LFE, ...) or something in the (extended) ML family (Standard ML, OCaml, F#, Haskell, Elm, ...).
  
• Or, you could go the other way and learn something low-level, like C. You could even learn about C and Lisp at the same time by building your own.
  
• Or learn a logic programming language, like Prolog.
  
• Or, if you really want to understand object-oriented programming (and how languages like Java managed to stuff it up), you could learn Smalltalk.
  
• If you don't know what a unit test is or how to write one, you should learn.
  
• Learn about data structures and algorithms. As a CS student, you'll be learning about them at some stage anyway, so there's no harm in starting early. Some people might recommended CLRS for this, but for someone just starting out, I'd recommend something a bit friendlier, such as this series of videos from Princeton (presented by Robert Sedgewick, author of one of the most popular books on the subject). If you'd prefer a book, this free one from Allen B. Downey (who also wrote the introductory programming text I recommended earleir) looks quite good.
  
• Work your way through NAND2Tetris. It will take way longer than a month, but it will definitely set you apart from the rest of the class. Even if you don't do this now, you should definitely plan to do it at some point.
  
• Learn about databases. Again, you'll have to study them eventually, so why not start early? You could start by trying to build something that uses a database, like a simple todo utility.
  
  ​
  
  Regardless of whether or not you have programmed before, I would also recommend doing the following:
  
  
• Learn some basic Unix skills. It doesn't have to be too much – just enough to be able to sit down at the command line and have a vague idea of what you're doing is fine for now. You'll learn more as you use it more. That said, if you really want to dive in and learn how everything works, then something like How Linux Works could be a good read.
  
• Learn some discrete mathematics. As a CS student, you'll be required to learn it at some stage – it's the mathematical backbone of CS, much like calculus is to physics – so you might as well start early. This free, book-length set of notes from MIT is very well-regarded (but don't expect to get through it all in a month!). There is also a set of video lectures if you prefer. If you're keen on learning functional programming, another option could be to integrate that with your discrete maths studies by reading Thomas VanDrunen's Discrete Mathematics and Functional Programming (if the physical book is a bit expensive for you, there's also a cheaper ebook version available).
  
• For bonus points: learn to use either Vim or Emacs. There probably isn't a massive practical advantage to using these this early in your career (although they could certainly come in handy later), but if other students see you writing code in one of them, you'll look like an absolute badass. Your teachers will probably be quietly impressed, too.
  
  ​
  
  if you have any questions about my above suggestions, let me know, and I'll see if I can point you in the right direction.
  
  ​
  
  Good luck!

Your mileage with certifications may vary depending on your geographical area and type of IT work you want to get into. No idea about Phoenix specifically.

For programming work, generally certifications aren't looked at highly, and so you should think about how much actual programming you want to do vs. something else, before investing in training that employers may not give a shit about at all.

The more your goals align with programming, the more you'll want to acquire practical skills and be able to demonstrate them.

I'd suggest reading the FAQ first, and then doing some digging to figure out what's out there that interests you. Then, consider trying to get in touch with professionals in the specific domain you're interested in, and/or ask more specific questions on here or elsewhere that pertain to what you're interested in. Then figure out a plan of attack and get to it.

A lot of programming work boils down to:

• Using appropriate data structures, and algorithms (often hidden behind standard libraries/frameworks as black boxes), that help you solve whatever problems you run into, or tasks you need to complete. Knowing when to use a Map vs. a List/Array, for example, is fundamental.
  
• Integrating 3rd party APIs. (e.g. a company might Stripe APIs for abstracting away payment processing... or Salesforce for interacting with business CRM... countless 3rd party APIs out there).
  
• Working with some development framework. (e.g. a web app might use React for an easier time producing rich HTML/JS-driven sites... or a cross-platform mobile app developer might use React-Native, or Xamarin to leverage C# skills, etc.).
  
• Working with some sort of platform SDKs/APIs. (e.g. native iOS apps must use 1st party frameworks like UIKit, and Foundation, etc.)
  
• Turning high-level descriptions of business goals ("requirements") into code. Basic logic, as well as systems design and OOD (and a sprinkle of FP for perspective on how to write code with reliable data flows and cohesion), is essential.
  
• Testing and debugging. It's a good idea to write code with testing in mind, even if you don't go whole hog on something like TDD - the idea being that you want it to be easy to ask your code questions in a nimble, precise way. Professional devs often set up test suites that examine inputs and expected outputs for particular pieces of code. As you gain confidence learning a language, take a look at simple assertion statements, and eventually try dabbling with a tdd/bdd testing library (e.g. Jest for JS, or JUnit for Java, ...). With debugging, you want to know how to do it, but you also want to minimize having to do it whenever possible. As you get further into projects and get into situations where you have acquired "technical debt" and have had to sacrifice clarity and simplicity for complexity and possibly bugs, then debugging skills can be useful.
  
  As a basic primer, you might want to look at Code for a big picture view of what's going with computers.
  
  For basic logic skills, the first two chapters of How to Prove It are great. Being able to think about conditional expressions symbolically (and not get confused by your own code) is a useful skill. Sometimes business requirements change and require you to modify conditional statements. With an understanding of Boolean Algebra, you will make fewer mistakes and get past this common hurdle sooner. Lots of beginners struggle with logic early on while also learning a language, framework, and whatever else. Luckily, Boolean Algebra is a tiny topic. Those first two chapters pretty much cover the core concepts of logic that I saw over and over again in various courses in college (programming courses, algorithms, digital circuits, etc.)
  
  Once you figure out a domain/industry you're interested in, I highly recommend focusing on one general purpose programming language that is popular in that domain. Learn about data structures and learn how to use the language to solve problems using data structures. Try not to spread yourself too thin with learning languages. It's more important to focus on learning how to get the computer to do your bidding via one set of tools - later on, once you have that context, you can experiment with other things. It's not a bad idea to learn multiple languages, since in some cases they push drastically different philosophies and practices, but give it time and stay focused early on.
  
  As you gain confidence there, identify a simple project you can take on that uses that general purpose language, and perhaps a development framework that is popular in your target industry. Read up on best practices, and stick to a small set of features that helps you complete your mini project.
  
  When learning, try to avoid haplessly jumping from tutorial to tutorial if it means that it's an opportunity to better understand something you really should understand from the ground up. Don't try to understand everything under the sun from the ground up, but don't shy away from 1st party sources of information when you need them. E.g. for iOS development, Apple has a lot of development guides that aren't too terrible. Sometimes these guides will clue you into patterns, best practices, pitfalls.
  
  Imperfect solutions are fine while learning via small projects. Focus on completing tiny projects that are just barely outside your skill level. It can be hard to gauge this yourself, but if you ever went to college then you probably have an idea of what this means.
  
  The feedback cycle in software development is long, so you want to be unafraid to make mistakes, and prioritize finishing stuff so that you can reflect on what to improve.

Good on you for looking to grow yourself as a professional! The best folks I've worked with are still working on professional development, even 10-20 years in to their profession.

Programming languages can be thought of as tools. Python, say, is a screwdriver. You can learn everything there is about screwdrivers, but this only gets you so far.

To build something you need a good blueprint. For this you can study objected oriented design (OOD) and programming (OOP). Once you have the basics, take a look at design patterns like the Gang of Four. This book is a good resource to learn about much of the above

What parts do you specify for your blueprint? How do they go together? Study up on abstract data types (ADTs) and algorithms that manipulate those data types. This is the definitive book on algorithms, it does take some work to get through it, but it is worth the work. (Side note, this is the book Google expects you to master before interviewing)

How do you run your code? You may want to study general operating system concepts if you want to know how your code interacts with the system on which it is running. Want to go even deeper with code performance? Take a look at computer architecture Another topic that should be covered is computer networking, as many applications these days don't work without a network.

What are some good practices to follow while writing your code? Two books that are widely recommended are Code Complete and Pragmatic Programmer. Though they cover a very wide range (everything from organizational hacks to unit testing to user design) of topics, it wouldn't hurt to check out Code Complete at the least, as it gives great tips on organizing functions and classes, modules and programs.

All these techniques and technologies are just bits and pieces you put together with your programming language. You'll likely need to learn about other tools, other languages, debuggers and linters and optimizers, the list is endless. What helps light the path ahead is finding a mentor, someone that is well steeped in the craft, and is willing to show you how they work. This is best done in person, watching someone design and code. Also spend some time reading the code of others (GitHub is a great place for this) and interacting with them on public mailing lists and IRC channels. I hang out on Hacker News to hear about the latest tools and technologies (many posts to /r/programming come from Hacker News). See if there are any local programming clubs or talks that you can join, it'd be a great forum to find yourself a mentor.

Lots of stuff here, happy to answer questions, but hope it's enough to get you started. Oh, yeah, the books, they're expensive but hopefully you can get your boss to buy them for you. It's in his/her best interest, as well as yours!

I'm a consultant with an IT software company, and with the current client I'm working with, I spent my first 3 weeks doing nothing but research and interviews and gathering information. Since you're starting as essentially a junior PM, just ask the senior people or your line manager how long they expect you to research and come to understand the project before needing to deliver anything. Hopefully, if all goes well, it'll be an organic process and will sort itself out in time. Be patient and just take lots and lots of notes.

Since you're in the position of having senior PMs, there's a good chance you won't need to establish objectives, at least right off the bat. You may be doing calculations, maintaining schedules, facilitating communications, etc. I say play that one by ear. Since you're new to the process, I recommend reading The Mythical Man Month and taking it to heart. Be wary of underestimating, and do your best to take reality into account as well as ever-shifting demands.

As to what a PM generally spends their time on, it totally depends on the organization and the project. I'm not a dedicated PM, and my background is actually in IT management. That said, at my last job, I did some PM, and I'm currently getting my master's in project management and will follow that up with a PMP. As a consultant, I'm working with the PMO, among other groups, and I spend a lot of my time in meetings and communicating, both to gather requirements from stakeholders and translate those into stories, and to make sure all stakeholders are on the same page. I spend a lot of time making sure that people have proper visibility into the project, which means good reporting and keeping a lot of notes close at hand. Developing a good system for maintaining your notes is essential if you don't already have one. I rely heavily on Evernote, but I've got a methodology for Outlook, and for my file system (be it in Google Drive or Dropbox or elsewhere), and for Skype.

Making educated decisions is our job. There's a science to PM, but at the end of the day, we're humans dealing with humans. We make the call to the best of our abilities, and take responsibility to fix it if we're wrong.

Regarding passing up the opportunity, I say absolutely not. You'll learn a lot more in this position than at a lower level PC job. Approach it ready to fail and pick yourself back up, and fail fast, and you'll grow quickly. Maintain your confidence as best you can, keep finding more books and resources to read/watch/listen to, and do your best.

Another good resource I'd recommend is the Project Management for the Masses G+ community and podcast. There are a number of different PM podcasts out there that are quite good (I also recommend the People and Projects Podcast), and quite a few good books.

As you get further into it, you'll discover that PM is actually a relatively new field, really just a few decades old. There's a lot to learn, but don't get too stressed about it. Take that energy and go learn more instead :-)

Oh god where to begin?

***

Well I Like to think there are level of programming understanding that are relatively tiered.

Tier 1 - How to Code

***
This one is tough as there is no real definitive best answer. My personal primer of choice is

• Sams Learn Java in 24 hours.
  
  > Fyi - , that is not "in one day" that is , in 24, 1 hour sessions equating to a hypothetical 4 college lectures a week lasting a month and a half of intensive training. A huge amount of homework is required to accompany that primer.
  
  so now you can write an app, what next? well. to finish the thought:
  
  
  

  Tier 2 - How to Code...
  

  so other programmers don't want to hit you over the head for each line in your longest function screaming CYCLOMATIC COMPLEXITYYYY
  
  **
  
  Here we talk about how to program properly* You want to be looking up Uncle Bob . Head over to
  
  

• www.cleancoders.com
  
  and check out his video form of his famous book:
  
  
• Clean Code....then buy that book.
  
  Now you should be writing code that doesn't make other programmers eyes bleed.
  
  

  Tier 3 - How to Code..To Solve Problems
  

  ***
  Here we talk about design patterns. Now, you will bump into a lot of debate over their value but...that is stupid. that is like some people saying all carpentry should be done with a saw and another group saying carpenters should never use a saw. Design patterns are names for recognised ways to solve problems you will hit every day in your programming. They may not always work in your case but at worst they will have you thinking around a problem better.
  
  For a primer, check out:
  
  

• Head First: Design Patterns
  
  In fact the entire head first series is great, It is like the For dummies series for programming principles. Great for morons like myself.
  
  With that read, get the real design pattern book:
  
  
• Elements of Reusable...
  
  Don't expect to actual understand almost any of this. I read that book cover to cover and it didn't actual click for me till it slapped me in the face when i was in the real world developing business tier applications. Although having read it so many times meant I new which pages to flip to when I was ready.
  
  

  Tier 4 - How to Code... For Users
  

  ***
  
  This is a whole different kettle of fish. Now you may have written the perfect app to do X with only two buttons, you will find quickly that users are adept at licking the buttons in just the correct order to cause your application to explode. You need to program applications so the cast of jersey shore can use it.
  
  I am a fan of the blog:
  
  

• Joel on Software.
  
  Joel (Co-founder of Trello) covers a lot regarding front facing applications and UX that is required reading...even if he a bit cavalier on his approach to testing.
  
  This is the next part. Testing. You are going to want to Learn about Defensive Programming andTesting. There is a wealth of tutorials over on pluralsight for these.
  
  

  Tier 5 - When NOT to Code
  

  
  **
  
  This is a hard step to get to. Realising that copy and pasting code is GREAT!..but for the right reasons. Once you jump over the initial Copy+paste = the greatest thing in the world barrier , most developers grow a level of defiance that borders on the absurd. Preferring to rewrite the wheel instead of using ...the wheel. When you can honestly say you could* program it from scratch, it is perfectly okay to use libraries and apis.
  
  This is where I go to:
  
  

• www.codeproject.com
  
  and hit up Sacha and others. They show you fairly feature complete and interesting implementations of problems, not just the one or two lines you get from Stack Overflow. Granted this is miles more complicated but it shows not only how to do it, but how to do it right and WHY to do it right. and github of course.
  
  

  Tier 6 - Learning From Mistakes
  

  ***
  
  Now that you have climbed code mountain and are absorbing the combined knowledge of all the internet geniuses, it is time to see where you went wrong.
  
  Head over to
  
  

• http://codereview.stackexchange.com/
  
  and post you functional applications. There a number of people will politely tell you not...how but how to do it better, general improvements in design, logic and reusability. take you through the solid principles and much more. Also..say hello to me if you like :P.
  
  You don't even have to learn exclusively from your own mistakes.
  
  check out:
  
  
• www.thedailywtf.com
  
  and cringe at some examples of real software....and if you don't understand why you should be cringing..learn.
  
  ***
  
  

  Tier 7 - How to think like a programmer
  

  
  Now things get a little bit meta. The best way to become a great programmer? don't JUST read programming. Read books like:
  
  

• Zen and the Art of Motorcycle Maintenance
  
  
• Don't Make Me Think
  
  Read anything and everything, exercise your mind. books on architecture, books on carpentry. any kind of design and problem solving with stretch your understanding of how to climb those brick walls you will hit.
  
  Read some of the more general programming blogs, like:
  
  
• http://blog.codinghorror.com/
  
  Read anything and everything.
  
  

  Final Thoughts
  

  ***
  
  Have fun.
  
  Check out:
  
  

• www.commitstrip.com
  
• www.xkcd.com
  
  and..well..here.
  
  I would also say as a personal suggestion, although i left it out of the mandatories up above as it is a bit controversial, I suggest going TDD. Test driven development. It is not for everyone, a hard ethos to get into but in the real world, in business applicable coding...a life saver. Uncle bob is the man for that again.
  
  Finally I am a fan of Rubber Ducking. Great way to work though problems.
  
  If you want some final reading, I left them out because everyone and their brother has these (and most of the above) in their top 50 programming book lists so it is a mite redundant:
  
  
• Code Complete
  
• The Mythical Man Month
  
• The Pragmatic Programmer
  
• Refactoring: Improving the Design of Existing Code
  
  ***
  Enjoy.
  
  
  
  

My Story

Hey pal, I was in a similar boat about 8 months ago. It was my senior year as an Economics major, and after taking a programming class, I instantly fell in love with it. I crammed a few more programming classes in before graduating, but in the end, I sure as hell wasn't employable as a software engineer.

​

I had a choice: become a data analyst (the path I was currently on) or follow the software engineering dream. I chose the latter.

​

I decided to go to a (remote) coding bootcamp after college. The program was 6 months. It taught web development (Node, React) and some very basic CS fundamentals. I spent my free time outside the bootcamp inhaling all the computer science and industry information I could. I did this because I wanted to be a competent programmer. I found it fun.

​

This week I had my second onsite. I expect to receive a full-time software engineer offer (my second offer so far) later today, and I have 4 other onsites in the near future (a big 4 + a few startups). It has been a heck of a lot of work to get here, but if you want it badly enough, it's possible.

​

My Tips

• Try not to be intimidated by these tips. Software engineering is something that you take little bites out of. You cannot become an employable developer in one bite, and sometimes the field can be intimidating.
  
• Your options right now are self-teaching, a coding bootcamp, or a CS master's degree (might be hard to get into a good program without a bit more relevant experience, tbh.).
  
• It's going to be pretty difficult to break into anything other than web development for your first programming job without a CS degree. Titles like Front-end Engineer, Full Stack Engineer, Backend Engineer, and Software Engineer (at a web company) are within reach. More specialized titles probably aren't very realistic.
  
• Basic toy projects (i.e., simple HTML/CSS or similar) probably aren't enough to get significant attention. You need things more complex, like full-stack applications built from scratch. This means a working backend, a working database, a modern front-end (using a framework like React, etc.). Here's my portfolio if you're curious about the type of apps I mean.
  
• Other types of programming applications outside of web dev are also fine, as long as they are sufficiently complex and interesting.
  
• Put your projects on your GitHub no matter what. Learning how to commit code to GitHub is an important industry practice. Having a green GitHub history makes you look better.
  
• Try and build a portfolio once you get better at coding. Don't kill yourself making it look amazing, but do try and make it look good. Not everyone will care about your portfolio, but some people will. I got an interview just based on having a nice portfolio.
  
• Your university course sounds like a great primer, but you need to go deeper to be competent enough to pass interviews. I took similar courses at my university, but what really helped me was going through a few textbooks (1, 2, 3 -- some suggestions) and watching MIT 6.006 lectures. You will still have gaps in things like web security, scaling systems, networks, and operating systems, but I wouldn't spend a ton of time learning those topics as a new grad. Knowing the basics can be helpful though, because these things do definitely come up in interviews.
  
  ​
  
  Happy to answer any other questions you may have. I'm not an expert or an experienced software engineer yet, but I've walked the path you're considering, so hopefully my tips are helpful.

What kind of jobs are you applying for? Low-level stuff is typically applicable for things like engine work, graphics, optimization, networking and audio. Okay, that covers a lot of the game development process, but there are certainly jobs that aren't deep into that, like peripheral tooling (making tools for developers to use) or working on stuff like the webservices that powers the online community.

However, if your goal really is core game development, then you need to be a lot more targeted in how you learn. I have interviewed for and was hired by a game company that worked in C++, and have also worked in distributed, networked military simulations (think of it like boring, more realistic Starcraft), so here is how I gained the various knowledge I had in getting through those types of interviews (including a 90-minute written test for the game company where I had to debug C++ code on paper, answer various gotchas, etc.).

I don't know how far you have covered, but this is how I would approach the learning now, were I to start over again.

• Become really good at C++ - During my first job, I mostly used Java with Python/C++/Perl/TCL on the side. I learned a lot of C++ in short order to prepare for interviews and move jobs (to simulation).
  
  
• Read Accelerated C++ and/or C++ Primer. These are probably the best books for getting introduced to C++ and starting off in a good place (as in, not learning C++ in the form of C), getting familiar with using the OO system of C++ and using the standard library. Also remember to do the exercises to really reinforce the concepts.
  
  
• Read Effective C++ SUPER COLLECTION - In honesty, you can make do with just Effective C++, Volume 1, but these cover good practices for using C++.
  
  
• Read the C++ FAQ - lots of gotchas there and corner cases of C++.
  
  
• If you want to go beyond those books and resources, there are Herb Sutter's Exceptional C++ books.
  
  
• Understand the machine - this covers the low level component. Helping you to understand the machine itself, how your code runs, how it's executed.
  
• Read Randall Hyde's Write Great Code - This is one of my favorite technical books, and is language agnostic.
  
  It covers low-level concepts like CPU pipelining, memory, and how code interacts with the machine. I read this years after I started my job building simulations, and it reinforced a lot of what I learned previously and in college. I also recommended this book to a friend of mine who credits it with giving him an edge over his fellow college grads (he's years younger than I am) in low-level knowledge. If you don't know concepts like cache locality, cache lines and how memory is allocated, this book will cover that and more.
  
  
• Read Randall Hyde's Art of Assembly Language - I have only briefly touched upon this book, but it takes a unique approach to introducing you to x86 ASM (by using a higher-level form of ASM).
  
  
  
• Understand the algorithms and data structures - I took multiple classes in this in college, as well as periodically read CLRS to refresh my knowledge. But CLRS is too mathematically rigorous and theoretical here if you just want to get familiar with algorithms.
  
  
• Skeina's Algorithm Design Manual is a more practical approach to refreshing yourself on algorithms and also learning complexity theory.
  
  
• Skeina's Data Structures Lectures are helpful for data structures. In general, though, know these (I include whatever C++ has as well):
  
  • Dynamic array - std::vector<T> in C++.
    
  • Associative structures - std::map and std::unordered_map
    
  • Sets - std::set and std::unordered_set
    
  • Linked List - std::list<T> and std::forward_list<T>
    
  • Stacks and Queues - std::stack and std::queue
    
  • std::deque - The C++ implementation of a double-ended queue.
    
  • Trees - binary trees, red-black, heaps, tries (no standard C++ implementations of these, though stuff like std::set is typically implemented with a red-black tree behind the scenes)
    
  • Graphs
    
    
  • Understand the complexities of actions on each data structure (insertion, deletion, modification, searching, etc.)
    
    
• Read the wiki on Pathfinding, because this class of algorithms is very important in game development, as well as network communication.
  
  -----
  
  The above covers the 'core' stuff you'd have to learn. If you wanted to get into stuff like network programming or graphics programming rather than just core gameplay development, I can expound further.
  

Something like Code: The Hidden Language of Computer Hardware and Software may be up your alley.

So may be From NAND 2 Tetris, a course where you build a computer (hardware architecture, assembler, OS, C-like compiler, and programs to run on the OS / written in the compiler) starting with just NAND.

At the end of the day though, the way things work is like this: Protocols and specifications.

Everything follows the same published IPO (input, processing, output) standards. Stuff is connected to and registers expected values on expected peripherals. The CPU, motherboard, graphics card, wireless modem, etc. all connect in the right, mostly pre-ordained places on the hardware.

In this vein, there's firmware level APIs for then communicating with all of these at the BIOS level. Although as far as I'm aware, "actual" "BIOS" is no longer used. UEFI is instead: https://en.wikipedia.org/wiki/Unified_Extensible_Firmware_Interface

This is what Firmware is / is built on-top of. Operating systems build on top of these. System calls. Operating systems communicate under the hood and expose some number of system calls that perform low-level actions like talking to devices to perform things like file access or network I/O. A lot of this stuff is asynchronous / non-blocking, so the OS or system will then have to respond to an interrupt or continuously check a registry or some other means of getting a response from the device to see if an operation completed and what its result was.

Loading the OS is one thing the BIOS is responsible for. This is through the bootstrapping process. The OSs are located at very specific locations on the partitions. In the past, the only command you had enough room for within BIOS / pre-operating system execution was to load your OS, and then the OS's startup scripts had to do everything else from there.

Once you have an operating system, you can ask the OS to make system calls and invoke low-level API requests to get information about your computer and computer system, such as the file system, networks, connected drives and partitions, etc. These calls are usually exposed via OS-specific APIs (think the win32 API) as well as through a command-line interface the OS provides.

New devices and I/O from/to those devices communicate through firmware, and interrupts, and low-level system calls that are able to communicate with these firmware APIs and respond to them.

Just about anything you can think of - graphics, audio, networking, file systems, other i/o - have published standards and specifications. Some are OS-specific (X windowing system for Linux, DirectX win32 API or GDI on Windows, Quartz on Mac, etc.). Others are vendor-specific but don't seem to be going anywhere (OpenGL, then nVidia vs AMD driver support which varies across operating systems, etc.).

The biggest hardware vendors and specification stakeholders will work with the biggest operating system vendors on their APIs and specifications. It's usually up to device manufacturers to provide OS-compatible drivers along with their devices.

Drivers are again just another specification. Linux has one driver specification. Windows has another. Drivers are a way that the OS allows devices and users to communicate, with the OS as a middle-manager of sorts. Drivers are also often proprietary, allowing device manufacturers to protect their intellectual property while providing free access to use their devices on the OS of your choice.

I'm not an expert in how it all works under the hood, but I found comfort in knowing it's all the same IPO and protocol specifications as the rest of computing. No real hidden surprises, although a lot of deep knowledge and learning sometimes required.

When we get to actually executing programs, the OS doesn't have too much to work with, just the hardware... So the responsibility of slicing up program execution into processes and threads is up to the OS. How that's done depends on the OS, but pretty much every OS supports the concept in some sense.

As far as how programs are multi-tasked, both operating systems and CPUs are pretty smart. Instructions get sent to the chips, batched and divided by them and the computational results placed into to registries and RAM. Again, something I'm not a huge expert in, and it honestly surprised me to find out that the OS is responsible for threading etc. I for some reason always thought this was at the chip level.

When you include libraries (especially system / OS / driver libraries) in your code, you're including copies of or references to OS native functions and definitions to help you reference these underlying OS or system calls to do all the cool things you want to do, like display graphics on the screen, or play audio. This is all possible because of the relationship between OS's and device manufacturers and the common standards between them, as well as the known and standard architectures of programs designed for OS's and programs themselves.

Inter-program compatibility is where many things start to become high level, such as serialization standards like JSON or XML, but not always. There are some low-level things to care about for some programs, such as big- vs little-endian. Or the structure of ASM-level function calls.

And then you have things like bitcode that programs like Java or JavaScript will compile to, which are a system-independent representation of code that most often uses a simple heap or stack to describe things that might instead be registry access or a low-level heap or stack if it had been written in ASM. Again, just more standards, and programs are written according to specifications and know how to interface with these.

The modularity of programming thanks to this IPO model and the fact that everything follows some standards / protocols was a real eye opener for me and made me feel like I understood a lot more about systems. What also helped was not only learning how to follow instructions when setting up things on my computer or in my programs, but learning how to verify that those instructions worked. This included a lot of 'ls' on the command-line and inspecting things in my debugger to ensure my program executed how I expected. These days, some might suggest instead using unit tests or integration tests to do the same.

Welcome! You are showing great initiative in learning C++ and asking for feedback says that you are very serious about it!

A few words on your repository.

1. Don't include binary files in git. Git is rather bad at versioning binary files and they just bloat your repository.
   
2. Including a file structure without VS solution stuff and adding a Makefile for those of us who don't use Windows is always appreciated. :)
   
   A few items on the code.
   
   It doesn't compile out-of-the-box with gcc. I understand that this is just a practice project that you probably won't be officially distributing and supporting, but it never hurts to get in the mindset of cross-platform development early. For non-Windows environments, gcc is pretty much the de facto target compiler (others include clang, icc, and open64). Hence, it is well worth the effort to ensure you compile (preferably warning free!) under gcc. The errors were
   
   
3. In vec3d.h and quaternion.h, you need to #include <cmath> to use std::sqrt, std::cos, and std::sin. You might need a preprocessor guard around the include since VC didn't have a problem with it. Additionally, <cmath> gives you M_PI so you don't have to #define your own.
   
4. no match for ‘operator’ (operand types are ‘vec3’ and ‘quaternion’)
   
   I have no idea how this compiled in VC
   
   vec3 getForwardVector()
   {
   return vec3(0, 0, 1) this;
   }
   
   inline vec3 operator(vec3 &v, quaternion &q)
   {
   quaternion result = quaternion();
   result = q v q.conjugate();
   return vec3(result.x, result.y, result.z);
   }
   
   When you say vec3(0, 0, 1), you are generating what is known as an r-value (its name comes from the fact that it is usually something that is on the right of an assignment statement). You are passing this r-value into a function that expects an l-value (a thing on the left of an assignment statement). In general, this is not allowed (and for good reason!). What would happen in the following:
   
   void foo(int &i) {
   i = 2;
   }
   foo(3);
   
   The value 3 is a perfectly good r-value, but what happens when I execute i = 2 in foo? Badness, that's what. How can I possibly change 3 to 2? I would break the universe. :p So it's just not allowed.
   
   However, there are two ways that you can pass an r-value to an l-value parameter. The first is through a const l-value.
   
   void foo(const int &i) {
   // I can't change i because it's const!
   std::cout << "i = " << i << std::endl;
   }
   foo(3);
   
   The second is through what Scott Meyers calls "universal references." I need a slightly more complicated example to demonstrate this.
   
   struct foo {
   int x, y, z;
   foo(int _x, int _y, int _z) : x{_x}, y{_y}, z{_z} {}
   };
   
   foo bar(foo &lhs, foo &&rhs) {
   return foo(lhs.x+rhs.x,lhs.y,lhs.zrhs.z);
   }
   
   foo f{1,2,3};
   auto x = bar(f, foo(4,5,6));
   std::cout << "x.x = " << x.x << std::endl;
   
   What does this print? 5 You can use either of these forms to fix your `inline vec3 operatorfunction. Notice that I didn't putconston the first parameter. This was purely to demonstrate thatfis an l-value and doesn't require being calledconstin the parameter list. However, it is good form to addconstto any l-value parameter that you are not intending to change. I *strongly* recommend a read through Scott's excellent book [Effective Modern C++](http://www.amazon.com/Effective-Modern-Specific-Ways-Improve/dp/1491903996/ref=sr_1_1?s=books&amp;amp;ie=UTF8&amp;amp;qid=1425771559&amp;amp;sr=1-1&amp;amp;keywords=scott+meyers). It is just chock full of great nuggets of wisdom like these.<br /> <br /> Wow. Another complete mystery as to why this compiles in VC (given what I just discussed, can you decipher the compiler error?)<br /> <br /> quaternion &amp;amp;q = m_camera-&amp;gt;getTransform().getRotation();<br /> <br /> &amp;gt; invalid initialization of non-const reference of type ‘quaternion&amp;amp;’ from an rvalue of type ‘quaternion’<br /> <br /> Does Visual Studio Express allow you to upgrade VC++ separately from VS iteself? If so, you need an upgraded compiler because this one stinks. Once you have mastered the art of l-value vs. r-value, you have lots of code to update as there are many errors surrounding this concept in your current code.<br /> <br /> While technically not an error, it is generally inefficient to pass primitive types by reference when you aren't going to be modifying them (the debate about using non-const references as in-out parameters rages to this day!). For example,<br /> <br /> static vec3 refract(vec3 &amp;amp;I, vec3 &amp;amp;N, float &amp;amp;NdotI, float &amp;amp;eta, float &amp;amp;cos_t)<br /> <br /> should really just be<br /> <br /> static vec3 refract(vec3 &amp;amp;I, vec3 &amp;amp;N, float NdotI, float eta, float cos_t)<br /> <br /> Ok. Errors out of the way. How can you make your code more C++-y? I promise I don't intend to sound pithy, but the Java is strong with you. :p Let's take that previous example.<br /> <br /> struct vec3 {<br /> /* lots of stuff! */<br /> <br /> static vec3 refract(vec3 &amp;amp;I, vec3 &amp;amp;N, float NdotI, float eta, float cos_t)<br /> }<br /> <br /> In Java, this makes sense since you aren't allowed to have free functions. But this is C++ and we do have them and folks are going to anticipate you have them rather than class-static methods.<br /> <br /> struct vec3 {<br /> /* lots of stuff! */<br /> }<br /> <br /> vec3 refract(const vec3 &amp;amp;I, const vec3 &amp;amp;N, float NdotI, float eta, float cos_t)<br /> <br /> Much better! :D (NB: notice that I addedconstto the input parameters? This is good form, too.)<br /> <br /> Alright. I think I have badgered you enough. Definitely keep us apprised of how the project evolves and don't be afraid to ask lots of questions!<br /> <br /> **EDIT**: fixed typos and added clarifications.<br /> <br /> **EDIT2**: Gavestruct foo` a non-default constructor so it will compile.
   
   EDIT3: Gold! Thank you, kind stranger.

I have some advice for you. I'm speaking more from the position of someone who didn't do a lot of these things and regrets it than someone who can say for sure what you need to do, but I still think I have some helpful advice:

First and foremost, take a little time to enjoy your last summer before going off to university. I'm not saying you shouldn't also learn some CS, but honestly if you're the type of person who knows how to study and is willing to go to class and put in the work you already have a "head-start" on a good percentage of your classmates. And frankly, life gets a lot more stressful after high school. Enjoy yourself. You're right that AP courses aren't representative of the college experience, but your first year's coursework isn't going to be too scary. If you can handle AP, you can handle your freshman level coursework. Go to class, take good notes, and be an active participant in your courses, and then study afterwards. That's 90% of college success in the classroom. Doing well in the classroom isn't the only thing you need to worry about though (more below).

If you'd like a little summer reading, I personally found this book really enjoyable. Picked it up during my freshman year IIRC: https://www.amazon.com/Code-Language-Computer-Hardware-Software/dp/0735611319/ref=sr_1_1?ie=UTF8&qid=1541924346&sr=8-1&keywords=code

It is both very informative and a fun read.

If you've taken AP Comp. Sci. then I'm assuming you can code a bit. If you want to do some programming I'd recommend sticking to what you know and deepening your understanding of it or trying out the language that your university starts you off with. They might even be the same language. Don't worry about learning multiple languages yet. You will likely be introduced to several languages in undergrad. Focus on the fundamentals.

Get connected at your university. Universities have a lot of resources for people interested in research. For example, my university had an undergraduate research program. They also had a student success center with people equipped to help you develop a plan (which is what you're trying to do now) to get to where you want to be, including graduate school and beyond. Be an active participant in your CS classes. You're going to have some shitty professors but you'll likely meet some really cool people too, who are passionate about what they do and who have the connections to help you if you show some initiative. If it's a larger school there will also be plenty of student organizations for you to check out, both explicitly CS-related and basically anything you can imagine. Don't be afraid to check out non-CS stuff. See what your university has to offer. If you don't know where to start, check out the website and once you get on campus seek out the equivalent of what I called the student success center. They will be familiar with all of the programs and services that your university offers at a broad level. Should be pretty similarly named. Also, ask your professors! At my university student organizations had faculty advisors and even if your professor isn't that person they will probably know who is.

Final note: while you should be active, have a plan, and get involved, don't try to do too much at once. You will burn out. You need to be honest about your limits. It's healthy to push yourself, but only if you are mindful of what you can handle. And if you find yourself struggling, do not be afraid to seek out academic coaching. If you have trouble adjusting to the university experience (very common and nothing to be ashamed of) your university might also offer access to therapists. Finally, if you have a diagnosed disability, make sure to register with disability services to receive accommodations!

I'm not sure what your background is, but if you haven't had any formal programming education, I believe we learned out of a book like this: https://www.amazon.com/dp/0201633612/?tag=stackoverfl08-20

One of the keys to good software is good design. Making a plan of action before you even start coding cuts back on the 'quick fix' solutions that make your code harder to work with later.

I don't think this is C# specific, but design is really something that is abstract from language specifics. If you're looking for something specific to the environment you're working in, I think material on best practice for the game engine you're using would be better. I have done application development with C# and C# scripts in Unity, and there are definitely differences in how I am able to make things interact, which impacts how I design my code.

I have two recommendations if you're wanting to expand your abilities in design:

1. UML Diagrams: You can model out all of the pieces, with their members, functions and interactions with each other. Doing this can help in prototyping a system, you can see the interactions and logically create classes and scripts around the model instead of bloating things as you run into problems along the way.
   
   
2. Documentation: This is key to the longevity of a project and saving time in bugfixes and expanding on software later. When you finish any snippet, leave comments explaining what you're doing. Use good variable names. I do consultant work on legacy code and it's amazing how people can write an entire application without comments, in one large Main file and with variable names that mean nothing. I was terrible about naming things 'temp' and what not when I first started out, and if you ever work with anyone else leave a project to sit for a few months to a few years, you and your colleagues will greatly appreciate documentation.
   
   As far as the book goes, I can't condone it, but there's probably PDFs out there. Sometimes it helps motivate to actually read through it if you've invested some money into it, though. I would recommend finding an old/used copy. An old version of the book should work just as well as an 'updated' version.
   
   You may also find it useful to look into Agile/Scrum. It's all about documenting your development, and helps to organize what's been done and what needs to be done, as well as give you an idea of how long things take, which helps later with estimations. All these things are skills that will come in handy later, if you decide to pursue software as a career. Plus, it's all good habits that help facilitate good, clean code.

While being a self taught sys admin is great, learning the internals of how things work can really extend your knowledge beyond what you may have considered possible. This starts to get more into the CS portion of things, but who cares. It's still great stuff to know, and if you know this you will really be set apart. Im not sure if it will help you directly as a sys admin, but may quench your thirst. Im both a programmer and unix admin, so I tend to like both. I own or have owned most of these and enjoy them greatly. You may also consider renting them or just downloading them. I can say that knowing how thing operate internally is great, it fills in a lot of holes.

OS Internals

While you obviously are successful at the running and maintaining of unix like systems. How much do you know about their internal functions? While reading source code is the best method, some great books will save you many hours of time and will be a bit more enjoyable. These books are Amazing
The Design and Implementation of the FreeBSD Operating System

Linux Kernel Development
Advanced Programming in the UNIX Environment

Networking

Learning the actual function of networking at the code level is really interesting. Theres a whole other world below implementation. You likely know a lot of this.
Computer Networks

TCP/IP Illustrated, Vol. 1: The Protocols

Unix Network Programming, Volume 1: The Sockets Networking API

Compilers/Low Level computer Function

Knowing how a computer actually works, from electricity, to EE principles , through assembly to compilers may also interest you.
Code: The Hidden Language of Computer Hardware and Software

Computer Systems: A Programmer's Perspective

Compilers: Principles, Techniques, and Tools

Thanks, I share your feeling. The first time I visited this subreddit I was looking for similar posts. I wondered how people could combine Reddit with their busy life or how they would be able to indeed create stuff by at the same time consuming so much. I could not find any of this idea at that time and I just kept surfing until a few months ago when I started frequenting Reddit less and less.

In the meantime I did not stop thinking about it, read The Shallows by Nicholas Carr and wondered how people could combine all this easy, distracting input (Reddit, Facebook, just surfing in general) with bigger things that require no distractions or 'alone time', like reading, learning a new language, or in your case hoolahooping with fire. My conclusion was that you can't. If you want to go for it, you just have to go for it.

Of course you can combine Reddit with taking a test, but you can not combine it with finishing cum laude. I also realised though that this does not count for most people, they can combine these things, but they do not have the intention to become the new Einstein. It is a whole different discussion if this should even be a personal goal, but my idea was that these new Einsteins are so into the achieving of their dream that this would be really hard to combine with the great entertainment part of the internet and our society. It requires an opt-out, you will have to be an einzelganger at some times and that is exactly what what internet tries to prevent.

You worded this very well in your statement and I agree wholeheartedly. As you can see I'm still on Reddit but not for long. The past few months when I paid Reddit a visit I noticed that the lesser frequency of my visits also made me see the content better. And although I'm subscribed to a whole lot of interesting subreddits and described from all these fun things, I still noticed that I did not need all of this. It gave me a sense of passivity that I should not want in my life.

Nevertheless there are a lot pro-arguments to this website and I see that as well. Because I'm living in the Netherlands, I do not necessarily have to suffer some of the ills that the United States is made of. I can really understand that you need some inspiration of sanity if you live in a small conservative town where everyone is the personal friend of Jesus. So yeah, Reddit should inspire you, but maybe more as in a caravanserai. You meet a lot of new and interesting people, have a good night's sleep and travel on. Staying there also means that you will not arrive at your destination.

The people who say that you should do everything in moderation do not see that this is really hard for some people, but these are the same people that will give you some of the most interesting stuff. They can immerse themselves, lose themselves in Reddit or alike, but if they learn to use this energy in a more enduring way they can use it to write books, build houses or govern countries (just some examples).

In my view it works just like torrents. You have the seeders, who make things. They put in the effort. They show themselves once they finish their product. Their creations will surprise or disappoint. Then, there are the leechers. They wait. They need the seeders and they will criticize or praise the products of the seeder. Most of the time a seeder also leeches, but a lot of leechers tend to forget that they can also be seeders.

TL;DR: Reddit should inspire you, but maybe more as in a caravanserai. You meet a lot of new and interesting people, have a good night's sleep and travel on. Staying there also means that you will not arrive at your destination. Just like torrents, the society consists of seeders and leechers. The OP decided he wanted to be a seeder, I as well.

The usual advice is "get out and program!" and that works, but it can be very tricky coming up with something to write that's also satisfying. The idea is that you learn best by doing, and that many topics in programming can't really be learned without doing. All that stuff is true and I'm not denying that at all, but some of us need more. We need something juicier than spending hours configuring a UI for a project we couldn't care less about. It shouldn't be an exercise in masochism.

I guess what I'm saying is that there are a lot of ways to learn to write code and books are great if you can really sink your teeth into them (a lot of people can't). Code Complete is a great book on the practice of programming. You also say that you "get" OO pretty well, but it might open your eyes to read up on design patterns (e.g., Head First Design Patterns). You have a long way to go before you really get it

In addition to those, you could delve deeper into your languages of choice. There's no way around JavaScript if you're a web programmer, and a book like JavaScript: The Good Parts is pretty enlightening if you've got some experience in JavaScript already. It's a pretty interesting and unusual language.

But sometimes programming is about building gumption, so instead of just being practical, try to figure out what you like about computers and keep going deeper into it. If you have an interest in computer science and not in just building apps, then something like Structure and Interpretation of Computer Programs could instill in you an enthusiasm for computers that trickles down to everything else you do. If you're more interested in web design, there are probably similarly interesting books on artistic design principles.

I think what I'm ultimately saying is that you should find what you enjoy doing and just go deeper down the rabbit hole, getting your hands dirty when it's appropriate and interesting.

At UVic, I think there are security specializations for degrees such as the MTIS or the Computer Science Options (such as Network Security -- although I did the Software Engineering option for C.Sc. in my undergrad)

I focused on taking classes, but I did a LOT of my own (legal) research/projects. That "legal" caveat is IMPORTANT. Don't get arrested for a hobby, it doesn't achieve your goal, and it's not worth it. Do things the right way, don't trespass or break the law.

Most of the government cyber defense jobs are in Ontario -- so expect to have to move there if you want to work with them. I hear there are ... "sites" ... elsewhere, but realistically you would have to "do your time" there before anything like that became available.

Business and Finance classes are always a good idea -- not just for business but personal benefit. My wife is an accountant and those skills are really helpful to have for our daily/monthly/etc finances.

Advice

• You have to "shoot straight" when it comes to security. Gone are the days where someone hacks the FBI and they offer him a job. Now they just arrest you and you stay there. It makes sense, why incentivise it. Don't do something that might even be construed as illegal. (With that being said, there is an argument to be made for making security education too "academic" and forgetting that people actually have to work on practical aspects -- this is outside the scope of this conversation though)
  
• There are plenty of projects such as OWASP Broken Web App, classes like Elec 567 at UVic, or just learn how to make your own VMs and attack them locally (the best route -- then you can control what's installed, with a fine-tooth comb) -- this also helps test new patches, etc to see if the software is vulnerable.
  
• Read. Lots. Subscribe to blogs, order books (I am partial to books such as Hacking: The Art of Exploitation (Pretty low level, but helps you understand what is going on under the hood), and Violent Python (more of a cookbook / handbook)), and read up on security news. Rule of thumb: Read at least 2 new security books every year (at a minimum) -- It gets easy when you have a dedicated app for security podcasts, RSS feeds, and you keep a book or two with you all the time.
  
• When interviewing for government security jobs, don't lie to them. If they asked you if you have smoked pot, tell them if you did. They are looking for truthfulness.
  
• Look at open source projects where you can contribute (general coding advice, but it helps). It doesn't have to be the Linux kernel, just work on something that isn't an assignment/project from school.
  
• Learn who the big players are in security -- Like everything on the internet, there is lots of talk. Find the people who actually know what they are talking about and listen to them. Take EVERYTHING (including this post) with a grain of salt! The classic motto is "Trust but verify". This applies to everything. The security industry is ... interesting ... Think of it as a cross between the mafia (Pay us for protection ... or else), "tinfoil hattiness" (Comes with the territory -- you see a lot more than the average person, so it skews your view on certain subjects... not all of which you can even talk about), and the classic balance between privacy and security (ranges from surveillance state and anarchy) ... Politics play a HUGE part.
  
• Always be learning. Show this to prospective employers. Don't just talk, do.
  
  
  Sorry, this turned into a bit of an essay. I'm just one opinion out there, but hopefully you get something out of this. As always, "trust but verify".
  
  [edit: a word]
  

Heh, sure.

A lot of people are fans of Code Complete. I tried reading it after being in industry for a decade, and I found it to be very dry and boring. The general consensus from people that I've talked to is that it's more useful when you're just starting out. Maybe I just came to it too late.

A better book (in my opinion) in that same vein is Clean Code. Clean code is shorter, more focused, and has better real-world examples. It feels less "complete" (hue hue) than Code Complete, but to me, that's a strength. As a quick point of comparison: Code Complete devotes 32 pages to the chapter on identifier naming; Clean Code devotes just 14.

I got a lot out of Design Patterns. I seem to recall that the pattern fad was in full swing back when I read this in 2005-ish. I think I had independently discovered some of the patterns already at that point, but this book helped me to codify those ideas and also showed me some new ones. Some of these patterns are now seen as antipatterns (I'm looking at you, Singleton!), and all of the patterns have an object-oriented bias. But there's still something useful in the pattern language, and this book is a reasonably comprehensive start. The book is somewhat dry, and some people report that Head First Design Patterns is a gentler and friendlier introduction. Head First Design Patterns hits the essential patterns, but misses a lot of the less popular ones.

Eventually, you'll need to work in a codebase with some technical debt. Maybe it's debt that somebody else put there, or maybe it's debt that you introduced. Working Effectively with Legacy Code is still my go-to recommendation. It defines technical debt as code that is not under test, it introduces the idea of "seams" that you can use to pry apart code that's too tightly coupled, and it then provides a cookbook of specific scenarios and reasonable approaches.

If you're looking for thought-provoking videos, I recommend anything by Rich Hickey. I don't know if I've watched all of those, but I remember good things about Hammock Driven Development and especially Simple Made Easy.

Get comfortable with a source control system. I didn't use source control in college, since it wasn't needed for any classes, and that was a missed opportunity. The whole world loves Git, so you'll probably want to learn it if you haven't already. But I'll also toss out a recommendation for Mercurial. I haven't used it in years, but I remember finding it to be quite good.

Good luck!

Physicist here so don't pretend I don't know what science is. (Though like the ancient Pythagoreans I'm sure as soon as I discuss something that has been proven that goes against a purely scientific worldview out comes the pitchforks.) And though I love science, unlike some people here I am willing to admit to the limits of science. Science can lead to all truth in the same way that rational numbers define all numbers: it can't! and Godel proved it.

The real problem with science is that it has been mathematically proven by Godel that there are more things that are true then are provable and thus you can't ever have a scientific theory that can determine the truth or falsity of all things. As soon as you write down that theory, assuming it allows for arithmetic, Godel's incompleteness theorem immediately shows if the theory is true there will be true statements about reality that are beyond provability. Read Godel Esher Bach or Incompleteness or work through it yourself in this textbook as I have.

So like I said above, science is great in it's sphere (and in that sphere let me emphasize it is awesome!) but leads to all truth in the same way that rational numbers leads to all numbers. (And the analogy is precise since Godel used the famous diagonizational argument in his proof.) Russell and Whitehead set out to show in the early 1900s that if we could determine the axioms of reality then through logic work out everything that was true and Godel spoiled the party.

It it would be one thing if these truths were trivial things, but they are not. Some examples of true or false statements that may fall into this category of being unprovable are:

• Goldbach's conjecture and an uncountable number of mathematical theorems (by the diagonalization argument) for that matter.. (Search the pdf for Goldbach)
  
  
• Issues related to the halting problem in computer science.
  
  
• Issues related to recursive logic and artificial intelligence.
  
  
• And again, this list goes on uncountably.
  
  Now, at this point critics almost always tell me: but Joe, Godel's incompleteness theorem is only relative to your set of logic. (Ie... we can prove Goldbach by just adding axioms needed to do so.) Fine. But two things: (first) adding axioms to prove what you want willy nilly is not good science. (Two) You now have a new set of axioms and by Godel's theorem there is now a new uncountable set of things that are true (and non-trivial things like I listed) that are beyond proof.
  
  Now usually comes the second critique: But Joe, this doesn't prove God exists. And this is true. But at least it has been proven God gives you a chance. It has been proven that an oracle machine is free from the problems that hold science and logic back from proving the truth of all things. At least something like God gives you a chance (whereas science falls short).
  
  Or, like Elder Maxwell says so well: it may only be by the "lens of faith" that we can ever know the truth of all things. He maybe be right, and hence the importance to learn by study, and also by faith...

You have to be above the bar to begin with. If you can understand exactly what intelligence is then you can increase it.

Meditation can be used as a way to gain insight. This is not all types of meditation, but there are definitely types of meditation with the goal of enlightenment in mind. Using the Buddhist definition of enlightenment and overly simplified explanation is insight, specifically the type of lower level type of insight that not everyone can get to and for the most part needs to be unlocked. Once it is unlocked, how one utilizes it can be a large intelligence booster, but you have to be able to comprehend how your mind works. If you can't fully recognize a lot of advanced and abstract concepts then knowledge gain is possible but hardly any intelligence gain.

Using the example you mention, math is utilized on the other part of the brain in such a way that you can multitask while solving advanced math problems. A way this can be figured out is solving math problems in your sleep. It is like a piece of your brain is a math coprocessor and it can chug along while you are talking to someone, reading writing, sleeping, or generally not paying attention to it, much like cooking something in the oven.

It depends what you want to learn. The most direct path is raw insight. For advanced logic, paradoxes, and other mathy nerdy stuff you might want to checkout GEB. Meditation doesn't skip the learning step. You still have to learn things the same way everyone else does. Meditation just helps you realize you can utilize your brain to a more full potential.

If you are really interested and think you can can push forward, I highly recommend you try a 300µg+ dose of lsd. Tripping is the same thing as a deep meditation state, but it doesn't stay. It is like driving a car over the mountain instead of walking. In a deep state under the influence you can do all of the more insightful things one can do in a deep meditative headspace. However, figuring it out could take multiple trips as sometimes insight will take 6 hours to come full circle. When meditating in a deep headspace the answer can come much quicker.

The idea is if you can figure it out while tripping, then you can remember what you've learned and migrate it into meditative practices, as it can literally take a life time to get to the level of meditation skill as one night of dropping acid will bring you to.

It is definitely possible. If you don't ask very specific detailed questions about how your brain works, I will not be able to explain in detail, and without asking yourself you can't move towards figuring things out either.

An efficient way to get to a deep headspace from meditation is a map, so you have an idea of which direction to go in. This tends to be pretty good.

well depends on what you want to learn. Do you only want to do webdev stuff or learn a ton about CS concepts? I'm going to answer in terms of learning CS stuff, but first here's a page on how to go from knowing nothing to knowing a wide range and depth of CS topics: you do this, you'll be a grade A software engineer!

OK, moving on. First the basics which it sounds like you've got covered.

1. understand basic programming concepts (conditions, loops, functions)
   
2. learn a programming language pretty well, it doesn't matter what language. Being good at and Understanding CS concepts does not involve mastering a single language... once you get the concepts any language will be easy to learn... It sounds like you know some Javascript (not my personal recommendation for learning CS concepts), personally I'd recommend Python (easy syntax, great resources, wide use, etc..)
   
   OK, now where it sounds you stand. Learning the Advanced stuff.
   
   
3. Algorithms: The bread and butter of programming. There are many resources out there, if you want to buy a book, the gold standard is "Intro to Algorithms, 3rd edition ". Other than that, I'd suggest just the relevant Wikipedia article for algorithms. Take the pseudocode and implement it yourself in your language of choice. Understand what the algorithm is doing. Compare it to similar algorithms, understand why/when it's better or worse.
   
   
4. OK, now that you've got that done, you can start making more complicated stuff. Come up with some silly or interesting real world examples to practice with. I suggest at this point learning more about Object Oriented Programming... learn about Classes, class structure, generics (this all varies by language). Practice, practice, practice. 4 hours of coding a day if your not doing anything else, spend the rest researching/reading.
   
   
5. Learn how to use Unix/Linux. it's good for you(tm)
   
   
6. optional but cool: Learn about Computers structures and how operating systems work, bonus points if you want to build a basic OS from scratch (this requires learning a systems language like C/C++/Rust and some assembly).
   
   anywhoooo that's kind of an overview/recommendation... feel free to ask any more questions/clarifications/suggestions for resources.

tl;dr version:

1. yes
   
2. no, but that will be the case at any school
   
   Quick background to validate the above/below: I was a 30y/o banquet manager when I decided to change careers. I had no prior experience [unless you want to count a single programming class I took in high school] but did get a job in tech support at a medium size startup while I was in school and wrote a couple apps for our department. Just before I graduated I started working at a primarily Google & Mozilla funded non-profit as their sole software engineer. I moved on after a little over two years and am now a software engineer at VMware.
   
   
3. The degree is a huge boost in getting past HR and/or having [good] recruiters work with you. You'll also learn the skills/knowledge necessary to get hired as a developer, which is obviously the more important part - but for the most part this is all stuff you can learn on your own, but you'll greatly reduce the number places that will even give you a phone screen if you don't have a degree [I'm not saying this is how it should be, but this is how it is].
   
   
4. I typed out a lot before remembering New Relic had a great blog post a few months ago about all the stuff you don't learn in school [about software development], ha. So I would highly recommend you not only read it but also try to learn a little on your own (especially regarding SQL and version control) http://blog.newrelic.com/2014/06/03/10-secrets-learned-software-engineering-degree-probably-didnt/ Being a good developer (or good anything) takes time/experience - but knowing what they don't cover in school (and trying to learn it on your own) will help.
   
   Two books I'd suggest reading are The Pragmatic Programmer and Code: The Hidden Language of Computer Hardware and Software. Pragmatic Programmer is one of those classics that every good dev has read (and follows!). Code is great at giving you some insight into what's actually happening at a lower level - though it gets a bit repetitive/boring about halfway through so don't feel bad about putting it down once you reach that point.
   
   The best thing you can do to help you land a job is have some open-source side-projects (ideally on GitHub). Doesn't have to be anything major or unique - but it will help a lot for potential employers to see what your code looks like.
   
   

Not that I know much about you, but from your post, it seems like your only option is to bootstrap yourself up the ladder. Given the constraints, you're going to have an uphill battle, but it can definitely be done. I'm not in the same situation as you, but I've been trying to teach myself coding on the side, and I'm starting to see a lot of progress! Admittedly, I went to school for electrical engineering, so I did have a class or two of exposure there, but I was far more interested in the hardware stuff.

Anyway, here's the approach I've been using so far:

1. Codecademy - I've gone through all the HTML, CSS, and Python lessons. These are extremely valuable in getting a taste for coding; to see how things work in general, and to pick up a bit of syntax. However, these lessons won't necessarily teach you how to code. They're more like a first step. If being a programmer is like being a writer, then these codecademy lessons are like 1st grade grammar.
   
   
2. Stackexchange aka: Learn what resources are available. - The biggest thing about coding is being resourceful. That's #1. Google everything. It's out there... Stackexchange is probably the best overall resource, but there is so much documentation out there it can actually be kind of overwhelming. It will take a while for you to sift through it all, but Rome wasn't built in a day...
   
   
3. The Algorithm Design Manual, 2nd Ed is bad ass. It's really two books in one, though. The first being a basic computer science book, and the second being a quick reference guide to all the most popular and useful algorithms people use. I promise you, that if you learn what's in this book and can implement what it teaches you in code, someone will hire you.
   
   
4. Project Euler - A really neat list of programming challenges, once you have a bit of a handle on a language of your choice. I actually just came across this, and I haven't tried it out yet, but I've looked through some of the challenges, and it seems like you'd gain quite a bit of experience by going through some of them (there's over 500 of them!)
   
   
5. Keeping things in perspective - This is going to be a long, difficult thing if you don't have much technical background or haven't done any coding before. BUT... hundreds of thousands of people all across the world are following a very similar track right now. You're going to want to pull your hair out because of a bug you can't find, but then you're going to feel like superman once you fix it. You're going to doubt your code and doubt yourself, but then realize that you're making your computer do amazing things you had no idea how to do 4 months ago. And it's going to take time... if you want this to be your career, then treat it as such. There's a reason why getting a degree takes multiple years; there's a lot to learn, but you have a great advantage over the Starbucks-slurping "creative-type" at your local university... You're doing this because you want to; because it's a way out of the box you're in; because you can see the light at the end of the tunnel. Ultimately, you'll kick ass because you're doing it for yourself.
   
   
   Ha, sorry that got kind of pep-talk-ish, but I was getting excited. Anyway, maybe this will be of use to you!

A famous artefact of early computing is the boot-strapping process where the goal is a self-hosting compiler - which lets you write the compiler for a new language in the new langauge. However to get to that point a lot of earlier innovations were needed.

Take all of this with a pinch of salt - the order and the details may be wildly inaccurate, but the overall ideas viewed from afar give an idea of how we got to the point that we can choose our own language to write a compiler for another language..

To start with, raw binary values had to be set in order to define and run a program. Those raw binary values represent instructions that tell the hardwaer what to do and data that the program needed to operate. This is now usually referred to as machine code.

At first you would enter values into computer storage using switches.

Since that's so tedious and error prone, puched cards were developed along with the necessary hardware to read them so you could represent lots of values that could be read toagether. They had their own problems but it was a step forward from switches.

After some time symbolic instructions were defined as a shortcut for several machine code instructions - now usually called assembly language. For example put the value 8 and store it into a memory location 58 could be written as ST 8, [58]. This might take 3 machine code instructions, one represents the store instruction, one the value 8 and one the location 58. Since now assembly language could be written down it was easier to understand what the computer is being instructed to do. Naturally someone had the bright idea to make that automatic so that for example you could write down the instructions by hand, then create punched cards representing those instructions, convert them to machines code and then run the program. The conversion from the symbolic instructions to machines code was handled by a program called an assembler - people still write programs in assembly code and use assemblers today.

The next logical step is to make the symbolic instructions more useful and less aimed at the mundane, physical processes that tells the computer exactly how to operate and more friendly for people to represent ideas. This is really the birth of programming languages. Since programming languages allowed you to do more abstract things symbolically - like saving the current instructions location, branching off to another part of the same program to return later, the conversion to machine code became more complex.Those programs are called compilers.

Compilers allow you to write more useful programs - for example the first program that allowed you to connected a keyboard that lets you enter numbers and characters, one connected to a device to print numbers and characters, then later to display them on another device like a screen. From there you are quite free to write other programs. More languages and their compilers developed that were more suitable to represent more abstract ideas like variables, procedure and functions.

During the whole process both hardware - the physical elctronic machines and devices and software, the instructions to get the machines to do useful work - were both developed and that process still continues.

There's a wonderful book called Code by Charles Petzold that details all of these developments, but actually researched and accurate.

You can try /r/electronics, /r/askelectronics, /r/EngineeringStudents, /r/engineering and /r/arduino too, in case this doesn't receive much attention. This is a pretty small subreddit, with very few subscribers. You'll have much more luck in those subreddits (the first two are very good for these types of questions).

This book would be perfect for you. Heck, I'm in my fourth year of electrical engineering, and I love that book. I'm sure you can find a free version somewhere, but I won't link you to that. It truly is an exceptional book that really teaches you about these things. Highly recommended and well worth the money. You'll have to make some purchases before each chapter, nothing too expensive. Just stop wasting money on alcohol or drugs and spend it on something that will benefit you in the future, something more relevant to education haha.

Seriously, that book will explain to you like you're five. It is great. And if you have any questions about the contents of it, you can google it, ask someone on the subreddits, or PM me for information.

Mind if I ask where you live? And what inspires you to be an engineer? What are some of your favorite classes in school? Tell me more about you.

I must say, your approach is a very good one. I can already tell you're a highly motivated person. You have a good attitude.

Edit: Some people are suggesting you start with arduino. But I really recommend you start with reading, and the basic tools (breadboard, components, etc). Although arduino can be basic, it involves coding as well, something you're likely not familiar with. Just get the book, and I promise you'll be satisfied.

In almost every field, you're going to end up dealing with groups of things - lists of contacts, groups of users, categories of billing items, whatever. Having a deep understanding of arrays vs. (hash) sets vs. (hash) maps is huge, by far that's the most common decision I make on a day-to-day basis.

I think it's worthwhile to expose yourself to a bunch of specialized algorithms and data structures. You don't need to study them all super in-depth, but reading about them and maybe hacking them out in Python/Java/C++/whatever is a great learning exercise. I personally like "The Algorithm Design Manual" by Steven Skiena, (EDU PDF, Amazon). It's on the dry side, but it categorizes algorithms into a handful of types (sorting, graphs, combinatoric search, etc) which makes it great reference material for learning.

A handful of useful exercises, maybe useful:

• Quicksort (and why is it faster than a trivial sort like selection sort? Explain it like I'm five)
  
• Caching! Also, how it makes pure functions preferable to unpure ones for expensive code.
  
• Implement a Fibonacci function, and describe why the recursive solution is terrible (hint: draw out each function call for a number like 10). This is a great exercise in runtime analysis. Implement it better and know why your second shot is better.
  
• Graphs manage to sneak into all sorts of places - knowing Dijkstra's algorithm by heart probably isn't important, but being comfortable with graphs is valuable. Many problems can be thought of as transforming data from group A and B into C, and thought of as information travelling through a graph, being changed at each node. The graphics pipeline used for 3D graphics is a fun example of an application of this idea.

Books on project management, software development lifecycle, history of computing/programming, and other books on management/theory. It's hard to read about actual programming if you can't practice it.

Some of my favorites:

• Code: The Hidden Language of Computer Hardware and Software - GREAT choice I notice you already have listed. Possibly one of my favorite, and this should be on everyone's reading list who is involved in IT somehow. It basically how computers and programming evolved and gets you in a great way of thinking.
  
  
• The Code Book: The Science of Secrecy from Ancient Egypt to Quantum Cryptography - Another great history book on code and how things came to be. It's more about crypto, but realistically computing's history is deeply rooted into security and crypto and ways to pass hidden messages.
  
  
• Software Project Survival Guide - It's a project management book that specifically explains it in terms of software development.
  
  
• The Art of Intrusion: The Real Stories Behind the Exploits of Hackers, Intruders and Deceivers - A fun collection of short hacking stories compiled and narrated by Kevin Mitnick, one of the most infamous hackers. Actually, any of Mitnick's books are great. Theres a story in there about a guy who was in jail and learned to hack while in there and get all kind of special privileges with his skills.
  
  
• Beautiful Data: The Stories Behind Elegant Data Solutions - Most of the books in the "Beautiful" series are great and insightful. This is one of my more favorite ones.
  
  
• A Guide to the Project Management Body of Knowledge: PMBOK(R) Guide - THE guide to project management from the group that certifies PMP... boring, dry, and great to help you get to sleep. But if you're committed enough, reading it inside and out can help you get a grasp or project management and potentially line you up to get certified (if you can get the sponsors and some experience to sit for the test). This is one of the only real certifications worth a damn, and it actually can be very valuable.
  
  You can't exactly learn to program without doing, but hopefully these books will give you good ideas on the theories and management to give you the best understanding when you get out. They should give you an approach many here don't have to realize that programming is just a tool to get to the end, and you can really know before you even touch any code how to best organize things.
  
  IF you have access to a computer and the internet, look into taking courses on Udacity, Coursera, and EDX. Don't go to or pay for any for-profit technical school no matter how enticing their marketing may tell you you'll be a CEO out of their program.

...continued...

> Test plans - When you apply for QA roles, you'll almost certainly be asked "how would you test ____?". The correct answer is to be methodical. Don't just spew out a stream of test cases as you brainstorm them. Understand the different scopes (unit, functional, integration, maybe end-to-end) and what the goals of each is, and how they differ. Understand that there are different areas of testing like boundary, happy path, special cases (null, " ", 0, -1), exceptions, localization, security, deployment/rollback, code coverage, user-acceptance, a/b, black box vs white box, load/performance/stress/scalability, resiliency, etc. Test various attributes at the intersection of a compenent and a capability (borrowed from the book How Google Tests Software), and I believe you can see a video that goes into this called The 10 Minute Test Plan. Understand how tests fit into your branching strategy - when to run bvts vs integration vs regression tests.

> Test methodologies - Understand the tools that make you an efficient tester. These include data driven tests, oracles, all-pairs / equivalency class, mocking & injection, profiling, debugging, logging, model-based, emulators, harnesses (like JUnit), fuzzing, dependency injection, etc.

> Test frameworks - Knowing all the tests you need to write is good, but then you have to write them. Don't do all of them from scratch. Think of it as a system that needs to be architected so that test cases are simple to write, and new functionality is easy to implement tests for. I can't recommend any books for this because it's something I learned from my peers.

> Test tools - Selenium / WebDriver for web ui, Fiddler for web services (or sites), JUnit/TestNG, JMeter (I have to admit, I don't know this one), integration tools like Jenkins, Github/Stash, git/svn.

> System design - As you're entry-level, this may not be a huge focus in an interview, but know how to sensibly design a system. Know which classes should be used and how they interact with each other. Keep in mind that the system may evolve in the future.

> Whiteboarding - Practice solving problems on a whiteboard. The process is more than just writing the solution, though. This is the process I follow (based loosely on the book Programming Interviews Exposed):

• Clarify the problem - resolve any ambiguities, determine behaviors for special cases (throw an exception vs return null?). Look for gotchas (like if you're doing some string manipulation with overlaps)
  
• Give a couple test cases to demonstrate your understanding of the problem, to make you think of other special cases, and because they want someone who's test-focused if you go into QA. Give a happy path scenario and a couple negative or special cases
  
• Propose a solution - do this verbally, and give its runtime complexity (and less importantly, its memory usage). If the runtime complexity is bad (polynomial, exponential), then say so and think of a better solution (there will almost certainly be one)
  
• Implement the solution - verbalize your thought process while doing so. If you don't know something, say so. The interviewer will likely help you out without penalty. Listen very carefully for clues, because the interviewer will be giving them. Really understand everything the interviewer says, and understand his motivation for saying it. If you see potential bugs, say so ("I want to be careful that I don't go out-of-bounds in the last iteration of this loop").
  
• Debug the solution - walk through it as if you're a debugger, using the happy path test case that you made earlier. Oftentimes, the interviewer will give you a test case with the problem. Use it - he probably selected it for a reason (the numbers are in an interesting order that will find the most bugs, for example).
  
• Test the solution - Add to the handful of tests you gave earlier. Think about the different types of tests, and if they apply.
  
  Resources:-
  
  > Learning to test:
  
  
• How Google Tests Software
  
• Guice, and another
  
• Google Test Automation Conference
  
• Netflix's Simian Army
  
• Google Testing Blog
  
• Hermetic testing
  
• The Art of Software Testing (I've only skimmed it)
  
  > Learning to interview:
  
  
• Programming Interviews Exposed
  
• Programming Pearls
  
  > Learning to program:
  
  
• Design Patterns (I'm embarrassed that I don't have more recommendations for this...)
  
  > Miscellaneous
  
  
• Meetup
  
• Inventing on Principle
  
  > What sort of skills should I really hone? I realize I gave you a ton of stuff in this post, so here's a shorter list:
  
  

1. Read How Google Tests Software
   
2. Understand dependency injection
   
3. Understand unit, functional (use hermetic environments), and integration testing
   
4. Understand mocking (Mockito's a good one for java)
   
   > Examples of projects that make you look valuable
   
   

• Refactoring product code to be Guice-friendly
  
• Tool to profile method calls simply by adding annotations
  
• Tool to automate bug filing/updating/closing - assign to the right person, re-activate when they repro, give good steps, close when they're fixed and don't repro
  
• Tool to automatically quarantine flaky tests that aren't caused by product bugs
  
• Aggregation of distributed logs into central, indexed location (I didn't write the solution, just did the work to integrate an existing one (Logstash/Kibana))
  
• Automatically display the picture of the team member who checks in code with the highest coverage (I didn't do this, just something cool I read about)
  
• Tool that logs messages with contextual information, so for example you can see all messages associated with user 123
  
• Tool that captures inter-server traffic, associated with the user-request
  
• Tool that provides metadata about test cases in your web proxy
  

As other's have said, K&R is a great introduction to C, but not a great introduction to programming/computer science. I think more people should try to C as their first language as it gives the student a better idea of what the computer is actually doing than high-level languages. I wish I had a modern book I could refer you to for learning C as a first language, but I am out of the loop, however, I have heard great things about Harvard's free online course: Introduction to Computer Science which uses C (and some other languages).

As far as learning how to be a better programmer, I think one of the key things is to 1) strive to understand what is happening under the hood. 2) Break large problems into smaller ones 3) Logically order the operations needed to complete the tasks that solve the problem, 4) Learn multiple programming languages.

Some tips for becoming a better programmer

Strive to understand what the computer is doing when you execute your program

Understanding what the compiler/interpreter is doing with your source code, how the the processor executes the binary and how information is stored/accessed in memory will help you write more efficient code. The C language is great for learning these things once you start to wrap your mind around it. I would also recommend learning computer organization and hardware. One book I found that really helped me learn what a computer does is The Elements of Computing Systems: Building a Modern Computer from First Principles. I would recommend a casual reading of it, don't get too hung up if you don't quite 'get' it. Read it and see what sinks in. After you get better at C and maybe learn another language, come back to this book and read it again with closer scrutiny.

Break large problems into smaller ones. Logically order the operations needed to complete the tasks that solve the BIG problem

Before I write a single line of code I will spend days, weeks or even months just planning the program out. Flow charts and lists, pseudo code are your friend. Identify your large problem, think about all the different steps needed to get there, write them all down. Determine how to what you need to do to complete each step. Determine if you are doing the same task multiple times (I keep writing data to this log file, I keep checking to see if this array is full, etc.), if so, then you need a function for that. Write this all down as a human readable list of steps. Once you think you have solved the big problem, start coding the small stuff. Write small programs that complete each step you identified and test each little program. Once you've written all those little programs, put the pieces together. Check out How to Think Like A Programmer. It's an excellent book in this area.

Learn multiple programming languages

Again, stick with C until some things are really clicking for you. Eventually though you need to learn another language or two before the "thinking like a programmer" will really sink in. The more languages you learn, the easier it is to learn even more languages. You will begin to see the patterns in languages. You will notice the different approaches that different programming paradigms take. There is a reason that nearly every book, course or tutorial on learning a language follow very similar trajectory: What datatypes exist in this language? How to declare a variable of a particular type. How to output text to the screen, how to cast a variable to a different type, how arrays work in this language, how IF/Then/Else works, How loops work, etc. These are things (nearly) every language has and they are the first steps to learning how to work with that language.

Hope some of this helps!

I have an internship lined up, but I'm really excited to be learning outside of that too. You should check out The Elements of Computing Systems by Nisan and Schocken. I'm going to be working through this book throughout spring semester and the summer. I think it will provide a foundation for every low-level part of CS and help fill in some gaps that I'm missing.

If you're excited about web dev, you could make a website with Ruby on Rails, Django, Flask, Node, Meteor, etc. There's always another good web framework that you could learn.

If you're into system programming, programming languages, or compilers, there are tons of great tutorials and guides online. I'm currently working through Learn C: Build Your Own Lisp. I'm really looking forward to doing Implementing a Language with LLVM. If you didn't already know, LLVM was started here!

If you haven't finished core math yet, there's Linear Algebra on Khanacademy. I think Salman Khan is one of the best teachers I've had. The videos are very concise and very clear. There's also a great series on ML on YouTube. It explains the theoretical underpinnings of the algorithms, but doesn't really show how to use them. If you want to use them, your best bet is the Python library scikit-learn.

For reverse engineering, here's a fantastic challenge site, and here's a good book that you can view online.

There's so much to do, and not enough time to do it! If you constantly work on a few things, little by little, it will all start to accumulate. Good luck and have fun this summer!

Computer scientist here... I'm not a "real" mathematician but I do have a good bit of education and practical experience with some specific fields of like probability, information theory, statistics, logic, combinatorics, and set theory. The vast majority of mathematics, though, I'm only interested in as a hobby. I've never gone much beyond calculus in the standard track of math education, so I to enjoy reading "layman's terms" material about math. Here's some stuff I've enjoyed.

Fermat's Enigma This book covers the history of a famous problem that looks very simple, yet it took several hundred years to resolve. In so doing it gives layman's terms overviews of many mathematical concepts in a manner very similar to jfredett here. It's very readable, and for me at least, it also made the study of mathematics feel even more like an exciting search for beautiful, profound truth.

Logicomix: An Epic Search for Truth I've been told this book contains some inaccuracies, but I'm including it because I think it's such a cool idea. It's a graphic novelization (seriously, a graphic novel about a logician) of the life of Bertrand Russell, who was deeply involved in some of the last great ideas before Godel's Incompleteness Theorem came along and changed everything. This isn't as much about the math as it is about the people, but I still found it enjoyable when I read it a few years ago, and it helped spark my own interest in mathematics.

Lots of people also love Godel Escher Bach. I haven't read it yet so I can't really comment on it, but it seems to be a common element of everybody's favorite books about math.

I’ve been working on this for a while, so I might as well drop it here. It should provide an authoritative answer for “How do I get started in CyberSecurity”

Before I get started, there are a few things I need to explain about cybersecurity - There are a ton of different areas of “CyberSecurity”.

This post is specifically catered around the core concepts of cybersecurity.

The most basic thing you need to understand about cybersecurity: It revolves around stuff communicating with other stuff. Anything from side-channel attacks to large-scale DDoS’ - stuff is insecure because stuff communicates with other stuff. Communication can be hard understand and even harder to define (let alone secure). I know this is a very vague statement, but it’s one of the core, fundamental concepts of cybersecurity.

The second most basic thing about cybersecurity you need to understand - “hacking” (I hate that word) as it’s known is not some bond-villain type activity. It’s intentionally mis-using something that already exists in a way that introduces a security flaw into the environment. Sometimes the right circumstances line up and this flaw can be leveraged into something, but sometimes it can’t.

I split up my resources into offensive-based and defensive-based because it’s important for you to understand that while each of these groups are individually important, each knowledge area is not as effective without the an understanding of the other one.

One other thing to note - Certifications are great, but you need to de-couple the idea that certifications=knowledge/skills in this field. There are certainly certifications that break out of that mold, but for the most part, this holds true. I’ve ordered them in the order in which I used/learned with these resources, so you can follow-along directly in order (if you want to). I learned offense first, so that’s the way I’m laying it out here.


Offensive-Based:


I started my career in InfoSec by studying for the most basic, foundational certification: The Security+. This is the best beginner-level cert that says “I know something about security.”

I learned by going through Professor Messer’s entire course, and I felt pretty ready after I went through it all. Here’s the link to his Sec+ course

Now, lets get into some practical stuff. OverTheWire. These are war-games, or CTF’s - challenges designed to test your practical ability in security, but also designed to help you learn new things. CTF’s are the absolute best way I’ve found to learn security. Here’s the link to OverTheWire in case Google is down. If you get stuck, here are some helpful write-up’s.

Do them in this order:

• Bandit
  
• Leviathan
  
• Natas
  
• Narnia.
  
  At this point, you should be set to start with the books and Hacking Labs.
  
  
• Penetration Testing (Book, Follow-along labs)
  
  
  
• Hacking, the Art of Exploitation (2nd Edition, Book, follow-along labs)
  
  
  At this point, I’d recommend going for another certification - CEH. Once you have the CEH, you’re ready to move into more practical-based certifications. Here's what I used to learn and practice the CEH:
  
  Now, lets get into some more practical exploitation. PentesterLabs focuses a bit more on WebApp stuff, but I’ve found its the best intro-environment (as it is relatively scripted scenarios, and you don’t have to do as much recon). They're fairly explanatory, and will walk you through the solution if you get stuck.
  
  
• PentesterLabs
  
  
  Next, lets get into HackTheBox (Exploitable virtual machines, ranging in difficulty. You’re going in mostly blind here, so you have to do your own recon and enumeration): HackTheBox
  
  Here are some helpful write-ups (Written Explanations):
  
  
• GitHub
  
  
• 0xRick Webiste
  
  Also, there’s some super awesome video explanations by IppSec
  
  
  After you get through most of these, you should be set to start on your OSCP. The OSCP contains a course (Penetration Testing with Kali), a lab environment (~50-60 vulnerable boxes), and a practical lab test at the end. OSCP
  
  After you’ve completed the OSCP, then you have enough knowledge to continue directly down the cert path, and the courses (in combination with the certs) put out by Offensive Security contain enough good content to where you don’t have to study other resources. The certification path from here on out splits into two different areas: Technical, and management.
  
  
• Technical:
  
  • OSCE (OSCP 2, basically)
    
  • OSWE (OSCP but for web exploitation)
    
  • OSEE (OSCP 3, really fucking hard).
    
    If you’re at this point, getting past the OSEE, you can pretty much walk into any offensive-based job, slap you’re cert on the table, and they’ll hire you. You don’t need my help anymore here.
    
    Now, here's the management path:
    
    
• Management:
  
  • CISSP
    
  • PMP
    
  • MBA
    
    Having the technical background of the OSCP, plus a CISSP, PMP, and MBA would create an extremely potent executive - one who can understand the technical details and risk, and who then could translate that into verbiage that other executives could understand.
    
    
    So, you’re overall standard security offensive certification path should look something like:
    
    
• Security+
  
• CEH
  
• OSCP
  
• OSCE
  
• OSWE
  
• OSEE
  
  OR
  
  
• Security+
  
• CEH
  
• OSCP
  
• CISSP
  
• PMP
  
• MBA
  
  Now, for the Defensive-based side.

My suggestion is always to start with Python. It's a very high level language and it's very easy to learn. In fact, Python recently became the most popular language to teach beginners. I know you wanted to learn Java, but there are several things about it that make it not so great for beginners, as well as several things about Python that make it good for beginners (ask why if you're interested, but it may be a bit technical). As a programmer, you will likely learn a dozen or more languages (I've learned over a dozen in school), so saving Java for a bit later isn't really an issue. You'll find in programming that a lot of the important things apply to most languages, so learning these allow you to apply them to new languages quite easily. My university now uses this book in the first year computer science courses.

Get yourself situated with a free GitHub account. GitHub is my favourite version control. If you have a student email you can get a free private repository (so others can't see your stuff). If you don't have a student email to use to get one, you can still make a free account, but it will be public. What that means is that anyone who navigates to your account can see all your code. Since you're just starting out, it shouldn't matter if people browse your code, there's not much to see since it's just you going through the basics. GitHub has a tutorial for new users and also has a user-friendly client that makes it all really simple. You can save the more complex stuff for later until you're comfortable.

Once you've gone through Python and learned a bit, it's time to get into some of the language-independent things. Introduction to Algorithms is an amazing textbook. The authors are some of the most well respected people in the field and I've used it in school in more than one course. You can go through this at any time. I recommend you programming some of the things (they provide some code as well), and perhaps trying this stuff in Java might be a good segway from Python to Java.

Algorithms.

Algorithms is an important class, but depending on how its taught, it may or may not prepare you for the challenge of actually developing an algorithm to solve a problem.

Its important to be familiar with certain algorithmic concepts. Each concept (CLRS is a great book for this but it can be...difficult to digest) is a type of solution for a certain type of problem.

Once you have some core tools in your algorithm tool box, then you can start to see how certain problems resemble certain other problems and how a solution can be crafted as a modification of a similar solution.

But to me, the real skill with algorithms isn't whether or not you can memorize a ton of algorithms, its taking a very systematic approach to developing the algorithm, and there are lots of books and classes that aren't very good at helping you learn that part. I find that sections of Programming Pearls and Programming Interviews Exposed are actually very good at helping explain the process of finding the solution.

Having a good process of algorithm building is much more important, imvho, than being able to memorize every algorithm in CLRS. That takes some study, but a lot of practice.

Data Structures:

Anytime you are writing a piece of code, you are probably doing a set of steps that looks like this:

1. Problem definition
   
2. Algorithm design
   
3. Data Structure choice.
   
4. Implementation.
   
5. Testing.
   
   Data structure choice is on that list, separate from implementation for a reason. IMVHO, smart data structure selection is what HELPS you arrive at an elegant implementation...a poor choice can yield similarly poor results in implementation.
   
   Data structures are important. Learning how to make them from scratch (lists, trees, stacks, etc...) is a good way to build your skills in a language, and its frequently the meat of programming interviews in some languages...but in the real world, you will very likely spend most of your time just focusing on selection and then using an implementation from an already well established/tested library.
   
   Knowing when to use a queue vs stack, when to use a list/array versus a hash, knowing what kind of tree will perform better under the specific conditions of your program (avl, red/black, splay, etc...)...these are things that when chosen well, will save you a massive amount of headache in the implementation and testing phases of development. Learning how to traverse those data structures is important too, for example: Recursion is taught to every cs graduate when they learn trees but then in production code it can be frowned upon for various reasons such as what happens when someone who isn't great with recursion has to maintain/debug it, or when it would put too heavy a load onto the call stack.
   
   Also, what /u/bvcxy said is spot on, its one thing to know the theory, but there is that whole other side of understanding source control, how a makefile works, learning how to use continuous integration tools like jenkins.
   
   And we haven't even gotten into debugging, that is its own skill and you will eventually also need to understand how to debug with breakpoints, inspect memory, check your code for leaks, etc...
   
   The nice thing is that so many IDE's out there are integrated with source control and memory inspection tools, so you can pick a good IDE and dive deep into understanding how to get the most out of it. Write a program in C/C++ and then deliberately put a heap memory leak into it, and learn how you can catch this with tools but also how you can inspect the memory at runtime with breakpoints to see what happens.

You may have to look up some of the terms in my reply and I apologize but, hey, you'll learn something.

I recommend Python, for the simple reason that Python manages to integrate several paradigms in one programming language (imperative, object-oriented, and functional) and a lot of what you learn with Python will carry over into other languages if you learn it deeply enough. E.g. Python has metaclasses which I believe were originally implemented in an older language called Smalltalk and so when I went over to experiment with Smalltalk (I like the Pharo implementation), it was no sweat understanding the idea of metaclasses.

Python also prepares you to read the kind of pseudocode you'll see on Wikipedia and in a lot of textbooks because Python reads a lot like pseudocode; it is an eminently readable language and actually enforces formatting conventions for clarity.

And should you decide to do a big advanced project, there are very frequently well-developed libraries available immediately available for your purposes, which is not an advantage you will get with some of the more obscure / less-used languages mentioned here.

For example, need to do machine learning? No problem! There's PyBrain.

Need to study complex graphs? No problem! There's NetworkX. (If you live in the United States, it's your taxpayer dollars at work, so enjoy.)

Need to do genetic algorithms? No problem! There's PyEvolve.

There's even a package for proving theorems in logic, FLiP.

Ruby comes recommended for similar reasons and has a purer object-oriented basis but (in my experience) fewer good libraries.

I have to disagree with several recommendations here: Lisp has been recommended in several posts and I have doubts about how much of a better or effective programmer it makes you; the evidence for such a claim is unclear and pretty much all anecdotal. And a lot of it is based on stereotypes about marginally competent enterprise Java programmer-types. Now that a number of programming languages have taken Lisp innovations like garbage collection and lexical closure to heart, there's not that much of an advantage anymore in Lisp. (IMO.) More to the point, I find that neither any implementation of Common Lisp nor Scheme enjoy quite the same support as Python.

For instance, even though Lisp has a reputation for being used widely in artificial intelligence, the AI libraries I can find for Common Lisp are relatively underdeveloped compared to those you can find for Python. For instance, in the case of soft computing methods in AI (which IMO are far more promising than logic-based approaches), between PyBrain and PyML you've got neural networks, SVM, reinforcement learning and more whereas I could only find fledgling projects like cl-machine-learning for Lisp, which apparently hasn't been worked on since 2009. (The Lisp community is notorious for not finishing projects once started.)

If you must use Scheme, I highly recommend Racket because it appears to be the most full-featured Scheme. (That's a major issue with Scheme: the standard specifies very very little and so the differing implementations tend to be kind of incompatible. One says that Scheme suffers from horrible "balkanization".)

Logo was mentioned, too. The NetLogo implementation is good for fast agent-based programming and a few other things (I found it highly useful for writing a Kohonen network implementation because of its inherently spatial character) but Logo as a language is not that great.

Prolog IMO is fucking terrible. Using it is like pulling your own teeth.

Pure functional programming languages like Haskell are kind of wanky as well. It's usually rather difficult to do anything useful with them because they disallow side effects completely but on the other hand, since you're interested in logic and computation, you'll get a lot of exposure to theoretical computer science ideas through these kinds of languages.

Bottom line is with Python you'll probably get more work done faster and have more fun that way too. And that's what counts.

One last note: I don't like SICP. Go on Amazon and look at some of the negative reviews to see what I mean. I can't exactly say what's a good intro to computer science because I'm well past that point now but this guy appears to come warmly recommended:

http://www.amazon.com/Python-Programming-Introduction-Computer-Science/dp/1887902996

And when you're a little more advanced, and want to dive into data structure and algorithms, the Segdewick "Algorithms" book is excellent, even if it uses Java for all the code:

http://www.amazon.com/Algorithms-4th-Robert-Sedgewick/dp/032157351X

They seem a like reasonable starting point I think. Repetition is the mother of mastery, the more books the better (in addition to applying what is learned).

Since Mosh is calling out learning fundamentals as important to becoming a good C# developers, I would personally also recommend some general (non C# specific books) too for who are starting out in software development:

1. Design Patterns (Amazon) - also known as the "Gang of Four" Design Patterns, it was originally published in 1994 and is still relevant today. When people talk about design patterns, they're referring to the book more often then not.
   
   
2. Soft Skills (Amazon) - Not a book on programming actually... it's a software developers life manual. The reason I like this book is it covers the other parts of the life of a developer that I haven't seen covered anywhere else. Everything from learning strategies, time management, career advice, and even some health and fitness. It was an enjoyable read and I think other developers would enjoy it too.
   
   
3. The Passionate Programmer (Amazon) It's been a while since I've read this one, but I remember it giving decent advice for building a career in software development. Not to be confused with The Pragmatic Programmer (Amazon) which should be read at some point too.
   
   There's a ton more, but those are a few that stood out to me. Essentially the more the merrier in my opinion - books, courses, videos, tutorials, and so on. The books I'm recommending here focus on adopting the developer mindset and being successful at it. That's part of the puzzle.
   
   The other part is understanding the technical details including the programming language and frameworks you intend to use.
   
   And finally, for learning about C#, I do highly recommend Mosh's videos/courses (some are free on YouTube, others available on Udemy). He's got a unique ability to explain things clearly and simply in a way that beginners can pick up quickly.
   
   What I'd do is check out his free content first, and if you agree his style is ideal for learning, an investment in one of his courses is well worth it since he'll cover a lot more breadth and depth on each of the topics and they're organized into a super consumable package rather than scouring the internet for various topics.
   

First of all, applause for the great start.

Here are some criticisms/suggestions I would like to offer. Keep in mind, I am not assuming your level/experience as a software developer:

1. Functions with smaller size. You see, most of the functions that you have written is lengthy because of the sql statements. Here comes my second point.
   
   
2. Separate business logic, application code, data storage related stuff etc. Keep things modular. That separation is important because you want things to be maintainable and reusable. Your code should be open for extension, but close for modification. If that does not make sense to you, that's perfectly fine, just start from this
   
   
3. On that note, since you are using flask, might I suggest using flask-sqlalchemy instead of sqlalchemy? You may like it better. I know you have mentioned
   
   > I force myself to write raw SQL Request to get better with SQL
   
   while that is commendable, it is not really a good idea to write raw sqls in production code if there are ORM library alternatives available. Remember, it's not always you that is going to read/modify the code. While ORM syntax will be fairly universal, your style of writing SQL may vary starkly from other people - which is what creates confusion and lets errors sneak in. Even if you want to do that, maybe keep the raw sql in separate modules (point 2).
   
   
4. Instead of computing everything and then sending the result along with the page, maybe create api endpoints for specific sections; render page with bare minimum info and from the webpage make multiple calls to update the page sections when required. This way, it will be far more responsive, user will not be waiting for you to finish all the computation and if you detect any change in any section of the page, you can just update that particular section with an appropriate api call, thereby avoiding a whole page reload. Design choices.
   
   
5. PEP8. You don't have to blindly follow every rule - just make sure you understand why those rules are there, and that if you are breaking any, you know that it is absolutely necessary for accomplishing what you want. Again, what you want may not always be what you actually need - so be really careful.
   
   
6. This is something I wish I knew earlier - Design Patterns. Without going into much details, I would recommend reading these books to start with and really understand instead of memorizing:
   
   • Head First Design Patterns
     
   • Clean Code - focused more on java, but you'll get the ideas are pretty much language agnostic
     
   • Fluent Python
     
     
7. Documentation is also important. Follow the good practices there. A remarkable reference would be Ken Reitz's Requests library.
   
   Finally, remember that all these are just suggestions, and you may already know them. You will decide which ones to take and which ones to leave behind based on your situation.
   
   Again, great job (I also learnt something from this). Just make sure you keep running.

I can't talk about Schildt's competence on Java. I know about his C books, which are pretty much recommended to be avoided. Bruce Eckel's on the other hand, I've heard only good about his materials (although I didn't really like his design patterns book very much). I've never read the two books you've mentioned though.

Have you tried the official tutorials for learning Java? They're very good IMO. They're freely available too.

My first book on java was The Java Programming Language (it teaches Java 5 [current version of java is 8]). Except that you'd be learning Java 5, which is still fully applicable, this book is very good. One of the authors is the creator of java, another is Guy Steele. He's a programming languages expert whose books I believe are worth reading just because he wrote it. He's pretty above the average, and also one of the creators of Scheme. Look him up on wikipedia =D.

I've read Core Java too (it has pretty up to date editions). I found it good, which is a win on its own since most learning sources are terrible IMO, but I didn't find anything particularly interesting about it. It does cover a lot of ground, though. I surely recommend it.

A lot of writing good java code is about understanding the usual patterns of which people make use.

The author of Core Java has a book on this (http://www.amazon.com/Object-Oriented-Design-Patterns-Cay-Horstmann/dp/0471744875/). I've never read it, but I'd guess it's good. I don't know how advanced it is though.

You can, of course, always look up the Design Patterns book (http://www.amazon.com/Design-Patterns-Elements-Reusable-Object-Oriented/dp/0201633612/). I'd not recommend reading this before learning java. I think you should only do it after learning some java. Although I don't think it's a particularly challenging book, I think it'll make a lot more sense given you can see its code examples (mostly in C++, and some in smalltalk; but mostly in C++) and understand what they do. You don't need to really know C++ for that, honestly. The code doesn't make use of any (IMO) advanced features of C++. Knowing java and using common sense I think is enough to understand what is in there.

There are many books on better using java. If you google for good java books, you'll find plenty of reviews, recommendations, and so forth. You can search amazon too.

By the way, a lot of the programming techniques for writing good code in one language can be learned by studying materials in other languages. For example, I owe much of my programming basis knowledge to K&R2 (The ANSI C Programming Language - 2e), SICP (Structure and Interpretation of Computer Programs), The Little Schemer, and The Seasoned Schemer. These books teach in C and Scheme (two languages that I probably will never use professionally), but a lot of what they teach I've been able to apply while coding in C++, Java, JavaScript, PHP, SML, Python, and also other languages I've used in the past.

Good luck.

I am not totally sure what you are asking for actually exists in book form...which is odd, now that I think about it.

If it were me, I would think about magazines instead. And if you really want to push him, think about the following options:

1. Science News, which is very similar to the front-matter of the leading scientific journal Science. This includes news from the past month, and some in-depth articles. It is much better written -- and written at a much higher level -- than Scientific American or Discover. For a very intelligent (and science-interested) high school student, this should pose little difficulty.
   
2. The actual journal Science. This is weekly, which is nice. In addition to the news sections, this also includes editorials and actual science papers. While many of the actual papers will be beyond your son, he can still see what passes for presentation of data in the sciences, and that is cool.
   
3. The actual journal Nature. This is also weekly, and is the british version of the journal Science. In my opinion, the news section is better written than Science, which is important as this is where your kid's reading will be mostly done. IN addition, Nature always has sections on careers and education, so that your son will be exposed to the more human elements of science. Finally, the end of nature always has a 1-page sci-fi story, and that is fun as well.
   
4. If you must, you could try Scientific American or Discover, but if you really want to give your kid a cool gift, that is a challenge, go for one of the top three here. I would highly recommend Nature.
   
   If you insist on books...
   
   I see you already mentioned A Brief History of the Universe, which is an excellent book. However, I am not sure if you are going to get something that is more "in depth." Much of the "in depth" stuff is going to be pretty pop, without the rigorous foundation that are usually found in textbooks.
   
   If I had to recommend some books, here is what I would say:
   
   
5. The selfish gene is one of the best "rigorous" pop-science books out there. Dawkins doesn't really go into the math, but other than that he doesn't shy away from the implications of the work.
   
6. Darwin's Dangerous Idea by Dennett is a great book. While not strictly science, per se, it does outline good philosophical foundations for evolution. It is a dense read, but good.
   
7. On the more mathematical side, you might try Godel, Escher, Bach, which is a book that explores the ramifications of recrusiveness and is an excellent (if dense) read.
   
8. You could also consider books on the history of science -- which elucidate the importance of politics and people in the sciences. I would recommend any of the following: The Double Helix, A man on the moon, The making of the atomic bomb, Prometheans in the lab, The alchemy of air, or A most damnable invention. There are many others, but these came to mind first.
   
   Hope that helps! OH AND GO WITH THE SUBSCRIPTION TO NATURE
   
   edit: added the linksssss

As one of the people who commented on that thread, I feel the need to respond to this as rationally as humanly possible.

For starters, let's clear up the difference between fractal mathematics, fractal woo, and what Douglas Hofstadter might call fractal analogy.

1. From the wiki - Fractal Mathematics would be the study of "natural phenomena or a mathematical sets that exhibits repeating patterns that display at every scale" as well as the study of self similarity and iterated functions. While it has grown complex and vast, the studies of fractals and their geometry started out as literally what you say it isn't: people asking questions about self-similarity in nature and asking how to describe it mathematically.
   
   
2. Fractal Woo would be, as OP said:
   
   >“Everything big is just like everything small!” they exclaim, “the universe is self-similar!”
   
   ...and then using such logic to thereby justify whatever silly energy-Reiki-mystical-connectedness-telepathy-de-jour they want.
   
   
3. Fractal Analogy (my term, but run with it) would be seeing patterns in the world which are, indeed, self similar, as tons of stuff in nature is. This includes plant and animal system, as well as consciousness and human experience. The reason I mention Douglas Hofstadter is that he is a PhD physicist who literally used fractal mathematics to predict some pretty nifty real world stuff 35 years before it was confirmed - but Mr. Hofstadter is also an incredibly enjoyable author who muses at length about cognitive science and AI research, often using the analogy of self-similar shapes to help describe what we understand of consciousness in a way that most layman readers can understand. Even if you are not a very capable mathematician, I highly recommend his Godel Escher Bach, which uses fractals and loads of other creative stuff to help conceptualize how the "mind" arises from the brain.
   
   As well, Chaos Theory - the study of how immensely complex patterns emerge from seemingly simple preconditions - is full of fractal mathematics. Given that the universe is absolutely packed with iterated functions and self-similarity almost everywhere we look, I think you can absolutely take the point of view that the universe is fractal in nature, especially when you are in a self-induced state where your brain makes a lot of connections you might normally overlook or not even bother to think about.
   
   My point is that discussing things in the universe as self-similar is useful to mathematicians and non-mathematicians alike; using the word "fractal" to describe natural systems that exhibit those familiar patterns might not be perfectly correct, but it's not itself offensive or an affront to reasonable discourse. I manage a business; so what's your problem if I visualize the structure of my company as a fern leaf with departments and employees as branches off the main stem? What would be the issues of discussing how incredible human cellular morphology really is with my biologist roommate, and citing some cool research someone decided to do about fractal geometry in the way our bodies build themselves?
   
   EDIT: OP's edit makes it more clear his statements were more about irrational folk seeing the universe as a single continuous fractal (that would be the "fractal woo"), and that he is not denying the existence of fractal-like patterns in nature, or that using fractal models can be useful in understanding phenomena. Sorry for any confusion and thanks for the discussion!
   
   EDIT2: /u/ombortron commented pretty well in regards to the utility of the concept of fractals in scientific discourse and otherwise:
   
   >The universe itself doesn't have to be a fractal for fractals to be important.
   
   >Fractals are quite common in our reality, and as a result, that means they are an important facet of reality, and as such they are a legitimate and common topic of discussion amongst people, and this is particularly true of people who do psychedelics.
   
   >Does this mean the universe is 100% fractal in nature? No.
   
   

Hey /u/Xerack! I'm the original author of the post linked here.

Appreciate the feedback! If you think I could clarify anything better, please let me know.

As far as resources for Reverse Engineering, I can provide you with a baseline that I would recommend starting with.

x86 Assembly:


If you don't know assembly language at all, this list of videos was where I picked up a decent amount of x86 assembly language.


A few good books would be:

• Hacking: The Art of Exploitation I am a huge advocate for this book. I learned a lot from this and have read it multiple times. It is written very well and teaches someone with no experience how to do C programming and assembly. This is mainly a book for learning exploitation/vulnerability research, but that can play hand and hand with Reverse Engineering. It will show you the assembly language break down of basic exploits and this can help you with RE.
  
  
• Practical Reverse Engineering I read through the beginning of this book and it gave me some good foundations of understanding memory and computer architecture for RE along with assembly of course
  
  
• Secrets of Reverse Engineering This book is a bit in depth, but the beginning gives another good foundation for Comp Architecture and assembly stuff.
  
  
• The IDA Pro Book Haven't personally read this book yet, but I have been told it is the defacto standard for learning IDA Pro, and it has examples you can learn from.
  
  Hands On:
  
  
  
• Legend of Random Very useful hands on with tutorials. Mainly based on cracking, but that requires reverse engineering. Highly recommend this!
  
  
• Lenas Tutorials Again, another awesome hands on tutorial, mostly based on cracking as well.
  
  
• Crackmes These are more of challenges once you start to have a little understanding down
  
  Courses:
  
  Tons of courses on youtube. I learn well from visual, so I recommend these youtube videos:
  
  
  
• Basic Dynamic Analysis
  
• Real World Decompilation There are a few videos to this series and he disassembles a game, definitely nice to learn from.
  
  
  Beyond that, Google will always be your friend, and /r/reverseengineering. I also have a bunch of material for Malware RE, but that's a bit different than Software RE, though it is relatable.

I did this, but I came to data science in the final year of my PhD when I got a job at a startup. I started with R, then SQL, then Python. I currently work in data science, moving internal ML products into production settings. I also do research - and knowing how to conduct proper trials is great if the company you work for gives you freedom in how something you've built is rolled out. I can also blend my degree with ML, e.g. designing batteries of questions to identify 'good fit' candidates for a given role - I combine the battery results with future performance data and continually refine the question set / improve the model. As well, I'm a good fit for UX and dabble in that. The combo skillset will give you the ability to produce value in many different ways.

The things that helped me most were:

• Early on, Programming for Everybody - very gentle intro, and well taught.
  
  
• Andrew Ng's machine learning course.
  
• SQLzoo.
  
• The Introduction to Statistical Learning course and book then, later, The Elements of Statistical Learning.
  
• Buying big fat books about the things I wanted to learn, and working through them (e.g., Probabilistic Graphical Models, Pattern Recognition).
  
• Coding algorithms from scratch, starting with linear regression and working my way to DNNs and RNNs. Do it in R, then Python, then Scala if you're ambitious.
  
• Doing the Kaggle intro competitions in R and then translating to Python - Titanic, census dataset, etc, and using a variety of approaches for each (i.e. xgboost, sklearn, tensorflow).
  
  It can be overwhelming, but don't worry. Do one course to completion, with that as your only goal. Then do the next. Then work on a kaggle thing. Then work through a book. One thing at a time - you might get anxious or be uncertain or want to do multiple things at once, but just start with one thing and focus on that and that alone. You'll get where you want to go.
  
  I also brushed up on my linear algebra / probability using MITs open courses and khanacademy.
  
  Beyond all this, I found that learning a lot about ML/AI really expanded my thinking about how human beings work and gave me a new and better lens through which to view behaviour and psych research/theories. Very much recommend to all psychologists.
  
  Good luck!

No problem. I am by no means an expert in writing code or buffer overflows but I have written several myself and even found a few in the wild which was pretty cool. A lot of people want to jump right in to the fun stuff but find out rather quickly that they are missing the skills to perform those tasks. I always suggest to people to start from the ground up when learning to do anything like this. Before going into buffer overflows you need to learn assembly language. Yes, it can be excellent sleep material but it is certainly a must. Once you get an understand of assembly you should learn basic C++. You don't have to be an expert or even intermediate level just learn the basics of it and be familiar with it. The same goes for assembly. Once you get that writing things like shellcode should be no problem. I'll send you some links for a few books I found very helpful. I own these myself and it helped me tremendously.

Jumping into C++: Alex Allain

Write Great Code: Volume1 Understanding the Machine

Write Great Code: Volume2 Thinking Low-Level, Writing High Level

Reversing: Secrets of Reverse Engineering

Hacking: The Art of Exploitation I used this for an IT Security college course. Professor taught us using this book.

The Shellcoders Handbook This book covers EVERYTHING you need to know about shellcodes and is filled with lots of tips and tricks. I use mostly shells from metasploit to plug in but this goes really deep.

.

If you have a strong foundation of knowledge and know the material from the ground-up you will be very successful in the future.

One more thing, I recently took and passed the course from Offensive Security to get my OSCP (Offensive Security Certified Professional). I learned more from that class than years in school. It was worth every penny spent on it. You get to VPN in their lab and run your tools using Kali Linux against a LOT of machines ranging from Windows to Linux and find real vulnerabilities of all kinds. They have training videos that you follow along with and a PDF that teaches you all the knowledge you need to be a pentester. Going in I only had my CEH from eccouncil and felt no where close to being a pentester. After this course I knew I was ready. At the end you take a 24-long test to pass. No questions or anything just hands on hacking. You have 24 hrs to hack into a number of machines and then another 24 hours to write a real pentest report like you would give a client. You even write your own buffer overflow in the course and they walk you through step by step in a very clear way. The course may seem a bit pricey but I got to say it was really worth it. http://www.offensive-security.com/information-security-certifications/oscp-offensive-security-certified-professional/

Here is my advice, take it with a grain of salt:

• There are lots and lots of flamewar worthy disagreements in computer science, programming and technology in general. Linux vs Windows vs Mac, Gentoo vs Arch vs Ubuntu, Ruby vs Python vs Java, Object Oriented Programming vs Functional Programming. Even within languages, certain frameworks have their loyalists and will tell you their favorite framework is the only way to go. Do not get mixed up in this. Follow your interests and enjoy what you're doing.
  
  
• Be patient. Do not try to learn too much too quickly. Since you have another year or so before you start taking computer science classes, you are not in a hurry. You can take this time to learn some practical skills rather than just theory (which is what /r/compsci is all about). You'll find that your classes will teach you really interesting theoretical stuff like how to measure the efficiency of your programs or how to organize your code to make it more maintainable, all of which is very helpful, but it probably won't teach you how to use Maven or how to use some of the things that the industry wants you to know how to use. This is what I mean by practical skills. Its one thing to know what a Binary Search Tree is, its another to know how to use a specific framework. Spend some time on the practical stuff now. That means actually creating stuff like websites or video games (or whatever interests you.)
  
  
• "The perfect is the enemy of the good." Don't try to make your programs perfect. Make them work and try to form healthy habits but do not be the type that settles for nothing less than perfection. If you do, you'll find that you hardly get anything done.
  
  
• Pick one language to specialize in. You will learn more this way in the beginning. A lot of people have stunted their own progress by spending their first couple of years learning different programming languages. Don't do that. You'll learn other programming languages eventually, it really isn't that hard, but you're better off specializing in a specific language (for now) than being crappy at a lot of languages. (I made this mistake.)
  
  If you want to get good at programming, I would recommend the book "How to design programs" combined together with The Racket Programming Language. If you're really up for it, mix in the content from Structure and Interpretation of Computer Programs (which is a great book by the way). If you finished those, you'll have a very good foundation for learning how to program. I would learn a new language (don't specialize in racket) and continue from there.
  
  The downside to learning racket is that it is not a common language, however as I said earlier, you'll find that learning new languages it very easy so this shouldn't be too much of a problem, especially if you're more concerned with forming a good foundation first.
  
  After learning all of that, I would say look into something on data structures and algorithms. There are a lot of great books on the subject. Introduction to Algorithms is considered the classic. If you can get through the whole thing on your own, then you are better then I am.

TL;DR Improve yourself, invest in your future, don't worry about the mistakes...read the books listed at bottom, and practice!

Few months ago I royally fucked up an interview at Microsoft. A really simple question. But I had no experience doing coding on paper instead of a computer.

I spent a lot of time studying various books and paper coding to make sure it wouldn't happen again.

I then had an interview for another (in my mind at the time) dream job. I did fine for all the phone interviews and they flew me over to the west coast for an in person interview for the day. I did well for the first bit until they started pulling out dynamic programming and integer programming questions on me and expecting me. Once again something I didn't prepare for, and f'd up. Didn't get this job either. For the longest time I was really hard on myself at fucking up on both these interviews one after another. Especially this second one since a lot more was riding on it than just the job (another story).

But then I decided I didn't want to have this sort of experience again and expected better of myself. I made myself further improve and brush up on all those concepts as well. Did a few mock interviews with friends, spent some time working on interview type questions on both the computer and on paper. A month or two later I started interviewing again. By this point I was an interviewing machine - and I'm now able to do just about anything thrown at me. I've had my choice of employers and until just recently, was in the situation where I had so many offers I didn't know which one I wanted most. I'll be heading to silicon valley soon at one of the top tech companies in the world with a fantastic offer considering I just graduated.

The point is - learn from the mistakes and improve yourself. I realize you don't want to be that guy spending heaps of time coding outside of work or whatever... but this is an investment in yourself and your career. Do it once, and then just brush up on your skills from time to time. Get into the interviewing mindset and just rock them so you can have your choice of job - and then you can go about your thing once you have the job locked. The up front investment will be worth it!

Things that helped me:

• www.hackerrank.com - practiced a lot of questions on here
  
• www.careercup.com - another great site for questions
  
• Cracking the Coding Interview More help on questions, but also some great insights into the interview process for the larger tech companies and many hints and tips on how to go about solving the more complex problems
  
• Code Complete A great book for helping you to refresh or learn about software design
  
• Eternally Confuzzled Great resource to learn how to think about common data structures and algorithms
  
  Having trouble with Algorithm design/analysis? These are some of the go-to books for that:
  
  
• The Algorithm Design Manual Probably the defacto for learning about algorithm design and analysis
  
• Introduction to Algorithms A great book with many different algorithms and data structures to learn about
  
• Algorithm Design A great book if you want to dive deeper into more complex subjects like graph theory, dynamic programming, search algorithms, etc.. etc..

You're asking a very complex question that the best current minds in the fields of sociology, politics, psychology, technology, futurology, neuroscience, education, and many others, cannot answer.

We just don't know what it is that makes a good programmer different from a bad one. We all have theories and ideas and notes and observations and anecdotes, but compiling them together doesn't generate an actual understanding of the subject.

So I'm sorry but there's no real way for anyone to answer your question.

I would look for local resources to double check wtf you're doing.

Befriend a trusted professor and visit them during office hours, or a trusted student or advisor or professional or something. Explain your concern and ask them to walk you through how they approach problems. Not the solution; just watch how they approach the problem and pay very close attention to it.

That's quite invaluable.

For instance, take SQL. If I get really stuck on a SQL problem, I go back to my root approach to it, which is to ask this question: if I had several tables of data printed out on paper, what would I tell a monkey to do to collate them and generate the output I want? That's all that SQL usually does; it explains to the computer how to collate and present diverse data tables.

And that's easy to forget when you're trying to think about join syntax or something and you're grasping at straws and trying to construct a pattern in your mind and it keeps unraveling because you don't have a good sense at the root level of what it is that you're trying to do.

Better programmers aren't defined by what they know, they're defined by how they think.

And I sense your problem is that you're trying to apply knowledge not without understanding it, but without understanding how to understand it.

Watch this, I'm about to do a cool programmer mental trick of segueing to what seems like a completely unrelated subject, but I'm actually following a mental thread that connects the two.

When linguists try to decipher ancient languages, they sometimes run into an interesting kind of trouble. Take Linear A as an example. They have the symbols. They have a pretty good idea of what some of them mean. But they have no idea how they go together or what most of them mean, because they have no context for deciphering the thing. It's completely inaccessible. For all scientists can tell, Linear A might as well be encoded symbols of sound waves which can only be translated intelligibly when played aloud. If they converted a Linear A script to MP3, it might come out a perfect rendition of All Along The Watchtower.

The problem isn't that they haven't unlocked the words, the problem is that they haven't figured out how the writers thought. And without knowing that, the words are probably unknowable. They could throw some together that have likely translations, but what sounds like "there is the sun" might actually mean "my dog ate my banana".

So the key to unlocking the language isn't to stare at the language and to try to wrestle words into place.

Instead, it's to research the culture that used the language, to try to learn more about the culture and how it functioned. Did it have a seat of government? Was it patriarchal or matriarchal? Was it militant or trade oriented or hunter/gatherer or what?

By understanding how the people lived, you get a sense of how they thought. And by understanding how they thought, you can start to figure out how they communicated. And more than one language over time has been deciphered in that way.

Or how about this; you don't speak french, but encountering a french person on the street, you're able to use hand gestures to ask them directions to something, and they're able to respond intelligently using hand gestures. How'd that happen? Because you both thought the same way.

This psychological question consumes exobiologists, because they're tasked with figuring out how to communicate with aliens who, by definition, don't think like us.

So what do they do? They return to the basic roots. And the simplest roots they can find are the hydrogen atom and the set of prime numbers. And maybe pi. Things like that. And people hear "math is the universal language" and sneer dismissively because math is boring, but it's actually true.

So I'm curious whether you're fluent in the universal language of computers, or whether you just think you are because you practiced writing linked lists 37 times.

Charles Petzold wrote a great book called "Code: The Hidden Language of Computer Hardware and Software". It doesn't teach you how to program, but it teaches you WHY you have to program. And by understanding the WHY, you get great inroads to the HOW.

I'd recommend taking a look at that if you can find it. "http://www.amazon.com/Code-Language-Computer-Hardware-Software/dp/0735611319". Notice that the second book in the "Customers Who Bought This Item Also Bought" section is titled "Think Like A Programmer". Code has better reviews so I'd start there.

But that might help.

I don't think you're stupid, I just think that you aren't thinking the right way about the problems.

Or maybe it's a problem solving thing altogether. How do you do with Sudoku or other games like that? Or chess puzzles?

I dunno. This is all food for thought, and maybe some of it will stick.

ETA: Damn I wrote a lot. I'll save it and blog it someday, maybe. Anyway, I did a search on "how programmers think" and came up with this interesting article: "http://www.techrepublic.com/blog/programming-and-development/how-to-think-like-a-programmer-part-1/43". It's interesting not because I entirely agree with it, and I couldn't find the other two parts of it anyway, but at the bottom of the first section, in bold, the author says that the big problem with some programmers is that they've been taught the HOW but not the WHY. So here again is someone supporting my point. Tricks and habits and stuff will only take you so far; at some point you have to learn the WHY in a way that lets you apply it and start coming up with your own HOW's as the need arises.

some amazing books I would suggest to you are:

• Godel Escher Bach
  
  
• Road to Reality By Roger Penrose.
  
  
• Code by
  Charles Petzold.
  
  
• Pi in the Sky by John Barrow.
  
  All of these I would love to read again, if I had the time, but none more so than Godel, Escher, Bach, which is one of the most beautiful books I have ever come across.
  
  Road to Reality is the most technical of these books, but gives a really clear outline of how mathematics is used to describe reality (in the sense of physics).
  
  Code, basically, teaches you how you could build a computer (minus, you know, all the engineering. But that's trivial surely? :) ). The last chapter on operating systems is pretty dated now but the rest of it is great.
  
  Pi in the Sky is more of a casual read about the philosophy of mathematics. But its very well written, good night time reading!
  
  You have a really good opportunity to get an intuitive understanding of the heart of mathematics, which even at a college level is somewhat glossed over, in my experience. Use it!

The Stanford Algorithm book is complete overkill in my opinion do NOT read that book. That's insane. Read it when you've been doing programming for a while and have a grasp of how it even applies.

Here's my list, it's a "wanna be a decent junior" list:

• Computer Science Distilled
  
• Java/ C# / PHP/ JS (pick one)
  
• Do some Programming Challenges
  
• SQL
  
• Maybe build a small web app. Don't worry about structure so much, just build something simple.
  
• Applying UML: and Patterns: An Introduction to Object Oriented Anaysis and Design Iterative Development
  
• Head First Design Patterns
  
• Clean Architecture
  
• Refactoring: Improving the Design of Existing Code
  
• If you're interested in Web
  
• Soft Skills: Power of Habit , A Mind for Numbers , Productivity Project
  
  ​
  
  Reasoning: So, the first book is to give you a sense of all that's out there. It's short and sweet and primes you for what's ahead. It helps you understand most of the basic industry buzz words and whatnot. It answers a lot of unknown unknowns for a newbie.
  
  Next is just a list languages off the top of my head. But you can pick anything, seriously it's not a big deal. I did put Java first because that's the most popular and you'll like find a mountain of resources.
  
  Then after some focused practice, I suggest grabbing some SQL. You don't need to be an expert but you gotta know about DBs to some degree.
  
  Then I put an analysis book that's OOP focused. The nifty thing about that book, is it breaks into design patterns nicely with some very simple design patters to introduce you to design patterns and GRASP.
  
  Then I put in a legit Design Patterns book that explains and explores design patterns and principles associated with many of them.
  
  Now that you know how code is structured, you're ready for a conversation about Architecture. Clean architecture is a simple primer on the topic. Nothing too crazy, just preps you for the idea of architecture and dealing with it.
  
  Finally, refactoring is great for working devs. Often your early work will be focused on working with legacy code. Then knowing how to deal with those problems can be helpful.
  
  FINAL NOTE: Read the soft skills books first.
  
  The reason for reading the soft skills books first is it helps develop a mental framework for learning all the stuff.
  
  Good luck! I get this isn't strictly computer science and it's likely focused more toward Software Development. But I hope it helps. If it doesn't. My apologies.

>How valuable is an Oracle cert?

No more than any other online course from a respected institution such as google, say: https://cloud.google.com/training/free-labs/ or one of the online courses available at MIT/Stanford.

>What else should I look into to boost my repertoire?

See if your university has any business partnerships you could do a 2-3 month project for. I worked with one of the university's here in the UK as part of a business/university partnership and that gives the students real world experience and us some free work. Win-win if the project is completed.

Sorry - mostly UK (amazon) links :)

TDD - https://www.amazon.co.uk/Growing-Object-Oriented-Software-Guided-Signature/dp/0321503627/ref=sr_1_1, Video by Trisha Gee whos fairly well known for speaking on this stuff: https://www.youtube.com/watch?v=QDFI19lj4OM (some very handy shortcut keys in the video and a good outline of some of the tools available to you).

Clean Code - https://www.amazon.co.uk/Clean-Code-Handbook-Software-Craftsmanship/dp/0132350882 (by "Uncle Bob")

Design patterns - https://www.amazon.co.uk/Head-First-Design-Patterns-Freeman/dp/0596007124/ref=sr_1_1

Learn to use shortcuts in Intelli J to speed up your ability to generate/refactor code: https://www.amazon.co.uk/Getting-started-IntelliJ-Hudson-Assumpção/dp/1849699615/ref=sr_1_1

Also Jetbrains does good newsletters (curated by the same lady that made the video above under TDD) sign up to stay up to date with interesting/relevant blogs/articles/industry news https://www.jetbrains.com/resources/newsletters/

Github - https://www.amazon.co.uk/Version-Control-Git-collaborative-development/dp/1449316387/ref=sr_1_4

Bash Commands - https://nikgrozev.com/2016/05/22/shell-cheatsheet-part-1-common-bash-scripting-tmux/

XP/Scrum/Kanban development process - https://www.agilealliance.org/glossary/xp/ the way we work

Trusted developer blog on various engineering topics https://martinfowler.com/

Interview Prep https://www.hiredintech.com/courses

Hint: the above books are likely to be available at any academic library. If not, request them. you likely only need to read 33-50% of them and you'll be golden. I imagine you can likely get hold of electronic versions of these books as well.

The best thing you can do to prepare yourself is to start practising developing projects... get them up on github. it could be a website, a desktop application/game/tool, a demo of sorting algorithms, a web service... literally anything. Fork others' projects, code a feature request and create a pull request back to the original repository/codebase on github. Just build something rather than nothing. Anyone can do the latter. There's so much more opportunity now that we have github available. Think of any thing you might be interested in working on and someone, somewhere has likely already got a project underway in that area, and you're free to submit a pull request to their repository at the click of a button. This wasn't really possible 10-15 yrs ago.

The simple answer is there's so much to know, you just have to find what your interests/passions are and follow those as much as possible.

No matter how good you are at what you do today, the tools will be different tomorrow and may even depend on the industry you enter: AI, web services, blockchain, computer vision, robotics? The list is long and each one requires you to be highly trained (over many years) before you're considered any good at it.

Just try to learn what you can. Find something that genuinely interests you and study it until you become a trusted authority on the subject, or you find something you're more interested in instead.

If you have any ideas for the type of area you might be interested in put them up here and perhaps someone can point you to a relevant project?

https://en.wikiquote.org/wiki/Howard_H._Aiken "Don't worry about people stealing your ideas. If your ideas are any good, you'll have to ram them down people's throats."

If you were serious about wanting some deep as-you-go knowledge of software development but from a Pythonic point of view, you cannot go wrong with following a setup such as this:

• learning python by mark lutz
  
• programming python by mark lutz
  
• fluent python by luciano ramalho
  
  Mark Lutz writes books about how and why Python does what it does. He goes into amazing detail about the nuts and bolts all while teaching you how to leverage all of this. It is not light reading and most of the complaints you will find about his books are valid if what you are after is not an intimate understanding of the language.
  
  Fluent Python is just a great read and will teach you some wonderful things. It is also a great follow-up once you have finally made it through Lutz's attempt at out-doing Ayn Rand :P
  
  My recommendation is to find some mini projecting sites that focus on what you are reading about in the books above.
  
  
• coding bat is a great place to work out the basics and play with small problems that increase in difficulty
  
• code eval is setup in challenges starting with the classic fizzbuzz.
  
• codewars single problems to solve that start basic and increase in difficulty. there is a fun community here and you have to pass a simple series of questions to sign up (knowledge baseline)
  
• new coder walkthroughs on building some fun stuff that has a very gentle and friendly learning curve. some real-world projects are tackled.
  
  Of course this does not answer your question about generic books. But you are in /r/Python and I figured I would offer up a very rough but very rewarding learning approach if Python is something you enjoy working with.
  
  Here are three more worth adding to your ever-increasing library :)
  
  
• the pragmatic programmer
  
• design patterns
  
• clean code
  
  

If you want to dig deep into the theoretical of programming, and help build a good foundation for OOP, patterns, and algorithm design, check out Concrete Mathematics: A Foundation for Computer Science. It is honestly the best textbook I have ever come across.

From there, if you're feeling really ambitious in studying algorithms, check out The Art of Computer Programming, but I should warn you, it is very dense and can be hard to understand even for accomplished developers.

Beyond that, I suggest checking out The Odin Project. It covers a variety of languages and frameworks including Ruby On Rails, which is pretty standard in app development these days. They have a lot of great references and side material. It's basically a "go at your own pace" open source coding boot-camp.

> Like I said, this is for me. I hate just being told "do this" and having no concept of why. I want to understand why I'm doing it, the implications for doing it "this way".

This... This is the mindset that will carry you and eventually make you stand out as an exceptional programmer. Learning how to do something might land you a job, but knowing how it works makes you an invaluable asset to any employer.

As long as you are passionate about learning the material, you will pick it up over time.

>This is where I realized that I was doing this wrong, at least for me. I'd be on codeabbey and know what I wanted to do, but not how. I realized that I needed to be building larger things to be working with oop concepts. I really felt I was missing a lot of "base" information.

Awesome observation. Doing studying and doing drills both have an important role in the learning process, but there are other forms of practice to include in order to reinforce the material in a meaningful way. Ruby Rogues Podcast has a great group discussion about how to learn that I highly suggest you give a listen.

Personally, I learn best by throwing myself into a project where I am in wayyy over my head. By struggling through problems, scrupulously tearing through documentation and examples, I learn a lot more of the why than the how at the end of the day.

I learned Javascript, jQuery, and AJAX by building a templating & ecommerce framework. I started out with little to no knowledge or understanding of how JS worked, and was forced to restart a number of times as I began to see what was good and what was not, but now I feel very comfortable working with it.

Find a problem, and solve it, because Computer Science is, really, just the art of problem solving.

Best of luck, and most importantly, have fun :D

Read these books to get to grips with the latest techniques and ways of working. As an employer I'd be extremely impressed if you'd read these books. They will give you a big head start when trying to move into the professional work environment. Most of them will apply to any programming language but they mainly use Java as the example language but it's very similar to C#. It's books like these that are the difference between a beginner and an expert, but don't forget when you start coding 9-5 with good developers you will very quickly pick things up. We were all in your position at one point, if you get these read it'll all be worth it in the end!

Coding

C# in depth - I've not read this one since I do Java but I've just had a quick glance. This should be pretty useful and it's a respected publisher. I think you should start with this one.

Clean Code - Great book which explains how to write clean concise code, this 1,000,000x. It doesn't matter what language you are using it should apply where ever you write code.

Cleaner Coder - Another Robert Martin book, this one is easy to read and quite short, it's all about conducting yourself in a professional manner when you are coding. Estimating time, working with co-workers, etc.. Another good read.

Growing Object-Oriented Software - This book is about writing code using test driven development. It explains the ideas and methodologies and then has a large example of a project that you build with TDD. I just read this recently and it is really good.

Head first design patterns - This book goes through essential design patterns when coding with an object orientated language. Another essential read. Very easy to read, lots of diagrams so no excuses to not read it!

Work Methodologys

Kanban

Succeeding with Agile


p.s

Start building stuff, get an account on linked in and state the languages you are working with. This will help as well because having something to show an employer is priceless.

Escher's work with tessellation and other mathematical ideas are fairly well-known and documented so I'll try to mention a few examples of things I learned in an art history course a while ago.


DaVinci's Vitruvian Man used Phi in the calculation of ratios. Example: the ratio of your arm to your height or your eyes to your face is nearly always Phi. I'm not sure if I'm correct in the body parts mentioned, my art history class was nearly 6 years ago so I'm a bit rusty. I'll try to think of some more examples and post.


EDIT: a few more examples have come back from memory. DaVinci was a master of perspective as well. As you can see DaVinci used linear lines to draw attention to the subject of his works. In the case of The Last Supper, the lines from the structure of the building, to the eyes and gestures of the disciples aim towards Jesus.


Botticelli's Birth of Venus uses a triangle to bring the subject into the viewer's mind. The two subjects on the left and right form the lines that meet at the middle of the top and close off a triangle with the bottom of the work. Venus herself is in the middle of the triangle which brings your attention to her immediately upon viewing the work.


Michelangelo's Pieta also uses a triangle to highlight its subjects. Mary's figure creates a triangle (which is considered to be quite intentional based upon her size, both in relation to Jesus, a full grown man, and from her upper and obviously enlarged lower body). Her triangle makes the outline for the subject, Jesus. He is nearly in the center of both the horizontal and vertical axises. The way he is laying, from near the top of the left and then draping to the bottom of the right, depicts a very lifeless form because of the unnatural laying. Moving the viewer's gaze from the top to the bottom of the triangle strengthens the emotion of the scene.



Moving on to architecture, vaulted ceilings also use triangles to draw your eyes down a line also make an awe-inspiring impression.


In contrast to the European's love of straight lines and geometric figures, the traditional Japanese architectural style was opposed to using straight lines. As you can see, nearly every line in a traditional Japanese building is curved. The traditional belief was that straight lines were evil because they thought evil spirits could only travel in straight lines. This design criteria made for very interesting formations and building methods which I would encourage you to check out because of the sheer dedication to the matter.


The Duomo in Florence is a great example of Renaissance architecture and has a really cool octagonal shaped dome. I could go on and on about how awesome Brunelleschi's design was, but I'll just let you read about it here.


I could talk all day about this sort of stuff, just let me know if you want anything else or have any questions. Good luck with your class!


EDIT2: I've found some more links about the subject of mathematics in art and architecture. It looks like University of Singapore actually has a class on the subject. There's also a good Wikipedia page on it as well. This article is pretty lengthy and knowledgeable, but doesn't include pictures to illustrate the topics. Finally, as almost anybody in r/math will testify, Godel, Escher, Bach by Douglas Hofstadter is a fantastic read for anybody interested in mathematics and cool shit in general.



EDIT3: LITERATURE: I know we've all heard what a badass Shakespeare was, but it really hits you like a bus when you find out that how well the man (or for you Shakespeare conspiracy theorists, men) could use words in rhyme and meter. Here's a Wikipedia article about his use of iambic pentameter and style. Nothing else really comes to mind at the moment as far as writers using math (other than using rhyme and meter like I mentioned Shakespeare doing); however, I can think of a few ways to incorporate math. If you would like to go into any sort of programming during the class, you could show how to make an array out of a word. Once that concept is understood, you could make them solve anagrams or palindromes with arrays... a favorite of mine has always been making [ L , I , N , U , X ] into [ U , N , I , X ] ( [ 3 , 2 , 1 , 4 ] for the non-array folks ).

There are some key concepts you want to get down if you really want to make the most of .NET

• OO design and basic patterns
  Design patterns are used over and over again in OO based systems. A good understanding of what they are for, and how they tend to be used will be helpful when trying to understand key framework extensions and 3d party libraries. I like to point people at Head First Design Patterns. The opinions on design patterns in this book are a bit dated and the examples use Java syntax but they are all relevant to the .NET world and will go a long way to understanding how class names and object structures are used in OO systems.
  
  IMO One of the biggest concepts you'll need to understand in OO currently is the Inversion of Control pattern (also referred to as dependency injection) and the frameworks that provide it. Most modern .NET applications leverage some kind of dependency injection to simplify development and make unit testing and porting of classes easier.
  
  NOTE: I understand many folks in the PHP world feel that PHP is a full OO system. While they have made strides in this area it is not a fully typed OO system. It's a procedural system twisted to provide some OO features.
  
  
• Syntax
  This is easy, just review MSDN docs and samples. The biggest different you will see in the .NET world is a different opinion in general on casing of object and method names.
  
  
• Frameworks
  This is the part that seems the most overwhelming IMO. The language itself is fairly easy but understanding the huge amount of 1st and 3rd party libraries, frameworks and tools can be daunting. Since you come from the PHP world I am going to assume you are most interested in web based applications. What I would recommend is to pick a set of tools for your web stack and learn them. Once you understand the key pieces of a web application and how they interact you can start picking and choosing different components to meet your needs. I am going to suggest you start with the following stack to get started with a web application, this is the same stack I use for most of my clients making smaller functional websites or simple content driven systems.
  
  
• .NET 4 (you can do 3.5 but really just go with the latest)
  
• Core Web App - MVC (3 or 4)
  
• Dependency Injection - Unity 2.0 or 2.1
  
• Data access - Entity Framework
  
• Application Security - .NET Membership Provider (there is a newer slightly better framework by MS but I cannot recall the name at the moment)
  
• Consuming 3rd party services - WCF
  
• Exposing your own services REST - MVC (since you are already using it for pages)
  
• Exposing your own services using multiple protocols/data formats - WCF
  
• XML Processing - Linq and Lambda's. Also be aware of XmlTextReader and XmlTextWriter for targeted high speed forward-only processing.
  
• Configuration management - build in web.config with CSD for complex configuration structures beyond what appsettings can provide.
  
  Key Concepts for Modern .NET Apps
  
  
• Generics
  
• Lambdas
  
• Linq
  
• Closures
  
• dynamic typing
  
• threading
  
  Some basic tools to help you:
  
  
• dotpeak - provides detailed assembly information and some decompilation.
  
• Assembly binding log viewer - helps troubleshoot dependencies by logging internal CLR calls to dependent libraries.
  
• MSBuild - Build management and orchrstarion. This is the system used internally by Visual Studio for building projects. It's a command line tool so you can build projects even without visual studio. A basic understanding of MSBuild makes it fairly easy to use any IDE or text editor you like for .NET development. I do however like VS2010 or 2012 as it goes a long way in helping you code and understand .net.
  
  Edit: Now with more links.

Throwaway account because I'd rather not have my current coworkers knowing about this.

About a year ago, I heard about Google Foobar from an article on Hacker News. I had never seen that before but it sounded interesting, and I'd always wanted to work for Google (sent my resume some years ago, heard nothing). Long story short, I found a backdoor way into Foobar, and went through the coding challenges until I got past level 3, at which point they ask if you'd like a Google recruiter to contact you. I said yes and gave them my details.

Fast forward to about two months ago. I finally got an email from an internal Google recruiter asking to talk. I freak out a little bit and start madly researching what a first contact entails (as it turns out, just an informal phone call about your career and what you might want to do at Google). During my research I also looked into what the infamous Google technical interviews might look like, and discovered that I needed to brush up on my algorithms and data structures, and fast. I told the recruiter I needed two to three months to prep (this is apparently not too uncommon, thankfully). She said that when I was ready, I should send her my resume and the jobs I'm interested in (probably in the Pittsburgh office so we can stay close to my wife's family), and she'll get the ball rolling. She also mentioned that it's possible that I could skip the standard video tech screen (since they already had a coding sample in the form of my Foobar submissions) and proceed directly to the onsite interviews.

The thing is, I've been primarily doing PHP web development for ages. I've done a bunch of freelance work previously and I've been working for a great startup for the last few years after immigrating to the US from Canada in 2009. But as far as I know, Google doesn't do much / any PHP, and we all know the general opinion on the language. I have, thankfully, done many other languages throughout my career... Javascript (lots), Java (college / some Android development), C++ (in my college days), C (when I was first teaching myself to program in a real language). But my professional experience has been dominated by PHP.

As far as education goes, I have an associate's degree in programming and about two years of a CS program (interrupted to move to the US). I always thought Google had a hard Bachelor's requirement but that's apparently not the case (you just have to show that you have the aptitude, skills, and experience necessary).

My prep so far has been reading through The Algorithm Design Manual (at least the theory part of the book), and more recently, reading through Cracking The Coding Interview and doing the questions, on paper first, and then verifying on my laptop. I am doing these questions in Python, which was the language that I did Foobar in, and probably the language I will interview in. That said, I learned Python for the first time going through Foobar, so I'm far from an expert in the language. I'm doing this prep while managing my current full time job and caring for a four month old, which I wouldn't even come close to managing without my wife's amazing support.

Doing a search here, I found the MIT Hacking a Google Interview site which seems like a goldmine, and Pramp which also seems like a great resource once I'm done with CtCI. Considering Interview Cake but only if people think it's indispensable ($200).

I have about one month left in the original timeframe I gave the recruiter. I am incredibly excited by the prospect and also incredibly intimidated. Do you have any advice for me on how to maximize my chances?

Also, should I apply as a SWE or a SWE-Frontend? My full stack web development experience seems relevant to SWE-Frontend but I don't want to only end up doing frontend work and I don't want it to be career-limiting; I like the backend stuff as well, and I'm definitely not a designer.

Thanks!

Edit: For those looking for the Foobar backdoor, it no longer works. It was a crossword you could solve that randomly generated (easy) CS and crypto clues, and was accessible from an IP apparently found in promos for The Imitation Game, but the crossword entrance has since been shut down. However, I figured out why I couldn't get in through the main method (searching Java- or Python-related CS queries). You have to both be logged into Google, and, crucially, you have to have search history enabled. Once I reenabled search history, the Foobar break-in came right up after a couple Python searches.

This is just my 2 cents, but the first thing you should be asking when learning any language is what problem are you trying to solve with the language?

C# as a language doesn't amount to anything, but it's real potential comes from the frameworks it is associated with.

​

If you're wanting to:

web develop then you would need to look into .NET Core + WebApi + MVC or a front-end framework (Angular, React, Vue).

This is a great course to get you started with. It'll create a basic web application you can modify and play around with from the database to the front-end:

https://www.pluralsight.com/courses/aspdotnetcore-efcore-bootstrap-angular-web-app

​

desktop development then look at Wpf (window presentation forms) or use electron and c#

mobile development then take a look at xamarin

​

from your use of Unity though, it seems as if you are more into game development which I would advise then to go a bit lower and really learn algorithms and good implementations. For this, there are some greats books you can use to help you get started:

Cracking the Coding Interview: 189 Programming Questions and Solutions by Gayle Laakman - Even though this is an interview book it's a great intermediate book to algorithms. The book does assume you have a basic understanding of elementary data structures.

The Algorithm Design Manual by Steven Skiena - This is definitely more advanced and heavy but it's a great book to really dig down into the nitty gritty

A great website for practicing writing algorithms in c# is leetcode.com. It's a site that basically lists a bunch of small questions you can solve with an in browser compiler that includes c#. This way you wouldn't need to download visual studio to practice coding.

if you're up for the challenege, then you can download a framework like SFML.Net and try to develop a game from the ground-up without using an engine like unity. But this is obviously a lot of work ;)

​

Overall it's hard to give really specific advice without knowing where you're trying to head. But it's a good time to get into c# and in general microsoft's development stack. In the past people were shoe horned into using microsoft's technology stack from top to bottom but recently microsoft has made a lot of stride in making there tech more open which is making a lot of people turn heads.


If you are also looking for a more lite-weight ide then I recommend visual studio code or vscodium which is the same but without the trackers :)

> Felt pretty good about myself.. until I got to the algorithm section.

This is VERY normal. These are hard math concepts that take everyone a little bit to get used to. The only way you will learn these concepts is by implementing them, over and over and over and over and over.

> I would say I was getting stuck probably about half the time and would turn to read-search-ask method.

If this were not the case, then there would be no need to learn. I am a web developer and I look up the most inane shit on a daily basis because it is something that I either have never used/implemented or something I rarely use/implement (my big one here is PHP's array functions, I can never remember if the array comes before the callback or not with array_map() but I remember that it is the exact opposite of array_filter() and array_reduce()). Embrace this, build your Google-fu because you will always need it.

> A lot of times I was missing some small operator (code error) or somewhat minor step in the thought process, other times I would be lost entirely. Basically I wasn't thinking about how to implement my code well enough, imo.

This is 100% normal. Have you ever heard of a code review? This is where other developers review your code before it goes live. The point of this is that you cannot be 100% perfect with your code, maybe you forgot a semicolon or maybe your code is tough to read, that is what the code review process is like. I write code in iterations to make sure that I never 'get in too deep' and the fear of removing code sets in, each of these phases I go through a mini code review to see what is working at what isn't. I ALWAYS find some half-baked logic in my first few iterations before I really get into it and over the last couple years I find that I need fewer and fewer iterations and that I am able to get a better 'big picture.'

Don't be afraid to scrap some code and go back at it, this is your education and only you know when you understand the material. I have a bajillion abandoned side projects and so does every developer that I know.

Advice

1. Keep coding, it is the only way you are going to get better, for real.
   
2. Read other people's code. This is where I learn all my cool tricks; Anytime I find a cool project/library/framework I hit up github and read through as much of the source as I can stomach. You will be surprised at how much you learn about the parts of a project that AREN'T code like documentation, contributing, comment styles, things that seem secondary when first learning to program.
   
3. Design patterns, paradigms, data structures, algorithms. I wouldn't suggest going head-on with this stuff yet, but don't be afraid of it. Design Patterns Book (Gang of Four) - This is a very highly suggested book, though the examples are in C++
   
4. Learn another language. The largest increases in my JS knowledge have come from learning another language and bringing back that language's way of thinking into JS. I would suggest Python because it is stupid-easy to jump in and start making cool stuff, but any language will do. Python, Java, C#, PHP, Elixir, Ruby, C++ and Go are a handful I can think of that will aid in employment as well as teach you new ways of thinking about JS.
   
5. Talk to developers, go to meetups, scour github for misspellings in documentation and contribute. Anything that you can do to get a free mentor will be an AMAZING boon for you
   
   
   

   Links
   

6. Project Euler - Looking for something to code? Here is around 600 different problems to solve. I am pretty sure some of the FCC algorithms were taken from Project Euler as it is a very good resource.
   
7. Eloquent JavaScript - A great resource, though, a little dated
   
8. You Don't Know JS - Another great resource on the JavaScript language. I reread through these books every once in a while.
   
9. Professor Frisby's Mostly Adequate Guide to Functional Programming - Great primer on functional programming with JavaScript
   
10. Rosetta Code - Algorithm reference across many languages, though, the coding style for each tends to be a mess it is a good getting-started reference.
    
11. 2017 Frontend Handbook - This is great for figuring out what to learn next when you get to that point where you don't know what to learn next.
    
    
    I did FCC up through the frontend section, I started my web dev career path in 2014 and picked up FCC in mid 2015 right before getting a job in web development. The most important part of FCC is that you are coding, getting practice and making mistakes, TONS of mistakes. Just keep it up, don't get burned out and remember that it is about your education, not how many challenges you complete. Code and read and read code.

Bishop's book Pattern Recognition and Machine Learning is pretty great IMHO, and is considered to be the Bible in ML - although, apparently, it is in competition with Murphy's book Machine Learning: A Probabilistic Approach. Murphy's book is also supposed to be a gentler intro. With an ECE background the math shouldn't be too difficult to get into in either of these books. Depending on your background (i.e. if you've done a bunch of information theory) you might also like MacKay's book Information Theory, Inference and Learning Algorithms. MacKay's book has a free digital version and MacKay's 16 part lecture series based on the books is also available online.

While those books are great, I wouldn't actually recommend just reading through them, but rather using them as references when trying to understand something in particular. I think you're better off watching some lectures to get your toes wet before jumping in the deep end with the books. MacKay's lectures (liked with the book) are great. As are Andrew Ng's that @CatZach mentioned. As @CatZach mentioned Deep Learning has had a big impact on CV so if you find that you need to go that route then you might also want to do Ng's DL course, though unlike the courses this one isn't free :(.

Finally, all of the above recommendations (with the exception of Ng's ML course) are pretty theory driven, so if you are more of a practical person, you might like Fast.AI's free deep learning courses which have very little theory but still manage to give a pretty good intuition for why and how things work! You probably don't need to bother with part 2 since it is more advanced stuff (and will be updated soon anyways so I would try wait for that if you do want to do it :))

Good luck! I am also happy to help with more specific questions!

Ok then, I'm going to assume that you're comfortable with linear algebra, basic probability/statistics and have some experience with optimization.

• Check out Hastie, Tibshirani, & Friedman - Elements of Statistical Learning (ESLII): it's basically the data science bible, and it's free to read online or download.
  
• Andrew Gelman - Data Analysis Using Regression and Multilevel/Hierarchical Models has a narrower scope on GLMs and hierarchical models, but it does an amazing treatment and discusses model interpretation really well and also includes R and stan code examples (this book ain't free).
  
• Max Kuhn - Applied Predictive Modeling is also supposed to be really good and should strike a middle ground between those two books: it will discuss a lot of different modeling techniques and also show you how to apply them in R (this book is essentially a companion book for the caret package in R, but is also supposed to be a great textbook for modeling in general).
  
  I'd start with one of those three books. If you're feeling really ambitious, pick up a copy of either:
  
  
• Christopher Bishop - Pattern Recognition and Machine Learning - Bayes all the things.
  
• Kevin Murphy - Machine Learning: A Probabilistic Perspective - Also fairly bayesian perspective, but that's the direction the industry is moving lately. This book has (basically) EVERYTHING.
  
  Or get both of those books. They're both amazing, but they're not particularly easy reads.
  
  If these book recommendations are a bit intense for you:
  
  
• Pang Ning Tan - Introduction to Data Mining - This book is, as it's title suggests, a great and accessible introduction to data mining. The focus in this book is much less on constructing statistical models than it is on various classification and clustering techniques. Still a good book to get your feet wet. Not free
  
• James, Witten, Hastie & Tibshirani - Introduction to Statistical Learning - This book is supposed to be the more accessible version (i.e. less theoretical) version of ESLII. Comes with R code examples, also free.
  Additionally:
  
  
• If you don't already know SQL, learn it.
  
• If you don't already know python, R or SAS, learn one of those (I'd start with R or python). If you're proficient in some other programming language like java or C or fortran you'll probably be fine, but you'd find R/python in particular to be very useful.

He sounds like a younger version of myself! Technical and adventurous in equal measure. My girlfriend and I tend to organise surprise activities or adventures we can do together as gifts which I love - it doesn't have to be in any way extravegant but having someone put time and thought into something like that it amazing.

You could get something to do with nature and organise a trip or local walk that would suit his natural photography hobby. I love to learn about new things and how stuff works so if he's anything like me, something informative that fits his photography style like a guide to local wildflowers or bug guide. I don't know much about parkour but I do rock climb and a beginners bouldering or climbing session might also be fun and something you can do together.

For a more traditional gift Randall Munroe from the web comic XKCD has a couple of cool books that might be of interest - Thing Explainer and What If. Also the book CODE is a pretty good book for an inquisitive programmer and it isn't tied to any particular language, skillset or programming level.

> I have zero Linux experience. How should I correct this deficiency?

First, install a VM (Oracle OpenBox is free) and download a linux ISO and boot from it. Debian and Ubuntu are two of my favorites. Both are totally free (as are most linux distros). Once installed, start reading some beginner linux tutorials online (or get "Linux In A Nutshell" by O'Reilly).


Just fuck around with it... if you screw something up, blow it away and reinstall (or restore from a previous image)

> Is it necessary? Should I start trying to make Linux my primary OS instead of using windows, or should that come later?

It's not necessary, but will help you learn faster. A lot of security infrastructure runs on Linux and UNIX flavors. It's important to have at least a basic understanding of how a Linux POSIX system works.

> If you can, what are some good books to try to find used or on PDF to learn about cissp and cisa? Should I be going after both? Which should I seek first?

You don't need to worry about taking & passing them until you've been working in the field for at least 3-5 years, but if you can get some used review materials second-hand, it'll give you a rough idea what's out there in the security landscape and what a security professional is expected to know (generally)


CISSP - is more detailed and broader and is good if you're doing security work day-to-day (this is probably what you want)


CISA - is focused on auditing and IT governance and is good if you're an IT Auditor or working in compliance or something (probably not where you're headed)


> What are good books I can use to learn about networking? If you noticed I ask for books a lot its because the only internet I have is when I connect my android to my laptop by pdanet, and service is sketchy at my apartment.

O'Reilly is a reliable publisher of quality tech books. An amazon search for "O'Reilly networking" pull up a bunch. Also, their "in a nutshell" series of books are great reference books for Windows, Linux, Networking, etc... You can probably find older/used copies online for a decent price (check ebay and half.com too)

> How would you recommend learning about encryption? I just subscribed to /r/crypto so I can lurk there. Again, can you point me at some books?

Try "The Code Book" for a very accessible intro to crypto from ancient times thru today
http://www.amazon.com/The-Code-Book-Science-Cryptography/dp/0385495323


Also, for basics of computer architecture, read "CODE", which is absolutely excellent and shows how computers work from the ground up in VERY accessible writing.
http://www.amazon.com/Code-Language-Computer-Hardware-Software/dp/0735611319

Quick note about number 6: Those terms are a lot more intimidating than they sound. Some of them take a little while to really grok what they are and why they are useful but once you understand them they are extremely useful (and huge selling points for yourself as a developer).

About the interview: From what I've heard the questions they ask are different based on different backgrounds. They are less likely to ask software development methodology questions to a new graduate since that's not really in the realm of computer science.

I did get asked some questions regarding data structures and algorithms. The ones that I was asked, and I feel I did really well on, were more related to problem solving and software architecture. Think of it this way, if they hire you, in your day to day job having memorized how to traverse a graph isn't going to come up that often. Your day to day is going to consist of coming up with solutions to problems presented with you.

So when they ask a question like how to traverse a graph, they aren't looking for you to be able to spit out Dijkstra's algorithm exactly. Instead, they are looking to see how your brain works and what kind of solution you can come to by logically breaking down the steps to solve the problem.

They are looking for how you take a problem, break it down in pieces, and what your solution would look like.

Example: Implement a scale, that has two sides and lets you know based on the objects on the two sides, which side is heavier and by how much?

My answer to this question would be something like:

• Create a WeighableInterface that requires the getWeight method.
  
• Create a few random classes that implement that interface. Maybe a horseShoe class.
  
• Create a scale class and scaleInterface that has the methods addToLeft(WeighableInterface $object) addToRight, getWeightDifference, getHeavierSide.
  
  How do you store the set of items on each side of the scale internally in the scale class? Do you need to be able to remove items from the scale, and why would this affect how you store the items internally? Should the scale have a weight limit?
  
  These are all great questions to ask. Think out loud, talk out loud. They want to see that when confronted with a problem you don't know the answer to, or don't know the best solution to that you don't freeze up but instead chunk it up and try to reason your way through it.
  
  "Should the scale have a weight limit?" Asking the interviewer this question is a huge win in your favor. It shows that not only are you trying to solve the problem, but you're constantly thinking about issues that might have been overlooked in the initial assessment.
  
  Back on number 6: I learned these by googling a fuckton. Watching a lot of videos, reading a lot of tutorials, and just asking a lot of questions.
  
  Here's some resources I still have bookmarked from the last year/18 months. Some of them are for targeted for php, but the concepts are universal. But if any of these don't do it for you, google a bunch.
  
  Solid: 1 2
  
  Inversion of Control & Dependency Injection: 1 2 3 4
  
  Domain Driven Design: This is actually a ton of concepts, and you don't necessarily need to learn them all at once. This book is the only software architecture book I've read cover to cover, its that good. If you can afford to, do buy it. Also another helpful link Intro to DDD.
  
  Test Driven Development and UnitTesting: 1 2
  
  Also I've found many of the top answers stackoverflow user tereško are great sources of wisdom regarding software development.

Depends on how old you are.

• Middle school: I really enjoyed this, this, and this, but I don't think I can read those books now (29) without cringing a little bit. Especially, Getting Things Done because I already know how to make to do list, but I still flip through all 3 books occastionally.
  
  
• High school: I really enjoyed this, this, and this, but if you're a well adjusted human and responsible adult, then I don't think you'll find a lot of helpful advice from these 6 books so far because it'll be pretty basic information.
  
  
• College: I really enjoyed this, this, and started doing Malcolm Gladwell books. The checklist book helped me get more organized and So Good They Can't Ignore You was helpful starting my career path.
  
• Graduate School: I really enjoyed this, this, and this. I already stopped with most "self help" books and reading more about how to manage my money or books that looked interesting like Stiff.
  
  
• Currently: I'm working on this, this, and this. Now I'm reading mostly for fun, but all three of these books are way out of my league and I have no idea what their talking about, but they're areas of my interest. History and AI.

I'll be honest with you, I don't think Head First Java would be a good choice, however DO READ Clean Code. I also suggest Design Patterns: Elements of Reusable Object-Oriented Software and Working Effectively with Legacy Code. The first is a classic MUST READ for anyone in software development. It present numerous challenges that most of us will face when developing solutions, and gives you the design patterns you will need to solve them. The second is great for learning how to fix your predecessors shitty code, you'll need this one. If you haven't already, look up Bob Buzzard and Andy Fawcett. These two guys are my favorite SFDC Dev Bloggers. I also suggest watching any Salesforce Webinar that has anything to do with code, especially security stuff.


Practice makes perfect, except for us there is no perfect, just better. Know your best practices and live by them. With everything you do ask how can I make it better? Faster? More efficient? Do I even need code, or will Workflow/Process Builder/Flow do? How can I write code, so that an Admin can customize it without any code?

> Based on code reviews--my code is pretty good, with good logic and pretty well laid out.

This is actually VERY important, having good logic is obviously crucial, but being well laid out is a kind of hidden requirement with code. You or somebody else will eventually need to maintain your code, if it's laid out well it should hopefully be easy to read and maintain.

When you write code do your best to incorporate declarative features so that further customization can be done without code (I know I said this earlier, but I think it's important). Need to write some code that uses an arbitrary set of fields, consider using Field Sets. An Admin can add/remove them without code. Maybe use a Custom Setting, or Custom Metadata to map fields to values.

Learn how to use Describe calls for everything. Need to write some code that catches dupes and merges them? Don't hard code the values, then nobody will be able to remove or add fields without updating code. Instead use Describe calls, now you get every field on the object forever. Need to remove a field from an object no problem. Need to add a field to an object no problem. Does your losing record have child records that need to be reparented? Don't hard code, use Describe calls to get all sObjects with a Child Relationship. Use Describe to find out if it can be directly reparented or if it needs to be clones (CampaignMembers can't reparent a LeadId to a new Lead. You MUST clone and add the new Lead Id).

How much do you know about HTML? CSS? JavaScript? JQuery? Visualforce? Learn 'em. Lightning is coming, and these are going to be more important than ever (except maybe Jquery).

Practice, practice, practice. One coding assignment per month isn't that bad, but if you get some work done early and you have an hour or two to spare, work on a side project. Can you think of something in your company that could be automated, spin up a Dev Org and give it a shot. Maybe your Sales people could use a new VF page for entering information just a little quicker.

Always seek to improve your code. Always seek new ideas and better ways of doing things.

Trailhead is good, do all the coding ones you can find, it's more practice!

Probably start with Artificial Intelligence: a modern approach. This is the state of the art AI as of 2009, of course in AI years that's ancient history but it's background you must know if you're serious about AI.

Following on from that you have the very popular statistical techniques, you can read about these in Pattern Recognition and Machine Learning. These are a wide range of statistical models and algorithms that allow machines to infer, classify and predict. Another very important concept is Chapter 14 on combining models. IBM's Watson for example uses a complex network of "simple" models who combine their answers to form the final responses.

From all the techniques in the previous book, neural networks from Chapter 5 have become the most popular and powerful. These are covered in Deep Learning, and are currently the cutting edge of machine learning. They are extremely general models that seem to be highly successful at a range of tasks. In particular their popularity comes from their amazing accuracy in image recognition, which really challenged past algorithms.

Ultimately nothing you can learn from anyone is sure to bring you close to sci-fi AI. The techniques to produce such an AI eludes even the foremost experts. You may also become disillusioned with your dream as you realise just how mechanical and constrained AI is. I personally think we'd have better luck genetically engineering intelligence in a random animal/insect than creating true intelligence in silicon and circuits.

Follow interesting people on twitter, ready up on development subreddits to get a grasp. These are useful for keeping a pulse on what's new.

As for learning, go to local user groups and technology meetups. Most cities have them and these events are a cheap and good way to learn from you peers.

Go to local code camps in your area (again these are becoming more popular). It's worth taking a weekend to go and learn new stuff. Also keep an eye out for one off developer events. In my area we always have something going on.

See if your company will pay for you to go to paid conferences.

Lastly get a Pluralsight subscription, it's worth its weight in gold and will teach you a ton of technology. They're constantly adding new stuff by industry experts.

Don't make getting a leadership position your goal, instead focus on becoming a good developer. Don't just learn new buzzwords or technologies, but try to understand how to write good clean code. Learn about unit and refactoring and in time you will move up the chain and you'll see new job offers all the time.

A few books you might want to read:

• Clean Code a great book on how to write better code, maintainable code.
  
  
• The Clean Coder - Not code related, but how to be a professional programmer
  
  
• Domain Driven Design
  
  
• Head First Design Patterns
  
  There are more obviously, but these are a few good generic books. If you are going into a specific area (like front end dev or javascript) there are a ton of specialized books on those topics. Read the latest ones there.
  
  All in all, technology will change, but having a good programming foundation and understanding what is going on (not just using a framework) will allow you to easily pick up new skills as they arise.
  
  I've been a professional developer close to 15 years and I'm always learning something new and that's just how I like it :)
  
  Edit: I forgot to add, work on personal projects , open source projects and practice practice practice. I do a lot of code katas and koans, like on a regular basis. Even simple intro katas often help.

> Recently released books? Udemy courses? Free stuff online like W3Schools or CodeAcademy?

Mozilla Developer Network has fantastic documentation for JS, HTML, CSS, and the browser APIs, and a section intended to guide you through them for the first time in a comfortable order.

If JS is your first language, I'd recommend checking out the book "Code" by Charles Petzold, a great and relatively short book that answers the fundamental beginner questions like "So what's a CPU actually doing in there?", "How does source code make stuff happen?" and "How can music be 1s and 0s?"

There's a great series of books, available for free online, called "You Don't Know JS", that teach you how the language operates. It might be too involved if it's the first thing you read, but definitely at least start it and bookmark the later volumes to come back to.

Marijn Haverbeke's book "Eloquent JavaScript" is available to read freely online. I'd really recommend that one, too. And when you want to stop reading theory and start working on actual projects, grab "JavaScript Cookbook" by Shelley Powers.

> Did I choose right languages for what I wish to create? Maybe I should also use something else, like Bootstrap, Node.js or Typescript?

Don't worry about those for now. Node will be useful if you decide you need a server component to your game. Bootstrap is nice, and it's helpful, but if you're still trying to learn HTML and CSS yourself, it will only get in the way and obscure things. TypeScript is something you'd look at only once you're comfortable and confident with regular old JS. Stick to plain old HTML/CSS/JS of your own to start.

CompSci covers a wide range of subjects, many of which won't be that relevant to you. When I was at Uni my classes covered:

• Algorithms
  
• Functional Programming
  
• Architecture and Design Patterns
  
• Ethics, Professional Issues
  
• Artificial Intelligence
  
• Compilers and Programming Language Design
  
• Data Structures
  
• Database Systems
  
• Networked Systems
  
• Operating Systems
  
• Discrete Mathematics
  
• Low-Level Systems and Hardware
  
  This list isn't comprehensive, but covers most of the main points. For your job, you can happily ignore most of that core.
  
  I think you'll want to focus on with the highest priority:
  
  
• Design Patterns (Book Suggestion)
  
• Algorithms (Book Suggestion)
  
  Warning: Algorithms is a heavy and dry book. It might not be a good recommendation for a beginner to be honest.
  
  As you're interested in Data Science, you're already off to a good start with R and Matlab. Python is fine but has some issues that don't make it ideal for large-scale data processing. The good news is that once you've got the hang of Python, you can learn another language much easier. I think it's worth noting that R is quite obtuse in my experience, so if you get your head around that you're doing quite well.
  
  But I digress. You're also going to want to learn about data structures, networked systems and databases, especially if you want to work with "Big Data". I think thought that your best starting place here is learning how to code. With that under your belt along with your math degree, everything else should be easy enough to learn on a case-by-case basis.
  
  Source: Masters & PhD in CompSci subjects. Good luck, and feel free to PM me if you're interested in a mentor for this. With a better understanding of your position, I could probably help pare down what you need to study to more specific subjects.
  
  PS: Assuming you're at Uni, your library should have both books I have suggested.

You probably already have, but if not, definitely read Design Patterns, which is old but a classic. I'd also highly recommend the Pragmatic Programmer.

EDIT: I just want to say, that I also fully support alienangel2's answer. I wanted to recommend a couple good books to get you on "the path", but ultimately, the best thing by far is to find a job that grows you. For some people, the best way to do that is to work at a super small startup, where everything you're building is from scratch. For others (like me), the best way is to work at a company with tons of really smart people who have already built great software, and learning from them and the choices they've made (and why). And if you still feel like you're regressing since school, maybe that's the answer: go back to school (i.e. get a Master's or PhD)!

Jaap Schroder wrote a book detailing his study of the Solo violin works, and he's recorded the concertos as well. That's a good place to begin. There are some really brilliant insights that most students would never consider.

Don't get caught up thinking you are handcuffed and can only imitate an anemic baroque style or a warbly, romantic style. This video is one sort of hybrid, where the soloist and conductor are very aware of performance practice, but modern instruments and techniques are relied upon heavily. Remember that no recordings exits before 1900ish. There's still a lot of personal judgment in a good historically informed performance.

There are many great Bach interpretations, and you should listen to many recordings (Grumiaux is often held in high esteem, and Schroder, as good models) to find out where your preferences lie. You should attempt to play with all sorts of expressive devices (Non vib, lots of decay, faster bow, different bow strokes, bowing patterns, holding the bow higher, gut strings?, baroque bow) and find out what you have to say about Bach. I think any successful interpretation will at least have two major things: a tremendous sense of line (form, rhythm, a large-scale view) and an expressive use of the tone color (bright, warm, deep, thick, feathery, etc.).

Leopold Mozart also wrote a treatise on violin playing. In terms of playing style, he was more familiar with the Baroque than with the music of W.A mozart. He wrote about a sense of "affect" in Baroque music. He wrote that overall, there is one overriding feeling that should come across in Barque works (especially dances and binary form movements.) In the E major Bach, I bet it would be helpful to decide what the "affect" is for each movement. Is there only one, is the narrative single-minded? More simply, come up with something other than "happy" or "sad."

Don't let anyone tell you Bach was a stodgy, strict person. He was ridiculously smart, as shown by his ability to improvise multi-voice fugues. Hofstader wrote eloquently about Bach's puzzles and intellectualism. He was a jokester - the crab canon and the Coffee Cantata or good examples. He was sometimes compensated for his work with large amounts of beer. Bach had somewhere around 20 children, about half of which survived childhood. Bach was a very complex person, with lots of life experience. Don't let a careless caricature influence how you think about his music.

So I don't think you should get too hung up on "enterprise architecture" at the moment, partially because you're still very early in your career, but also because enterprise architecture means a lot of things to a lot of different people. At this stage in your career, I really think you should focus mainly on SOLID code, core Object Oriented design concepts, and then understanding patterns. Good architectural strategies are built around all of those concepts, but they're also much much more than that.

For SOLID code, one of my favorite references is actually Dependency Injection in .Net by Mark Seemann. Although he does spend a good amount of time on DI, the recommendations that Mark makes for how to properly structure your code in order to take advantage of DI are very useful in understanding SOLID oriented design principles in general. The examples and code really work through the concepts well, so you get a great explanation followed by some well thought out code.

Clean Code by Uncle Bob is a great reference on how to structure well thought out code that touches on some architectural principles, but doesn't have that as the main focus of the book. Many of the topics in the book you'll find need to be addressed throughout a codebase.

As far as design patterns (which are different then architectural patterns), I don't think you can go wrong with the original Gang of 4 book , although I personally have a C# specific version, C# Design Pattern Essentials. I don't want to put too much emphasis on design patterns, because sometimes they get overused and applied too literally, but they are still very useful. I think the key to design patterns is not just knowing what they are, but determining where they might be applicable to your use case, and whether you should make any small adjustments or tweaks to them.

After you really have a rock solid base of working with code, then you can shift your focus on more architectural concerns. For that, it really depends on what problem your looking to solve, but Domain Driven Design (DDD) is a good way about understanding those problems and to structure the solutions in a well thought out, loosely coupled, and evolvable manner. That "central framework" that you referenced in your post is the business logic, and its the key focus of DDD

Beyond the obvious choices, Watts' The Book, Ram Dass' Be Here Now, Huxley's Doors of Perception, Leary’s The Psychedelic Experience, and of course Fear and Loathing (all of these should be on the list without question; they’re classics), here are a some others from a few different perspectives:

From a Secular Contemporary Perspective

Godel Escher Bach by Douglass Hofstadter -- This is a classic for anyone, but man is it food for psychedelic thought. It's a giant book, but even just reading the dialogues in between chapters is worth it.

The Mind’s Eye edited by Douglass Hofstadter and Daniel Dennett – This is an anthology with a bunch of great essays and short fictional works on the self.

From an Eastern Religious Perspective

The Tao is Silent by Raymond Smullyan -- This is a very fun and amusing exploration of Taoist thought from one of the best living logicians (he's 94 and still writing logic books!).

Religion and Nothingness by Keiji Nishitani – This one is a bit dense, but it is full of some of the most exciting philosophical and theological thought I’ve ever come across. Nishitani, an Eastern Buddhist brings together thought from Buddhist thinkers, Christian mystics, and the existentialists like Neitzsche and Heidegger to try to bridge some of the philosophical gaps between the east and the west.

The Fundamental Wisdom of the Middle Way by Nagarjuna (and Garfield's translation/commentary is very good as well) -- This is the classic work from Nagarjuna, who lived around the turn of the millennium and is arguably the most important Buddhist thinker after the Buddha himself.

From a Western Religious Perspective

I and Thou by Martin Buber – Buber wouldn’t approve of this book being on this list, but it’s a profound book, and there’s not much quite like it. Buber is a mystical Jewish Philosopher who argues, in beautiful and poetic prose, that we get glimpses of the Divine from interpersonal moments with others which transcend what he calls “I-it” experience.

The Interior Castle by St. Teresa of Avila – this is an old book (from the 1500s) and it is very steeped in Christian language, so it might not be everyone’s favorite, but it is perhaps the seminal work of medieval Christian mysticism.

From an Existentialist Perspective

Nausea by Jean Paul Sartre – Not for the light of heart, this existential novel talks about existential nausea a strange perception of the absurdity of existence.

The Myth of Sisyphus by Albert Camus – a classic essay that discusses the struggle one faces in a world inherently devoid of meaning.

----
I’ll add more if I think of anything else that needs to be thrown in there!

First off, well done on getting one of your first apps out there. It's always a daunting step, especially when you're a beginner.

Some general things that will help you improve your current design and any other app you choose to create going forward:

• Learn about SOLID programming principles. I won't go into too much detail because there is a wealth of resources out there to explain the basics better than I ever could such as this. Once you understand what each of the letters in the acronym means, you can use it as a framework to assess your own design.
  
• Design patterns can also be a valuable tool for a developer (though use with caution, if not used properly they can make your application needlessly complex). This site has some simple examples available specific to C#, but you might want to check out some material on object-oriented design first to get a better understanding of WHY we use patterns in the first place. The Head First series is quite a beginner friendly option in this regard Book 1 Book 2.
  
• Take a look through the official Microsoft C# guidelines, I noticed a few instances where you could improve the readability of the code based on their checklist (using implicitly typed variables with the var keyword where applicable, using string interpolation etc, using auto-implemented properties for your classes, meaningful variable names etc).
  
• Look up DRY (Don't repeat yourself), and KISS (Keep it simple, stupid), it will help you write shorter, clearer methods. I can see a few places in your code where you could decompose certain operations into separate methods.
  
• Treat user-input as an unpredictable spawn of Satan that it is: using decimal.TryParse(...) instead of Convert.ToDecimal(...), try...catch blocks, you always want to validate user-input as far as humanly possible.
  
• BONUS TIP (though some may disagree with me here): try ReSharper out, it will give you valuable suggestions while coding that you can otherwise miss. Even after 8 years of experience with C#, it helps me out tremendously.

I think it depends on your location. If you live in or a commutable distance to a city with a strong technology sector, they will be quite a bit of companies willing to hire an high school level intern.

For example, a friend of a friend got an internship after graduating high school for the summer in the city he lives. I live outside the city and I am taking a year off before university because I got sick in the summer. I'm better now but all the companies near me are kind of old fashioned and they don't accept interns after a lot of cold calling; my calls and emails get sent to their HR manager, and they don't feel like giving me a chance. Also the benefit of an internship in the city for him was that he used pretty modern web development stuff.

As a high school intern unless you find a research group, you will highly unlikely use R. You can probably do front-end web development, so learning HTML, CSS, JavaScript, Jquery, and the Bootstrap framework would be awesome. If you don't want to do front-end web development, you really have to market yourself and make sure you are competent in Python if you want to use Python.

As a person who graduated high school last year and is taking a year before university to recover from an illness, I have to compete with other university students of various years who even the freshman have some sort of qualification as a candidate for a bachelor of applied science or math degree which tells the potential employer the applicant is knowledgeable. If you want to be competitive with the freshman or maybe the sophomore students, you really need a good GitHub portfolio which shows you are knowledgeable as them.

For example, in my GitHub portfolio, I have an Android application (GitHub and Google Play). In this small to medium sized application (35, 000 lines of code), I show I can use a version control system and a bug tracker by using Git and GitHub, respectively. Furthermore, in the bug tracker, I show I can debug by showing results of me using an allocation tracker, a heap dump analyzer, a GPU rendering profiler, and the like. In the actual source code, I show my experience with Java. But more importantly, I show I can implement an architectural pattern like Model-View-Presenter (a deviation from Model-View-Controller), some design patterns like wrappers, singletons, mappers, adapter, presenters, contracts, providers, and factories, and design an API which performs network requests, database queries, and file input and output. In the source code, I try to apply as much as I can from reading, Effective Java (2nd Edition), Clean Code: A Handbook of Agile Software Craftsmanship, Design Patterns: Elements of Reusable Object-Oriented Software, and Introduction to Algorithms while I get acquainted with reading Software Engineering: A Practitioner's Approach. I still need to try to utilize TDD and Agile practices; I read about them, but I never tried them out.

I think if you have a GitHub portfolio with project(s) of a good size that shows a lot of computer science and software engineering concepts, you will be ahead of most freshman students whose only projects might be a small class project in their Intro to Java class which all their peers did.

Currently, the application has around 5,000 downloads in about a month with 4.4 rating to place it 5th in its specific category above 4 stars on Google Play: https://play.google.com/store/search?q=Manga+Reader&c=apps&rating=1; it took about a month and a half. However, every time I send my resume to a local company outside the city for an internship, I get no response. I'm going to a Career Fair at a friend's university in the city on Friday, so I'm a test my luck there; they have quite a few recruiters for mobile application interns, and one company develops a full stack product and service whose mobile applications kind of match mine. Overall, it's feasible if you are near a city, willing to commute, and can prove you know as much as a freshman student who they could hire instead.

Congratulations! That's a big step. Be proud that you were able to make the switch. Not many people manage to transform ideas into results.

I think there are four areas on which you need to focus, in order to go from mediocre to great. Those areas are:

1. Theoretical foundation.
   
2. Working knowledge.
   
3. Software engineering practices.
   
4. Soft skills.
   
   Now, these areas don't include things like marketing yourself or building valuable relationships with coworkers or your local programming community. I see those as being separate from being great at what you do. However, they're at least as influential in creating a successful and long-lasting career.
   
   Let's take a look at what you can do to improve yourself in those four areas. I'll also suggest some resources.
   
   ​
   
   1. Theoretical foundation
   
   Foundational computer science. Most developers without a formal degree have some knowledge gaps here. I suggest taking a MOOC to remediate this. After that, you could potentially take a look at improving your data structures and algorithms knowledge.
   
   

• CS50: Introduction to Computer Science
  
• Grokking Algorithms
  
• Algorithms by Sedgewick
  
  ​
  
  2. Working knowledge.
  
  I'd suggest doing a JavaScript deep-dive before focusing on your stack. I prefer screencasts and video courses for this, but there are also plenty of books available. After that, focus on the specific frameworks that you're using. While you're doing front-end work, I also suggest you to explore the back-end.
  
  ​
  
  
• FunFunFunction on Youtube
  
• You Don't Know JS
  
• JavaScript Allonge
  
• JavaScript Design Patterns ​
  
  3. Software engineering practices.
  
  Design patterns and development methodologies. Read up about testing, agile, XP, and other things about how good software is developed. You could do this by reading the 'Big Books' in software, like Code Complete 2 or the Pragmatic Programmer, in your downtime. Or, if you can't be bothered, just read different blog posts/Wikipedia articles.
  
  ​
  
  4. Soft skills.
  
  

1. Actively seek to mentor and teach others (perhaps an intern at work, or someone at a local tech community, or create blog posts or videos online).
   
2. Get mentorship and learn from others. Could be at work, or open source.
   
3. Go to programming meetups.
   
4. Try public speaking, go to a Toast Masters meetup.
   
5. Learn more about and practice effective communication.
   
6. Learn more about business and the domain that you're working in at your company.
   
7. Read Soft Skills or Passionate Programmer for more tips.
   
   ​
   
   Some closing notes:
   
   - For your 'how to get started with open source' question, see FirstTimersOnly.
   
   - If you can't be bothered to read or do large online courses, or just want a structured path to follow, subscribe to FrontendMasters and go through their 'Learning Paths'.
   
   - 4, combined with building relationships and marketing yourself, is what will truly differentiate you from a lot of other programmers.
   
   ​
   
   Sorry for the long post, and good luck! :)

The correct answer to:

Q. Should I learn C or C++ first?

Is:

A. Yes.

WARNING: Highly Opinionated Analysis of C vs C++

I see a lot of people recommending one way but no one offering an analysis of BOTH the Pro's & Con's.

I've been using C++ since ~1990. I've briefly worked on a PS3 C++ compiler when I worked for Sony. I've seen 2 major problems over the years with C++ programmers:

1. People don't exercise discipline and restraint in K.I.S.S.

They use (and abuse) every language feature because they can. There is this tendency to over-engineer even the simplest things. Take a look at this complete clusterfuck of CRC in the Boost library.

1109 lines of over-engineered C++ crap for a simple CRC32 function instead of a mere 25 lines of code!?!?! The C version would:

• do the same thing,
  
• be simpler to write, and
  
• be simpler to debug, and
  
• more importantly solve the problem at hand, not abstracted to the point of being over-engineered.
  
  The trade-off would be is that it is less flexible, but WHEN was the last time you needed to use a custom CRC polynomial!?!? One would instead use a different algorithm such as MD5, SHA, etc. that:
  
  
• has better better error-rate detection,
  
• less collisions,
  
• is multi-core.
  
  This excellent SO on hashing is but one example of focusing on the big picture.
  
  2. People lack a basic understanding of the cost let alone the implementation of C++ expressions.
  
  I've seen people stick a virtual function inside an inner loop and wonder why their performance is crap. I've seen people fail to grasp a basic understanding of pointers. I've seen people not understand memory management and how to guarantee zero memory leaks. I've seen people spend more time on writing an "über" template and waste hours debugging that instead of just writing something in 1/10 of the time and move on.
  
  IMO, due to the bloated, over-excessive verbose nature of C++ it is for these reason that I strongly recommend a beginner learn C first and then learn C++. You'll have a better understanding of why C++ is designed the way it is, what the design trade-offs are/were, what C++ hacks are, and how to best use the languages to their potential.
  
  However, this is ignoring the benefits and disadvantages of the Pro's/Con's of why one would learn C++ or C first.
  
  

  Learn C++ first
  

  
  

• C++ Pro
  
• C++ really is a better C then C in so many ways, too numerous to enumerate
  
• In the ways it is worse the smart people / companies use a sub-set of the language: Ubisoft avoid Templates, Exception Handling, and Run-Time Type Identification. When even a C++ committee member admits he writes in a sub-set of C++ himself you know the language is b-l-o-a-t-e-d.
  
• You won't have to unlearn certain "bad habits" of C
  
• Your skills will up-to-date
  
• Your code will be textually smaller (See note about Con)
  
• Job Security -- that is half joking, half serious. Seriously.
  
• You can enjoy the time exploring the different nooks and crannies of the language. You will see a different way to solve the same old problems. This can be both good and bad.
  
• Eventually you'll be able to enjoy deep technical C++ comedy such as Hitler on C++
  
• OOP (Object Orientated Programming) makes it almost easy to quickly write bigger scale programs
  
• Is multi-paradigm: Procedural, OOP, Functional, Generic. You have the freedom to pick and choose the parts of the language that fits your needs.
  
• For every problem you're trying to solve there is probably language support. Threads, and Atomics are finally part of the language.
  
  
• C++ Con
  
• You won't understand some of the C idioms used in practice
  
• The language is HUGE -- it will take you a decade to properly learn the language
  
• Debugging C++ is a PITA
  
• While people write crap code in any language, it is harder to read bad C++ code then C code.
  
• Compiler Support for the latest standards is a constantly moving target. Translation: Microsoft's Visual C++ has traditionally had crap support for the latest C and C++ standards. The good news is that MSVC 2015 finally supports a nice section of the language.
  
• While C++ can be textually smaller, one's code can easily be "bloated" if not careful (such as templates and partial template specialization)
  
• You really won't understand the run-time costs, nor be motivated to understand the underlying assembly language generated, by a "simple" C++ expression.
  
• Expect L-O-N-G compile times for any significant code base unless you use a "Bulk / Unity" build (you compile one .cpp file that includes EVERYTHING)
  
• It will be hard to resist over-engineering, over-complicating even the most basic tasks
  
• iostreams is a complete clusterfuck. Even the C++ committee recognizes there are many problems with C++ iostreams but sadly nothing is being done towards performance at the cost of type safety.
  
• It is far easier to blow your cache. Even Bjarne Stroustrup, the language designer, until 2012 didn't have a clue in understanding why Doubly Linked Lists were so slow compared to Arrays. HINT: The L1 Cache usage is critical for performance sensitive code.
  
• People tend to over-use the OOP paradigm even when they shouldn't. People make dogma and religion of "Design Patterns", failing to think if the model applies or not.
  
• The OOP paradigm is slow and bloated compared to Data-Orientated-Design. See Sony's Pitfalls of Object Orientated Programming
  
• Reflection STILL isn't standardized -- everyone has their own "home grown" approach. Maybe in C++17 ?
  
  
  

  Learn C first
  

  
  

• C Pro
  
• The language is tiny and easy to learn. Learn C the Hard Way is a great tutorial.
  
• No operator overloading
  
• No function overloading
  
• No lambas
  
• Has no reflection
  
• Has no exceptions
  
• Has no RTTI (Run-Time Type Identification)
  
• Has no STL (Standard Template Library)
  
• You will have a better understanding of the run-time "cost" or performance of code instead of a single line hiding "hidden" behaviour.
  
• You'll be a better programmer for understanding more of the lower-level implementation. If you don't know how to write itoa() or atoi() you're a noob programmer.
  
• You'll be forced to keep things simple
  
• You'll understand how to implement OOP in a non-OOP-native language, and better appreciate C++'s syntax sugar of OOP.
  
• You'll appreciate how C++ templates solve some but not all "textual replacement" problems and why #define macro's suck for debugging.
  
• Is ubiquitous, runs everywhere, and easy to get a C compiler for everything under the sun. Matz's Ruby Interpreter (MRI) was written in C, the Java VM was originally implemented in C, Perl is implemented in C, Linux is written in C. Anything popular and older then 10 years was probably written in C.
  
• Variables must be placed at top of a brace {
  
  
• C Con
  
• Compared to C++, you'll hate how primitive the language is such as typedefs for structs, no local functions, const is only "half" useful in C -- it can't be used in array declarations (See: http://stackoverflow.com/questions/5248571/is-there-const-in-c ), etc.
  
• No operator overloading
  
• No function overloading
  
• No lambas
  
• Has no reflection
  
• Has no exceptions
  
• Has no RTTI (Run-Time Type Identification)
  
• Has no STL (Standard Template Library)
  
• Simple algorithms can be tedious to write
  
• Variables must be placed at top of a brace {
  
  With that said there are numerous C++ books I would recommend to ALL C++ programmers. They are sorted from beginner to expert:
  
  
• The Design and Evolution of C++, Bjarne Stroustrup -- another ancient but fundamental to understanding all the kludges in C++
  
• The C++ Programming Language, 4th Edition <-- "Mandatory"
  
• ALL the books by Scott Meyer
  
• Effective Modern C++: 42 Specific Ways to Improve Your Use of C++11 and C++14
  
• Effective C++: 55 Specific Ways to Improve Your Programs and Designs (3rd Edition)
  
• Effective STL: 50 Specific Ways to Improve Your Use of the Standard Template Library -- ancient but good
  
• Modern C++ Design: Generic Programming and Design Patterns Applied by Andrei Alexandrescu -- another ancient but it blew the doors open for C++ Meta-Programming. IT is interesting that he hates C++ -- he now works on the D language.
  
  If you can get only one book, get the The C++ Programming Language.
  
  Even though Bruce's book is ancient he keeps it simple and is a fun easy read. Remember this is before C++98 where the language is much simpler.
  
  
• Thinking in C++, Bruce Eckel
  
  You can find it online for free
  
  Lastly, just because you can, doesn't imply you should. Use balanced C++ and you'll be fine.

I think C++ Primer is nice, and I still keep it around at work as its a useful reference to have. Being able to open up to a section about a topic and know I'll find some reference info, example code, and some good exposition is great. It covers C++11 fairly well, too. Make sure to get the most recent edition. The book does a nice job of providing a decent amount of example code, and the included exercises are very useful.

Effective Modern C++ is great, once you have a bit more experience under your belt. I pull this one out all the time to take a quick look through it when I question how I'm using some feature, and the paradigms of "Modern C++" in general are just great to follow and fun to use.

The C++ Programming Language is a reference guide: its good for more advanced programmers who want a quick reference guide that also has a bit of exposition on various concepts/features (beyond what can be found on cppreference). I still don't think it would be well suited to you- it lacks the example code and useful exercises of the C++ Primer.

As you probably well know though, the best way to learn a programming language is to write in the language. Books are good for making sure you don't do outright "bad" things at first, and in that case I'd definitely recommend the C++ Primer. I had the problem of following online sites for my first C++ experiements, and these sites never used or mentioned any of the wonderful things C++ offers like the algorithm library (learn to love everything that offers!) or even something as basic as std::vector! Instead, I was using lots of raw calls to new and delete and doing other suboptimal things.

So, I'd say go with C++ Primer to start. Follow along like you would with a maths textbook and do the example problems, and transcribe and run much of the example code yourself.

Effective C++ would be next, to help you brush up on using various features of Modern C++ and better understanding small but vital details like constexpr and move semantics.

I started learning C++ in August of this year, so I still remember a lot of what it was like to start. Feel free to ask me more if you have any questions about other materials, websites, or resources.

Hmmm, I might be completely wrong (it's been a long time since my first CS course), but you shouldn't worry so much about the language.

I mean, if it's your first one, yeah, it matters more. But most imperative, C-syntax languages are very similar, even more so from a CS 101 perspective. So you could try to learn some Java (C# is a better Java :-) ) if you find resources more easily.

If you want to see what a real :-p CS 101 course looks like, check this out: https://mitpress.mit.edu/sites/default/files/sicp/full-text/book/book.html (full text of the book available for free) and https://www.youtube.com/playlist?list=PLE18841CABEA24090 (videos from 1986 when this course was taught at HP IIRC and they recorded it). SICP is a really interesting and influential book, with a very interesting distribution of reviews on Amazon - mostly ones and fives, people seem to either love it or hate it. You might hate it, but you won't know unless you check it out ;-) I think it's best to try and watch one or two of the lectures to form a quick opinion.

Another language independent, important book is https://www.amazon.com/Introduction-Algorithms-3rd-MIT-Press/dp/0262033844.

My point is you shouldn't focus on a particular language or tech stack in college (you'll get to do that a lot on the job), but instead, try to study interesting stuff (which will help later as you'll be better equipped to recognize ideas, patterns and designs).

You probably don't need extensive knowledge of data structures for mobile apps, but I ALWAYS encourage learning data structures! Knowing what structures are available and when to use them is a bit like being a programmer super-hero and one of the things that really sets apart the self-taught hackers from the top tier engineers and scientists.

It's not a course, but I always love to plug my professor's book Open Data Structures. He's made it freely available in many different languages with code samples in multiple languages, and it's a really good read.

One thing I would highly recommend before getting into the mobile space, however, is looking into design patterns. The fundamental book on this is Elements of Reusable Object-Oriented Software by the Gang of Four, but there are some other ones I've found which are pretty handy. Game Programming Patterns is freely available, but it is a bit domain specific. It really nicely details a lot of patterns, however. JavaScript Design Patterns also really nicely details them and is also freely available.

Get an MS degree. I had a BA in Psych and went straight for MS in Comp Sci. Not every school will allow it and the ones that will will require you to take a couple of undergrad courses and pass them with B or higher.

That being said - if you still prefer to go the no degree route you're going to have somewhat of a tough time with interviews even though you may perform the job well itself. Most software engineering interviews revolve around things like how a hash map works and properties of binary trees - information you aren't usually going to get from the "build your own iphone app" type books. So I would recommend:

• Read a book on data structures, in either Java or C++, and really understand Big O complexity analysis and be able to pick the right data structures/algorithms in common situations
  
• Read this book. You don't have to understand it completely the first time through; but re-read every few years and come back to it as you gain experience.
  
• Design your own web site which uses a database, user authentication, and looks nice on mobile browsers. Read through Google's SEO guide and optimize your site for search engines. Automate the deployment of your site. Write test for your site. Basically, treat your site like people used to treat the rusty Corvette in the back of the garage. Constantly take it apart and put it back together, making it slightly better with every iteration. Even when you get a day job keep working on the site in your spare time. If you do all of the programming and design work yourself, you can run a small site for free (Heroku has a decent free service tier).
  
  Good luck!

I've taught a lot of people how computers work, or more precisely how to program them. I am sure you can learn too.

First, let's make it fun.

There is a lot of material for people who like the Raspberry Pi out there that is fun and simple. You don't even need to own a Raspberry Pi to understand what they're talking about.

It's fun and simple because it's designed for youngsters who find long/complex books a bit too boring. I think you might enjoy it, because you've said you've found the books you've tried too boring.

Here is a load of magazines about the Pi - on each issue you can click on "Get Issue" and then under the cover "download the PDF" and read it and see if you enjoy that.

Next, have a play with Scratch. It's designed for kids but the exact same concepts are in professional programming languages.

The reason I recommend it is not because I think you are a child, but because it's a lot of fun and makes a lot of the dull and boring bits of programming go away so you can focus on the fun bits.

You have to remember all the things going on inside a computer are basically the things going on in there - just a lot more complex.

If you ever want to learn a programming language that professional developers use, I think you'll like Ruby.

It's very forgiving for new developers, but still lets you do what we would call "production grade" code. It's what I work in most days.

Also, why's poignant guide is quite funny, but you might find it a bit weird and confusing - I know I did the first time I read it. :-)

I also recommend this book to you: Code by Charles Petzoid. The first few chapters don't seem like they're about computers, because they talk about flags and electrical circuits - that's because you need to understand those things first.

If you can read and understand the whole thing you will know more about how computers work than half of the professional software engineers out there. And they're normally quite a clever bunch.

If you find it too difficult, slow down and think. Each paragraph has something in it worth thinking about and letting it mull over in your mind.

IQ is not a measure of how much you can learn, but perhaps how quickly it can see patterns and understand things.

You having a lower IQ than somebody else does not mean you can't see those patterns or understand things, it just means it might take you a little more thinking to get there. I'm sure you will.

If you ever have any questions about computers, I'd love to try and help answer them - feel free to ask me.

There was a book I read 40 years ago that covered basically everything from vacuum tubes and semiconductors up to basically chips. It was in the library, and it was like 800 pages long. I asked on reddit if anyone knew what it was, and someone pointed me at the newest edition. But I don't really have time to go through all my comment history looking for "electronics book" or to write a program to do same, but you should feel free to do so. :-) Then I got into assembly for the 8-bit CPUs, picked up the 16-bit and 32-bit CPUs of the day, and the mainframe stuff. Then I went back to school. :-)

However, all that said, this looks like what I read, and the intro sounds like he's describing the first edition I remember: https://smile.amazon.com/Electronic-Devices-Circuit-Theory-11e-ebook/dp/B01LY6238B/ref=mt_kindle

If you want more about assembler, just flipping through this seems like it starts with the very fundamentals and goes through a fair amount. https://smile.amazon.com/Code-Language-Computer-Hardware-Software/dp/0735611319/ref=sr_1_5 If you already know how to program, and you understand the basics of how (for example) basic assembler language works and how the chip accesses memory and what an interrupt does and etc, then learning new assembler languages is pretty straightforward. Sort of like "I know Java, now I need to learn C#."

But honestly, at this point, I'd look online. When I learned all this stuff, textbooks were the way to go. Nowadays, everything moves so fast that you're probably better off finding a decent description online, or looking up an online class or something and seeing what texts they use.

If you don't want to learn assembler or hardware, but you still want to challenge yourself, the other thing to look into is unusual programming languages and operating systems. Things that are unlike what people now use for doing business programming. Languages like APL (or "J"), or Hermes, or Rust, or Erlang, or Smalltalk, or even Lisp or Forth if you've been steeped in OOP for too long. Operating systems like Eros or Amoeba or Singularity. Everything stretches your mind, everything gives you tools you can use in even the most mundane situations, and everything wonderful and wild helps you accept that what you're doing now is tedious and mundane but that's where you're at for the moment. :-) (Or, as I often exclaim at work, "My kingdom for a Java list comprehension!")

Books are still the best way to learn C++! C++ Primer, 5th Ed. covers all the basics of C++11 from functions and standard library usage to OOP and templates. Effective C++ reinforces good practices and idiomatic C++ that, despite being written for C++98, is just as relevent today as it was then, some of its contents even more so than ever before. Then Effective Modern C++ then does the same for C++11 and C++14 features, building on top of what C++ Primer covers about C++11 and introducing the subtle changes brought about by C++14. This is my primary recommendation for learning modern C++ from the ground up.

But we live in the internet age! Best make use of it! So many wonderful talks from conferences such as CppCon, C++Now, Meeting C++, ACCU and Code::Dive are all available for public viewing. With regards to modern C++, Herb Sutter's CppCon 2014 Back to the Basics! Essentials of Modern C++ Style and CppCon 2016 Leak-Freedom in C++... By Default are great videos to watch. For more specific topics, here is a list of videos that I've seen and personally found engaging, educational, and worth my time to watch (multiple times!):

• The Exception Situation for exception handling,
  
• rand() Considered Harmful and What C++ Programmers Need to Know about Header <random> for random number generation,
  
• Everything You Ever Wanted to Know About Move Semantic (and then some) for move semantics (by one of the authors of the proposal that introduced it!),
  
• Modern Template Metaprogramming: A Compendium for template metaprogramming,
  
• Lambdas from First Principles: A Whirlwind Tour of C++ for lambda expressions (this one is very good!), and
  
• Type Deduction and Why You Care for auto and decltype(auto) (I miss Scott :'( ).
  
  There are also shows such as CppChat and CppCast where interesting events, projects, papers, and people related to C++ are brought up and discussed. There are so many interesting blogs to read!
  
  And there is always people on IRC (##c++, ##c++-basic, and ##c++-general) and the Cpplang Slack Channel for live updates, discussions, debates, questions, answers, and/or just plain fun with a group of people that ranges from complete noobs who are learning the basics, to committee members and library authors whose names are known across the community. If you ever have a question or need help, these are the places to go and ask (/r/cpp_questions is nice too! :P ).
  
  And finally, links to videos, blog posts, articles, papers, interesting Stack Overflow questions, almost everything mentioned above is constantly being shared at isocpp.org and on /r/cpp. Subscribe to both to get a constant stream of links to anything and everything about C++.
  
  Edit: as for C++17 material, the standard is not technically completed/published yet, but that hasn't stopped the community from creating material about it! This paper lists all the changes from C++14 to C++17, with links to relevant papers, and this Git repo provides a simple "then, and now" comparisons of the major changes to the language. Talks describing the changes in breadth and in depth have been given at conferences, and blog posts have been written for a more textual description of the changes. C++17 is not a major update like C++11 was to C++98, but full of fixes, conveniences, more language flexibility and utility, and new toys to play with! If you have a solid foundation in C++11, C++14 and in turn C++17 should be relatively easy to pick up compared to the shift from classic (C++98) to modern C++.
  
  TL;DR Learn C++11 the best you can. Once you are comfortable with C++11, the transition to C++14 will feel natural, and C++17 will be waiting just around the corner.

I'm assuming you're looking for things geared toward a layman audience, and not textbooks. Here's a few of my personal favorites:

Sagan

Cosmos: You probably know what this is. If not, it is at once a history of science, an overview of the major paradigms of scientific investigation (with some considerable detail), and a discussion of the role of science in the development of human society and the role of humanity in the larger cosmos.

Pale Blue Dot: Similar themes, but with a more specifically astronomical focus.


Dawkins

The Greatest Show on Earth: Dawkins steers (mostly) clear of religious talk here, and sticks to what he really does best: lays out the ideas behind evolution in a manner that is easily digestible, but also highly detailed with a plethora of real-world evidence, and convincing to anyone with even a modicum of willingness to listen.


Hofstadter

Godel, Escher, Bach: An Eternal Golden Braid: It seems like I find myself recommending this book at least once a month, but it really does deserve it. It not only lays out an excruciatingly complex argument (Godel's Incompleteness Theorem) in as accessible a way as can be imagined, and explores its consequences in mathematics, computer science, and neuroscience, but is also probably the most entertainingly and clearly written work of non-fiction I've ever encountered.


Feynman

The Feynman Lectures on Physics: It's everything. Probably the most detailed discussion of physics concepts that you'll find on this list.

Burke

Connections: Not exactly what you were asking for, but I love it, so you might too. James Burke traces the history of a dozen or so modern inventions, from ancient times all the way up to the present. Focuses on the unpredictability of technological advancement, and how new developments in one area often unlock advancements in a seemingly separate discipline. There is also a documentary series that goes along with it, which I'd probably recommend over the book. James Burke is a tremendously charismatic narrator and it's one of the best few documentary series I've ever watched. It's available semi-officially on Youtube.

Here is a "curriculum" of sorts I would suggest, as it's fairly close to how I learned:

1. Programming. Definitely learn "C" first as all of the Exploitation and Assembly courses below assume you know C: The bible is pretty much Dennis Richie and Kernighan's "The C Programming Language", and here is the .pdf (this book is from 1988, I don't think anyone would mind). I actually prefer Kochan's book "Programming in C" which is very beginner freindly and was written in 2004 rather than 1988 making the language a little more "up to date" and accessible. There are plenty of "C Programming" tutorials on YouTube that you can use in conjunction with either of the aforementioned books as well. After learning C than you can try out some other languages. I personally suggest Python as it is very beginner friendly and is well documented. Ruby isn't a bad choice either.
   
   
2. Architecture and Computer basics:
   Generally you'll probably want to look into IA-32 and the best starting point is the Intel Architecture manual itself, the .pdf can be found here (pdf link).
   Because of the depth of that .pdf I would suggest using it mainly as a reference guide while studying "Computer Systems: A Programmers Perspective" and "Secrets of Reverse Engineering".
   
   
3. Operating Systems: Choose which you want to dig into: Linux or Windows, and put the effort into one of them, you can come back to the other later. I would probably suggest Linux unless you are planning on specializing in Malware Analysis, in which case I would suggest Windows. Linux: No Starch's "How Linux Works" is a great beginner resource as is their "Linux Command Line" book. I would also check out "Understanding the Linux Kernel" (that's a .pdf link). For Windows you can follow the Windows Programming wiki here or you can buy the book "Windows System Programming". The Windows Internals books are generally highly regarded, I didn't learn from them I use them more as a reference so I an't really speak to how well they would teach a "beginner".
   
   
4. Assembly: You can't do much better than OpenSecurityTraining's "Introductory Intel x86: Architecture, Assembly, Applications, & Alliteration" class lectures from Xeno Kovah, found here. The book "Secrets of Reverse Engineering" has a very beginner friendly introduction to Assembly as does "Hacking: The Art of Exploitation".
   
   
5. Exploitation: OpenSecurityTraining also has a great video series for Introduction to Exploits. "Hacking: The Art of Exploitation" is a really, really good book that is completely self-contained and will walk you through the basics of assembly. The author does introduce you to C and some basic principles of Linux but I would definitely suggest learning the basics of C and Linux command line first as his teaching style is pretty "hard and fast".
   
   
6. Specialized fields such as Cryptology and Malware Analysis.
   
   
   Of course if you just want to do "pentesting/vuln assessment" in which you rely more on toolsets (for example, Nmap>Nessus>Metasploit) structured around a methodology/framework than you may want to look into one of the PACKT books on Kali or backtrack, get familiar with the tools you will use such as Nmap and Wireshark, and learn basic Networking (a simple CompTIA Networking+ book will be a good enough start). I personally did not go this route nor would I recommend it as it generally shys away from the foundations and seems to me to be settling for becoming comfortable with tools that abstract you from the real "meat" of exploitation and all the things that make NetSec great, fun and challenging in the first place. But everyone is different and it's really more of a personal choice. (By the way, I'm not suggesting this is "lame" or anything, it was just not for me.)
   
   *edited a name out
   
   
   
   
   
   

Hi,
do you want to become a computer scientist or a programmer? That's the question you have to ask yourself. Just recently someone asked about some self-study courses in cs and I compiled a list of courses that focuses on the theoretical basics (roughly the first year of a bachelor class). Maybe it's helpful to you so I'm gonna copy&paste it here for you:



I think before you start you should ask yourself what you want to learn. If you're into programming or want to become a sysadmin you can learn everything you need without taking classes.

If you're interested in the theory of cs, here are a few starting points:

Introduction to Automata Theory, Languages, and Computation

The book you should buy

MIT: Introduction to Algorithms

The book you should buy


Computer Architecture<- The intro alone makes it worth watching!

The book you should buy

Linear Algebra

The book you should buy <-Only scratches on the surface but is a good starting point. Also it's extremely informal for a math book. The MIT-channel offers many more courses and are a great for autodidactic studying.

Everything I've posted requires no or only minimal previous education.
You should think of this as a starting point. Maybe you'll find lessons or books you'll prefer. That's fine! Make your own choices. If you've understood everything in these lessons, you just need to take a programming class (or just learn it by doing), a class on formal logic and some more advanced math classes and you will have developed a good understanding of the basics of cs. The materials I've posted roughly cover the first year of studying cs. I wish I could tell you were you can find some more math/logic books but I'm german and always used german books for math because they usually follow a more formal approach (which isn't necessarily a good thing).
I really recommend learning these thing BEFORE starting to learn the 'useful' parts of CS like sql,xml, design pattern etc.
Another great book that will broaden your understanding is this Bertrand Russell: Introduction to mathematical philosophy
If you've understood the theory, the rest will seam 'logical' and you'll know why some things are the way they are. Your working environment will keep changing and 20 years from now, we will be using different tools and different languages, but the theory won't change. If you've once made the effort to understand the basics, it will be a lot easier for you to switch to the next 'big thing' once you're required to do so.

One more thing: PLEASE, don't become one of those people who need to tell everyone how useless a university is and that they know everything they need just because they've been working with python for a year or two. Of course you won't need 95% of the basics unless you're planning on staying in academia and if you've worked instead of studying, you will have a head start, but if someone is proud of NOT having learned something, that always makes me want to leave this planet, you know...

EDIT: almost forgot about this: use Unix, use Unix, and I can't emphasize this enough: USE UNIX! Building your own linux from scratch is something every computerscientist should have done at least once in his life. It's the only way to really learn how a modern operating system works. Also try to avoid apple/microsoft products, since they're usually closed source and don't give you the chance to learn how they work.

When I started, the most memorable three resources I know I had were the following:

• Bjarne's book - I don't think any C++ developer can truly call themselves even intermediate until they have absorbed at least half the content in the book. I started off with his 3rd edition, which is way less intimidating and shorter, but I subsequently ran through this entire book after it came out. There are no shortcuts on here - you need to read it.
  
• Effective C++ 3rd Edition - I would almost require this one as it prevents any new C++ developer from getting caught in C++ gotchas. You should ideally follow this book up with his 4th edition afterwords. The reason why I recommended the 3rd first is because that book is much more newbie friendly. The 4th edition is targeted towards experienced C++ developers that already have had their feet wet with C++11/14 and want to figure out some best practices. Note the 3rd edition is for C++98 while the 4th is for C++11/14.
  
  After you're done with the two above required books, here are some useful readings:
  
  
• What Every Programmer Should Know About Memory - This is an absolutely essential reading whether or not you've taken any systems courses. It's the foundation of what you will be programming towards (optimizing CPU cache usage).
  
• 1024cores - I believe this guy works/worked at Google at one point, but his site is essential to understanding multi-threaded programming (which is essential in the field). Browse through his site and learn what you can.
  
• Linux Kernel Development - Robert Love (who also works at Google) has probably written the most concise and understandable book on the Linux kernel I've ever read, and I've run through the Daniel Bovet's book and Michael Kirrisk's. For one thing, they're 1,000 and 1,500+ pages, respectively. Secondly, all I've found in those two books that I didn't find in Robert Love's is the implementation details in some areas as well as the details on the scheduler. Robert Love's incredible descriptions on the bottom-half/tasklets were already more than effective for normal understanding. I believe the latter books were more detailed in the networking areas as well, but in that case, you're better off with Understanding Linux Network Internals.
  
  The above readings will probably be a solid 6-12 months to read and absorb assuming you spend a couple hours a day, but I think it'll be well worth it in the long run since this type of stuff sticks with you for a long time. I read the above around 2013, and I can still talk about the CFS/other schedulers, software interrupts, and how the CPU cache works. It'll also make converting to other languages even more of a breeze because you'll know how everything works underneath the hood.

Code is also a good book. If you want textbooks:

This is a good one for computer architecture. And there's a companion course/website at www.nand2tetris.org. https://www.amazon.com/Elements-Computing-Systems-Building-Principles/dp/0262640686/ref=ed_oe_p

I like this one as far as operating systems go: https://www.amazon.com/gp/aw/d/1118063333/ref=dp_ob_neva_mobile

For learning programming, I would check out courses at www.udemy.com. But be mindful of ratings & reviews because the quality of courses can vary pretty drastically. But I've had good experiences there. www.udacity.com also has great courses. They offer paid nanodegrees but you can take every individual course free of charge. www.teamtreehouse.com is another good website

If you're interested in networking, this is a good book for starters: https://www.amazon.com/gp/aw/d/0768685761/ref=dp_ob_neva_mobile

Any A+/Network+ certification books or courses would also be a great way to learn networking and computer hardware

Those are pretty big topics in tech & computer science. There's a ton of stuff to learn. I've been studying this stuff for probably 2-3 years and sometimes I feel like I've barely scratched the surface. Let me know if that helps & if there are other topics you'd want book recommendations on! :)

Hooray, a question I can answer!

One of the problems here is that the question is worded backwards. Binary doesn't combine to give us programming languages. So the answer to your question is somewhat to the contrary: programming languages were invented to ease the tedium of interfacing using binary codes. (Though it was still arguably tedious to work on e.g. punched cards.) Early interfaces to programming machines in binary took the form of "front panels" with switches, where a user would program one or several instructions at a time (depending on the complexity of the machine and the front panel interface), using the switches to signify the actual binary representation for the processor functions they desired to write.

Understanding how this works requires a deeper understanding of processors and computer design. I will only give a very high level overview of this (and others have discussed it briefly), but you can find a much more layperson accessible explanation in the wonderful book Code: The Hidden Language of Hardware and Software. This book explains Boolean logic, logic gates, arithmetic logic units (ALUs) and more, in a very accessible way.

Basically, logic gates can be combined in a number of ways to create different "components" of a computer, but in the field of programming languages, we're really talking about the CPU, which allows us to run code to interface with the other components in the system. Each implementation of a processor has a different set of instructions, known as its machine code. This code, at its most basic level, is a series of "on" or "off" electrical events (in reality, it is not "on" and "off" but high and low voltages). Thus, different combinations of voltages instruct a CPU to do different things, depending on its implementation. This is why some of the earliest computers had switch-interfaces on the front panel: you were directly controlling the flow of electricity into memory, and then telling the processor to start executing those codes by "reading" from the memory.

It's not hard to see how programming like this would be tedious. One could easily write a book to configure a machine to solve a simple problem, and someone reading that book could easily input the code improperly.

So eventually as interfacing with the machine became easier, we got other ways of programming them. What is commonly referred to as "assembly language" or "assembler" is a processor-specific language that contains mnemonics for every binary sequence the processor can execute. In an assembly language, there is a 1:1 correlation between what is coded, and what the processor actually executes. This was far easier than programming with flip-switches (or even by writing the binary code by hand), because it is much easier for a human to remember mnemonics and word-like constructs than it is to associate numbers with these concepts.

Still, programming in assembly languages can be difficult. You have to know a lot about the processor. You need to know what side-effects a particular instruction has. You don't have easy access to constructs like loops. You can't easily work with complex datatypes that are simply explained in other languages -- you are working directly with the processor and the attached memory. So other languages have been invented to make this easier. One of the most famous of these languages, a language called "C," presents a very small core language -- so it is relatively easy to learn -- but allows you to express concepts that are quite tedious to express in assembler. As time has gone on, computers have obviously become much faster, and we've created and embraced many languages that further and further abstract any knowledge about the hardware they are running on. Indeed, many modern languages are not compiled to machine code, but instead are interpreted by a compiled binary.

The trend here tends to be making it easier for people to come into the field and get things done fast. Early programming was hard, tedious. Programming today can be very simple, fun and rewarding. But these languages didn't spring out of binary code: they were developed specifically to avoid it.

TL;DR: People keep inventing programming languages because they think programming certain things in other ones is too hard.

Reading some books would be a good idea.

• Superintelligence: Paths, Dangers, Strategies by Nick Bostrom is a good introduction to some philosophy and general tech behind AI. It's really a lovely read.
  
  The following are textbooks:
  
  General AI
  
  
• Artificial Intelligence: A Modern Approach by Russell and Norvig is a conical book on AI. It has an AMAZING companion site ran by UC Berkeley
  
  
• Artifical Intelligence for Humans by Heaton has some overlap with Artificial Intelligence: A Modern Approach, but is also a good overview
  
  Machine Learning
  
  
• Deep Learning by Goodfellow, Bengio, and Courville is a great book on deep learning
  
  
• Introduction to the Math of Neural Networks by Heaton is a great book on the math behind neural networks
  
  
• Make Your Own Neural Network by Rashid is a good guide to making your own neural network
  
  
• Reinforcement Learning: An Introduction by Sutton and Barto
  
  Statistics for Machine Learning
  
  
• Machine Learning: A Probabilistic Perspective by Murphy
  
  
• The Elements of Statistical Learning by Hastie, Tibshirani, and Friedman
  
  There are many other topics within AI which none of these books focus on, such as Natural Language Processing, Computer Vision, AI Alignment/Control/Ethics, and Philosophy of AI. libgen.io may be of great help to you.

That's one of my favorite popular science books, so it's wonderful to hear you're getting so much out of it. It really is a fascinating topic, and it's sad that so many Christians close themselves off to it solely to protect their religious beliefs (though as you discovered, it's good for those religious beliefs that they do).

As a companion to the book you might enjoy the Stated Clearly series of videos, which break down evolution very simply (and they're made by an ex-Christian whose education about evolution was part of his reason for leaving the religion). You might also like Coyne's blog, though these days it's more about his personal views than it is about evolution (but some searching on the site will bring up interesting things he's written on a whole host of religious topics from Adam and Eve to "ground of being" theology). He does also have another book you might like (Faith Versus Fact: Why Science and Religion are Incompatible), though I only read part of it since I was familiar with much of it from his blog.

> If you guys have any other book recommendations along these lines, I'm all ears!

You should definitely read The Selfish Gene by Richard Dawkins, if only because it's a classic (and widely misrepresented/misunderstood). A little farther afield, one of my favorite popular science books of all time is The Language Instinct by Steven Pinker, which looks at human language as an evolved ability. Pinker's primary area of academic expertise is child language acquisition, so he's the most in his element in that book.

If you're interested in neuroscience and the brain you could read How the Mind Works (also by Pinker) or The Tell-Tale Brain by V. S. Ramachandran, both of which are wide-ranging and accessibly written. I'd also recommend Thinking, Fast and Slow by psychologist Daniel Kahneman. Evolution gets a lot of attention in ex-Christian circles, but books like these are highly underrated as antidotes to Christian indoctrination -- nothing cures magical thinking about the "soul", consciousness and so on as much as learning how the brain and the mind actually work.

If you're interested in more general/philosophical works that touch on similar themes, Douglas R. Hofstadter's Gödel, Escher, Bach made a huge impression on me (years ago). You might also like The Mind's I by Hofstadter and Daniel Dennett, which is a collection of philosophical essays along with commentaries. Books like these will get you thinking about the true mysteries of life, the universe and everything -- the kind of mysteries that have such sterile and unsatisfying "answers" within Christianity and other mythologies.

Don't worry about the past -- just be happy you're learning about all of this now. You've got plenty of life ahead of you to make up for any lost time. Have fun!

There are a ton of books, but i guess the main question is: what are you interested in? Concepts or examples? Because many strong conceptual books are using examples from java, c++ and other languages, very few of them use php as example. If you have the ability to comprehend other languages, then:

http://www.amazon.com/Design-Patterns-Elements-Reusable-Object-Oriented/dp/0201633612/ref=sr_1_1?ie=UTF8&qid=1322476598&sr=8-1 definetly a must read. Beware not to memorize it, it is more like a dictionary. It should be pretty easy to read, a little harder to comprehend and you need to work with the patterns presented in that book.

http://www.amazon.com/PHP-5-Objects-Patterns-Practice/dp/1590593804 - has already been mentioned, is related directly to the above mentioned one, so should be easier to grasp.

http://www.amazon.com/Patterns-Enterprise-Application-Architecture-Martin/dp/0321127420/ref=sr_1_1?ie=UTF8&qid=1322476712&sr=8-1 - one of the most amazing books i have read some time ago. Needs alot of time and good prior knowledge.

http://www.amazon.com/Refactoring-Improving-Design-Existing-Code/dp/0201485672/ref=sr_1_4?ie=UTF8&qid=1322476712&sr=8-4 - another interesting read, unfortunatelly i cannot give details because i haven't had the time to read it all.

Here's pretty much your most basic flow for problem 3:

1. Find the square root of your target number.
   
2. Starting at 2, check if target % loop counter == 0
   
3. If yes, store as a factor and divide your current target by that number. Use that as the new for loop end condition. Find the complement of that factor, and store that as well.
   
4. Go through all the divisors you found and test if they are prime.
   
5. The largest remaining number should be your solution.
   
   To troubleshoot, use a debugger (Eclipse's builtin is nice). If you feel it's taking too long, break the program's execution and check its state. Is the loop counter about where it should be? Are the found divisors plausible? Is the loop end target plausible? Set a breakpoint on the first line inside the loop and keep stepping through (either one line at a time if you like, or just hit 'resume' and it will break again at the top of the next loop iteration).
   
   I learned Java throughout college, as it was the primary teaching language. Honestly, the best way to learn is just to WRITE CODE. Solve problems that you don't know how to solve. Invent random things that are useful to you. Your code doesn't have to be perfect when you're learning (and it definitely won't be!), and what is important is that you constantly look for ways to improve. I want you to look back on code you've written a year ago, and think that it's absolute crap - that will show that you are learning and improving.
   
   Somewhat counter-intuitively, the best resources are books! I'll list some recommendations below.
   
   Keep these principles in mind:
   
   
6. Don't repeat yourself. If you're copying and pasting code, it is wrong. If there is not a single point of truth for each piece of information in your code, it is wrong. Find ways to keep your code clean and non-repetitive.
   
   
7. Document everything. Comments - comments everywhere. Explain what ever piece of your code does. Explain what each method's arguments are, what it does, and what it returns. If you don't know, then that's a big red flag to reevaluate your design. If a bit of code is doing something complicated, write inline comments explaining what each bit does. All this is for future you - I can hardly remember code I wrote last week, let alone a year ago.
   
   
8. Separation of concerns. Each piece of code should only work with what it is directly responsible for. UI code should deal with presentation. Application logic should deal with data manipulation. A persistence layer should handle any database or serialization of things. Keep your code loosely coupled!
   
   
9. Design patterns. There are dozens of semi-formal patterns used to solve common problems in software. Learn to recognize these problems, when to apply these patterns, and how to modify them to suit your goals. See Wikipedia, or Design Patterns by the Gang of Four.
   
   
10. Be pragmatic. What does your code really need to do? What is the minimum that it needs to accomplish, and how can you keep it extensible enough for future expansion? The answer to the last part is largely the previous points - well designed code is always easily changeable. The Pragmatic Programmer is another excellent book. It even comes with a handy summary sheet of its main points!
    
    
11. TEST! Write lots of unit tests. Make sure that every piece of your program is tested to be correct. Every time you find a bug, write a test for it so it never happens again. If a piece is difficult to test, it may mean that it is poorly designed - reevaluate it. This is guaranteed to save your bacon at some point - you'll probably hate the work, but the safety net is invaluable. Being able to instantly tell if you program is working properly is invaluable when making changes.
    
    Once you start getting a feel for Java, which I think you might be already, Effective Java is the book. You probably won't need any other resource for Java itself.
    
    If you need help with something, Reddit is a great place, but Stack Overflow is the programmer's mecca. The best resource on the web for just about everything software, and their sister sites cover other topics, from IT/sysadmin to gaming.

Obviously the biggest gripe with Magento is obviously, Speed.

That said I recall Alan Storm mentioning performance was not a target during initial development, flexibility and developer friendliness would be a key to market penetration as it is obviously what helped make it as popular as it is.

Fast forward and now we all are having to deal with this initial uncaring for performance. We install layers upon layers of caching and indexing to squeeze as much out of it as we can.

Personally I find Magento overly architected. It feels like Spaghetti code at times, except its just a big massive plate of lasagna now. Everything has to go through hundreds of layers to build out a simple request.

With that said.

Wrong:

• Documentation sucks = Learn to read code
  
• ORM = Learn SQL! (a DBA will thank you later)
  
• EAV = Flatten the tables to many smaller tables
  
• XML = Use associative Arrays (its native and loads quickly, and will throw errors upon un-initialization)
  
• Email templates = Surely there is a better way?!
  
• API = Nothing but wrappers around Models (which is why its still so damn slow)
  
• Autoloading = Who ever thought scanning a hard disk for X number of dirs for one file must seek therapy. (yes I know theres class maps now and opcode cache like APC) Fun fact lib/ is scanned as well. so thats 4 code pools in total.
  
• Upgrading large data will just not happen due to upgrade scripts with numerous ALTER TABLE commands instead of grouped causing large MySQL table disk copies and scan.
  
• Data flow (even with the latest version still just plain sucks, thankfully theres Magmi and uRapidFlow)
  
• Cron (do we really need another Cron inside of Magento itself?)
  
• A better Magento connect similar to how Wordpress works would be nice.
  
• Ebay/Paypal ;)
  
  Right:
  
  
• Observers (as much as I hate using design pattern buzzwords!)
  
• PHP as phtml (no template language overhead. learn PHP frontend devs!)
  
• Factories (see observers comment)
  
• Singletons (see observers comment)
  
• Adminhtml_Grid
  
• Multi-Site/Store
  
• Layouts per product/site/store
  
• Theme and code pool fall backs
  
• Shopping Cart Rules
  
  What I'm NOT looking forward to in Magento2:
  
  
• EAV is sticking around (but maybe can be disabled?)
  
• TDD/Unit Tests (Yes, I don't see the point in TDD, and hard to convince otherwise)
  
• Twig
  
• WYSIWYG editors
  
• More layers on the already tall lasagna stack.
  
  After using Magento since version .6b using (X-Cart years before) I've slowly come to the realization that the majority of implementations seem to come from the Java world.
  
  http://i.qkme.me/3u7vuq.jpg
  
  I don't know if its the fact that instead of teaching Basica or even C isn't part of the curriculum at universities anymore and they just drop you into Java but I wish people would take more time to figure out the basic principles FIRST before saying Java, PHP, C, etc is better. They all have their +/-'s. But understanding the principles layers generally helps you understand how your PHP code is working inside the machine. I don't think this is taught anymore or no one cares. I'd suggest http://www.amazon.com/Elements-Computing-Systems-Building-Principles/dp/0262640686 to pickup for a good read for those that don't.
  
  With that said anyone who thinks they can rebuild a better Magento from scratch, I will salute you, me I realize such a task would require years to achieve, by then the train may of already left the station. I know Varien who was a consulting company before Magento, realized the many pitfalls of OSCommerce for their clients. Hence why we have Magento today.
  
  Disclaimer: These are just my opinions, which are a lot like butts we all have one and they all stink. ;)

Nice curated list, but I'd recommend adding a few more interview prep sites from this list:

The 10 most popular coding challenge websites for 2017

Because I would definitely recommend someone to check out TopCoder, Coderbyte, and Codewars if they are preparing for an interview.

Here are a few resources I've also used when preparing for interviews (taken from previous comments of mine):

• Read the Algorithm Design Manual.
  
  
• Go through some of the challenges on this interactive python algorithms website.
  
  
• Practice coding simple and then more advanced algorithms on sites like Coderbyte (my site) and HackerRank which provide good explanations and solutions as well. Here's a list of popular coding challenge websites in 2017.
  
  
• Read as many algorithm explanations and code examples as you can on GeeksforGeeks.
  
  
• Try and implement basic algorithms yourself like: shortest path, minimum spanning tree, DFS + BFS, tree traversals, different sorting algs, min/max heap, etc. and learn about their running times (big-o).
  
  
• Look at some interview questions posted on careercup and try and understand how other users solved the questions. Like this example.
  
  
• Aside from coding challenge sites, try and solve common coding interview questions you find online such as this list.

I haven't read it, but it looks pretty good. I can personally vouch for this book however:

https://www.amazon.com/Code-Language-Computer-Hardware-Software/dp/0735611319/ref=pd_sim_14_2?_encoding=UTF8&psc=1&refRID=C8KMCKES83EHGXS3VWSQ

It's truly amazing. I'm currently an EE PhD student but I had a pretty limited background in digital hardware and computer architecture, and I read most of this book just out of interest a little while ago and frankly learned quite a bit. It's written at a very readable level for anyone with almost no prior knowledge, yet gets technical when it needs to. It's very thorough, but approaches the topics at a wonderful and easy pace with very clear explanations. The author even says you can skip some of the more technical details if they're not of interest to you, and you'll still end up learning quite a lot. The book you posted looks pretty similar, so I'd say it's worth a shot.

The amount of planning you have to do scales with the complexity of the project.

Professors drill the importance of planning, documentation and unit testing into students because it is extremely important and once you start your career if you're a poor planner it's going to come back to haunt you.

However, when you're working on a simple project that's not intended for public release you don't have to go overboard with docs unless you just want to practice.

My own process usually starts with me jotting down an idea; I find that writing it out helps me to get a better grasp on the overall feasibility.

Once I'm satisfied that I actually have something I can implement I'll diagram the flow of the application, and maybe do some wire-frames.

I usually find that this is enough of a launching pad for a simple personal project.

Professional projects are a different ballgame, because as I said, the amount of planning you have to do scales with the complexity and size of the project. It's in the professional environment that all of the things your professors are teaching you will become really important.

So, to answer what I think was your question,

>So how does one end up with 20 classes connected with each other perfectly and a build file that set everything up working flawlessly with unit test methods that check every aspect of the application?


This comes about more in the implementation phase than the planning phase. I've heard it said that in war "no plan survives contact with the enemy" and you'll find this to be true in software development as well. Even when you plan really well you'll sometimes have to go back to the drawing board and come up with a new plan, but that's just part of the process.

Some books that I recommend on the topic are Hackers and Painters - Paul Grahm and I think every software dev should have a copy of Design Patterns

The former is a collection of essays that might give you some useful perspective on the process of writing software.

The latter is more of a reference book, but it's helpful to become familiar with the patterns covered in the book so that you don't find yourself re-inventing the wheel every time you begin a new project.


As for the other part of your question (apologies for addressing them out of order)

>My new "bottleneck" writing code is the structure. I end up having huge classes with way to many public methods. I might as well just write a script with everything in one file. Almost anyway.. I try to write OO, but I often get lazy and just end up with not very elegant systems I would say.

Don't be lazy, because as you're already seeing, it comes back to bite you in the ass.

As you're writing your code you have to be mindful of the complexity of the project as it grows around you, and you have to periodically take a step back and look at what you've created, and re-organize it. This kind of goes back to what I was saying earlier about no plan surviving enemy contact.

So when you find yourself creating a new class that you hadn't thought about, be mindful of where you put it.

Should you create a new file (yes, of course you should), new folder?

Do you have a bunch of similar classes doing the same thing? Should they inherit from one another?

Be especially mindful of copy and pasting from one are of your code to another, generally speaking if you're doing this you should probably be writing a function, or using inheritance.

It's up to you as the developer to make sure your project is organized, and now-a-days it's really easy to learn how to best organize code by looking through other peoples projects on github, so there's really no excuse for it.

Hope that helps, good luck.

I recommend reading: The User Illusion by Tor Norretranders, Gödel, Escher, Bach by Douglas R. Hofstadter, and I Am a Strange Loop also by Douglas R. Hofstadter for some interesting reading on the subject (Warning: Gödel, Escher, Bach isn't for everyone- it's a bit strange, but I love it). I read a lot of books on science in general and, based on that, it seems like many believe consciousness and also free will is just an illusion. In fact, just a few days ago, physicist Brian Greene sorta-kinda said as much in his AMA - granted, he's talking specifically about free will and not consciousness per se, but I think the two must be very related.

I, too, believe in God and also have a very strong belief in and enthusiasm for science, so this is an especially fascinating question for me.

BTW: if you're interested in the way the brain works in general, I highly recommend How the Mind Works by Steven Pinker.

Sometimes depression isn't about circumstances or perspective, it's entirely chemical.

I've thought of the answers to these questions hundreds of times. But the thing about depression is that sometimes it makes it impossible to find a happy answer.

Here are my thoughts:

1. I have a goal. I'm going to school for Computer Science and Philosophy. I'm hoping to go into AI research. I want to improve the world through new discoveries. That's not my reason to live, though. The only reason I'm alive is because I don't want to hurt the people who love me. I only feel more awful when I think of the wasted potential that my death would cause, which makes me feel even more depressed. Having a goal and dreams does little to curb my depression, and only increases my anxiety.
   
   
2. I'm doing absolutely everything I can to get better. I'm taking my meds, I'm going through therapy, I'm doing everything I'm supposed to do. I think every person deserves to be happy, including me. Happiness is just much, much, harder for some to achieve than other. It's frustrating when so much work doesn't get you very far.
   
   
3. I am connected to everything around me, I am a part of this universe. Even when my consciousness ceases, I (well, maybe not "I") will continue to impact everything around whether through ideas or the physical decomposition of my body. I think I contribute a lot even while alive, and the world has so much to offer. I just lack the capacity to enjoy so much of it.
   
   
   I'll try to keep the philosophical bit short, because I could really lose myself in a rant otherwise :p
   
   I think that an existentialist philosophy can have a lot to offer on a human level. In a way, everything is functionally meaningless, in the sense that so much meaning is beyond our understanding. However, I think that rather than a complete lack of meaning in the universe, meaning is an inherent part of the universe.
   
   To quote Hofstadter (taken from P-6 of Godel, Escher, Bach:
   >Shouldn't meanings that one choooses to read into strings of meaningless symbols be totally without consequence?
   
   
   >Something very strange thus emerges from the Godelian loop: the revelation of the causal power of meaning in a rule-bound but meaning-free universe.
   
   Basically, by the way that matter is related to other matter, meaning emerges from even the tiniest connection. And that meaning can push matter around in the same way that matter can cause meaning. Ideas are not only meaningful, they have causative power. I think that's pretty cool!
   
   So basically, I agree that humans may have insignificance on some scale. But in the grand scheme of things, there is something so much more magnificent that we are a part of.
   
   Anyway...while I appreciate your thoughts and respect your desire to help others, I think that you are a bit misinformed. That's okay! It's nearly impossible for someone who hasn't experienced depression to know what it's like. But there are ways to better understand and help. Here is a great resource from /r/SuicideWatch that shares some ways that you can connect with depressed or suicidal people. I think it may help a lot!
   
   Oh, and sorry for what turned out to be a philosophical rant anyways; I just can't resist invoking Hofstadter and isomorphism in the face of existentialism :p

"I craved for games that had easy achievements so I could feel good again."

+1

The industry gamifies games to make you want to play them regardless of their quality. It's not even a "I want to finish a hard game" or "I want to complete a hard game". You just want the 100% completion/platinum trophy and we will be inclined to choose the easy way to the reward.

I've been reading about dopamine and its behavioral effects. Apparently it doesn't only moderate reward but also motivation. Check my comment posted today for explanatory links.

You essentially opted in for easy reward over hard, it's like opting to avoid going to the gym or improve your social skills in favor of playing video games and indulge to pornography. Another good book is the shallows: what the internet is doing to our brains where the author argues that the medium (how we choose to convey a message) can affect us more than the information.

Because another thing that gives us quick fixes is the novelty of browsing Reddit for funny things, and the warmth of social approval that we get from getting one of our comments/posts upvoted.

One book that i didnt see mentioned in a casual skim of the posts is Off to be the Wizard
https://www.amazon.co.uk/Off-Be-Wizard-Magic-2-0/dp/1612184715

A very silly series where a modern day guy ends up in an alternate dimension where he can do magic/control the world via programming. Super light reads, fun and funny, and pulls in your computer interest. If you enjoy the first one, you can pick up the others.

If you want something a bit meatier, check out some Douglas Hofstadter.

Le Ton Beau de Marot (it's in English) is about the process and problems of translating languages, and makes surprisingly good bathroom reading because the chapters are short. He starts the scope small, talking about whether to focus on literal meaning or the spirit of the words, and then brings in more concepts like artificial constraints (poetry, or even writing without certain letters, for one example). It is philosophical, informative, and amusing. https://www.amazon.co.uk/dp/B012HVQ1R0/ref=cm_sw_r_cp_awdb_L2sgAbDYFK1XK

He also wrote Godel Escher Bach: an Eternal Golden Braid. https://www.amazon.co.uk/dp/0465026567/ref=cm_sw_r_cp_awdb_b3sgAbQ79TTGS better writers than I have written reviews (this one is from Amazon)

>Twenty years after it topped the bestseller charts, Douglas R Hofstadter's Gödel, Escher, Bach: An Eternal Golden Braid is still something of a marvel. Besides being a profound and entertaining meditation on human thought and creativity, this book looks at the surprising points of contact between the music of Bach, the artwork of Escher, and the mathematics of Gödel. It also looks at the prospects for computers and artificial intelligence (AI) for mimicking human thought. For the general reader and the computer techie alike, this book still sets a standard for thinking about the future of computers and their relation to the way we think.

>I want to make more applications...but I don't have any ideas..is there any reading you would recommend me to do?


Have you read Head First Java?

Head First Design Patterns?

The pragmatic programmer?



>I want to be employable...after 3 years doing a computer science course, I feel like I still only know the basics. What Java books do you value most and feel helped you become a much better programmer?


In my particular case, I didn't read books. My interest has been developing web applications, so I have gotten more information from frameworks' documentation an tutorials than from books.


>What are some examples of programs you made when you were 1 or 2 years into your Java programming career?


Hmm... I created some plugins to check on the availability of some servers and services. When it detected those were unavailable, it sent email and SMS alerts to our system administrators. Things got interesting when the email server was down tho.

>What resources would you recommend me reading to understand how to make my android applications able to access the internet..so that users can compare high scores and achievements?


>I have the drive. I love programming and I want to be a successful one. What advice can you give me?


Code as much as you can. Check what kind of applications you want to develop and find which frameworks can help you build them. You don't need to re invent the wheel (unless necessary). Follow the developer's guide and check if there are any tutorials that you can use to improve your knowledge and make better applications in the better way possible.


>Thank you for your help. I really appreciate it. I've felt stuck for days and i honestly did browse a lot before I came here. I've seen a lot of Java developer jobs paying £20-40k but i feel i don't have the relevant experience to even apply to them yet. I feel like i know very little..I.e I have no idea what J2EE is and what it's used for.


From wiki:
"Java Platform, Enterprise Edition or Java EE is Oracle's enterprise Java computing platform. The platform provides an API and runtime environment for developing and running enterprise software, including network and web services, and other large-scale, multi-tiered, scalable, reliable, and secure network applications. Java EE extends the Java Platform, Standard Edition (Java SE)[1], providing an API for object-relational mapping, distributed and multi-tier architectures, and web services. The platform incorporates a design based largely on modular components running on an application server. Software for Java EE is primarily developed in the Java programming language and uses XML for configuration."


If you want to build enterprise web-enabled applications, this is what you should start reading:
J2EE 6 Tutorial
And I always recommend these as well, they helped me a lot when I was learning Java Server Faces:


http://balusc.blogspot.mx/

http://www.mkyong.com/ (He has an Android tutorial that might help with with your interest to develop applications for that OS)

http://www.coreservlets.com/

I think this might be beyond what you're looking for, but I really enjoyed Pattern Recognition and Machine Learning. It's very heavy on statistics, and if you're looking into machine learning methods, it has a wonderful amount of mathematical information given in a fairly clear manner. It might be severe overkill if this isn't your field, but I thought I'd mention it since you said AI.

For AI in general, I see Artificial Intelligence: A Modern Approach used a lot. It gives some solid basic concepts, and will be helpful in getting you started writing basic AI in your applications.

I can't really recommend discrete math because, despite enjoying it quite a bit, I haven't found a textbook that I like enough to endorse. My textbook for it in college was by Rosen, and I despised it.

edit:
Just double checked it, and I would stay far away from the first recommendation unless you have a very extensive knowledge of sophisticated statistics. I like it because it gives the math that other books gloss over, but it's not good for an introduction to the subject. It's almost like going through a bunch of published papers on some new cutting edge methods. The ever popular Machine Learning by Thomas Mitchell is a much better introduction to machine learning. If you want to obtain the mathematical depth necessary for your own research into the field, go with the other book after you've gotten acquainted with the material. I'll leave my suggestion up anyway in case anyone here might find it interesting.

These are books I actually own and would recommend. Of course there are other great/better books out there, but I'm going to stick with what I've actually bought and read or "read".

I say "read" because several books are NOT meant to be read cover-to-cover. These typically have about 1/3 that you should read like normal, and then skim the rest and know what's in the rest so that you can quickly reference it. These books are no less important, and often even more important. I've marked these kind of books as #ref for "read for reference". Normal books that should be read cover-to-cover are marked #read


For learning your first language: This is really the hardest part and unfortunately I don't have any books here I can vouch for. I started with "C++ for Dummies" and am not including a link because it's bad. Your best bet is probably "Learning <language>" by Oreily. I also love the Oreily pocket books because you can carry them and skim while on the bus or the john, but you can just do the same with your smartphone. Pocket Python, Pocket Java, Pocket C++

Top Recommendations:

Accelerated C++ #read Made for people who already know another language and want to pickup C++. Also great for people who need a refresher on C++. I really like how it doesn't start with OOP but gets you familiar with the imperative parts of C++ before diving into OOP.

The Algorithm Design Manual #ref This is my new favorite book and the first I would send back in time to myself if I could. Each algorithm & data structure is given a mathematical breakdown, pseudocode, implementation in very readable C, a picture (very helpful), and an interesting war story of how it Saved The Day.


Cracking the Coding Interview #read I originally avoided this book like the plague because it represented everything I hate about coding interviews, but many interviewers pull questions straight from this book so this book can equal getting a job. Put that way, it's ROI is insane.

The Pragmatic Programmer #read Must-have for any profressional software engineer that covers best-practices for code and your growth. You can also find the raw tips list here

Head First Design Patterns #read Many prefer the "GoF/Gang of Four" Design Patterns which is more iconic, but Head First is a modern-version using Java to cover actual design patterns used day-to-day by programmers.

For Intermediates:

Effective Java or Effective C++ and Effective Modern C++ #read When you're ready to go deep into one language, these books will give you a huge boost to writing good Java and C++.

Design Patterns #ref You'll want to get this at some point, but early on it's too much for a beginner and many of the patterns are obsolete.

The Art of Computer Programming #ref The programming "bible" but like Design Patterns you should hold off on this iconic book until you've got your basics covered. It would make for a great purchase with your first paycheck or first promotion :)

In my opinion; every book in this bundle is a bag of shit.

Here's a list of reputable books, again in my opinion (All links are Non-Affiliate Links):

Web Hacking:

The Web Hackers Handbook (Link)

Infrastructure:

Network Security Assessment (Link)

Please Note: The examples in the book are dated (even though it's been updated to v3), but this book is the best for learning Infrastructure Testing Methodology.

General:

Hacking: The Art of Exploitation (Link)

Grey Hat Hacking (Link)

Linux:

Hacking Exposed: Linux (I don't have a link to a specific book as there are many editions / revisions for this book. Please read the reviews for the edition you want to purchase)

Metasploit:

I recommend the online course "Metaspliot Unleashed" (Link) as opposed to buying the book (Link).

Nmap:

The man pages. The book (Link) is a great reference and looks great on the bookshelf. The reality is, using Nmap is like baking a cake. There are too many variables involved in running the perfect portscan, every environment is different and as such will require tweaking to run efficiently.

Malware Analysis:

Practical Malware Analysis (Link)

The book is old, but the methodology is rock solid.

Programming / Scripting:

Python: Automate the Boring Stuff (Link)

Hope that helps.

You are on the right track. The most important to understand is the fundamentals of any programming language. You mentioned Java. Java is an object-oriented programming language. In order to write good code in Java, you will need to learn what is an object? What is object-oriented? Like, what is inheritance, polymorphism, classes, interfaces etc etc. Once you learn the concept of OOP and you want to learn Python (another OOP language), it will be that much faster, because you already understand the concepts. Python has its nuances but you learn as you go along. I think you should start with the Head First series by Oreilly. They are sooo good at teaching this sort of stuff. I will give u the links below:

Head First Java

Head First Object-oriented Analysis and Design

Head First Design Patterns

Buy just the one book and start from there. Checkout the Head First series, you may like other books too. Also, google 'design patterns' and read about it. Some people mention Algorithms and that is all great stuff and you will learn as you write good code. There is another book I would recommend:

Pragmatic Programmer



I would also suggest that you should try different types of programming languages as well. Like functional (LISP or Scheme) or procedural (C). When you do that you will start to think differently and it will expand your knowledge. LISP was created in 1958 by John McCarthy. My friend works at Google and he told me that they are using LISP behind Google Maps.

I'll start off with some titles that might not be so apparent:

Unexpected Fundamentals

These 2 books provide much needed information about making reusable patterns and objects. These are life saving things! They are not language dependent. You need to know how to do these patterns, and it shouldn't be too hard to figure out how to implement them in your chosen language.

• Design Patterns: Elements of Reusable Object-Oriented Software
  
  
• Game Programming Paterns
  
   
  
  Good General book
  
  
• Effective C++: 55 Specific Ways to Improve Your Programs and Designs
  
   
  
  This book is great if you're going to make a browser based game
  
  
• HTML5 Canvas Cookbook
  
   
  
  General Knowledge books
  
  
• Pro HTML5 Games (Expert's Voice in Web Development)
  
   
  
  Provide a working moveable 3D model with C++ and DirectX, Very cool.
  
  
• Character Animation With Direct3D
  
   
  
  More general game base building
  
  
• Game Engine Architecture, Second Edition
  
  
• Programming Game AI By Example
  
   
  
  Working product results books, little if any modification needed
  
  Releasing in a couple months (hopefully) 2 Very good books using C++ to develop by.
  
  
• Introduction to 3D Game Programming with DirectX 12
  
  
• Introduction to 3D Game Programming with DirectX 11
  
   
  
  Not presented in the best manner but still noteworthy:
  
  
• DirectX 11.1 Game Programming
  
   
  
  I used to love XNA...but now it's not feasible for commercial development. If you're a beginner to game design...starting out with XNA might actually be useful. It's easy to pickup and put out a working product. XNA is C#
  
   
  
  
• Learning XNA 4.0: Game Development for the PC, Xbox 360, and Windows Phone 7
  
  
• XNA Game Studio 4.0 Programming: Developing for Windows Phone 7 and Xbox 360
  
  
• XNA 4.0 Game Development by Example: Beginners Guide
  
  
• Beginning XNA 3.0 Game Programming: From Novice to Professional (Expert's Voice in XNA)
  
  
• XNA 3.0 Game Programming Recipes: A Problem-Solution Approach (Expert's Voice in XNA)
  
  
• Building XNA 2.0 Games: A Practical Guide for Independent Game Development (Books for Professionals by Professionals)
  
   
  
  Working product books, modification needed to make run on current systems
  
  
  Provides a working FPS game in C++ on DirectX 9. Good for some starting out knowledge for an FPS
  
  
• Programming Mutliplayer FPS Direct X
  
   
  
  Good for 3D Terrain rendering in DX9...however much of this is outdated...some concepts still apply, and it's not the worst idea to see a working example.
  
  
• Real-Time 3D Terrain Engines Using C++ and DirectX9 (Charles River Media Game Development)
  
   
  
  TLDR: Click links starting at top, buy, read, profit

I'm a ~10 year sysadmin that has decided to rebuild my software dev skills that I haven't used since college. Here's what I did to reawaken that part of my brain:

1. Harvard's CS50. I figured an entry level college course would be "beneath me" but it was a great experience and I learned a surprising amount. It's very entertaining as well so that made the "simple" parts fun to do as well.
   
   
2. Read CODE by Charles Petzold. Great insight into the nuts and bolts of how computers work. Read through it on my lunch breaks while taking CS50 in the evenings.
   
   
3. Read and do the problems in C Primer Plus. This is a great book for learning how to write in C, which is the basis for all modern languages and is still widely used today. Great starter book for anyone who wants to learn to program.
   
   3.5) After going through the last chapters of C Primer Plus, I realized that some of my math skills were not up to par, so I took this MOOC from MIT to supplement that. No idea if that's something you need.
   
   
4. Here comes the fun one: The Structure and Interpretation of Computer Programs, aka The Wizard Book. This book is more about how to design software in general, and it is pretty difficult. That being said, if you can get through it then you have the chops to do this professionally.

This is one of those questions that basically yields no useful answers.

• On the how part, it depends. Generally you would analyze your requirements and problem and find out that it fits problems described by one or more design patterns. So you apply these design patterns and modify them as fit until you think you've cover all the basis on a higher level. Now you have a fuzzy picture of the house you want to build and where the general walls and hallways are. You might have kitchen and bedroom marked that you know will be for certain purpose but you don't have anything specific in each room yet(hope the analogy makes sense)
  
  
• Next step will be the more difficult part, which is fine tunning and validating your blueprint. Idk how other people do it, but I prefer to run through each requirements and see how they fit into each "room". This process usually expose ambiguity in the architecture. You want to the repeat the process till it is clear how each requirement will be handled. It's a good idea to also anticipate how the requirements might change or expand in the future when validating your architecture.
  
  
• In the case of Django they basically did most of that for you already. If that's all you work on then I'm not sure what you are asking, you could look into data structures topic if you want better data model designs. Front end is pretty flexible, usually depends on the framework you pick and follow their design style. For server side application that supports your front end would depends on your problem/requirements. Like I said this is one of those questions that yields no useful answers since it's essentially design question and design is very subjective and a broad topic. As far as UML or whatever other tool/diagrams you choose to use, it really doesn't matter as long as it conveys your design clearly and there's no ambiguity.
  
  Not sure if I answered your question. You can checkout topics on design patterns. there's a good book on Amazon for that I think just called design patterns. Or checkout tutorialpoint.Com ? For software architecture.
  
  Design Patterns Book
  
  
  Software Architecture Quick Overview
  
  edit: added resources and changed format

Here are my two big enthusiastic suggestions.

Sign up to Lynda. You get a 10-day free trial, and then it's $30 for a month. Watch Foundations of Programming: Fundamentals (4h 47m), Foundations of Programming: Data Structures (2h 29m), Programming Fundamentals in the Real World (3h 8m), and Python 3 Essential Training (6h 36m).

These are short crash courses, you obviously don't walk away a full-on programmer. But the main instructor Simon Allardice is excellent at explaining the basics and fundamentals in a very clear, natural way. I have taken university courses, I have watched MIT and Harvard courses, I have used a dozen tutorial sites and watched a bunch of lecturers and read three dozen books: the Lynda programs I linked are the best first-intro things I've seen. I strongly recommend that you watch at least the first two.

You might not understand it all, that's fine. Don't worry about what languages he uses for examples, 90% of stuff carries over between languages. If you can absorb a good chunk of that material it'll be a huge boost for you and a nice foundation to start on. You'll walk into your first real class in a better headspace, already knowing the gist of what you're going to flesh out and properly sink your teeth into. And if you find that the Lynda stuff really works well, look up their C and databases courses, since you'll wind up using that stuff too.

My second recommendation is that you buy and read Charles Petzold's wonderful book Code: The Hidden Language of Computer Hardware and Software. This book doesn't focus on a specific programming language, or how to implement programs, or the mathematics, or the theory. Instead it answers "So what is a computer actually doing under there when we program? What's a CPU, exactly, how does it understand words and numbers?" It does this in a very natural, accessible, for-the-layman way, starting with really simple analogies about signal flags and morse code, and before you know it, bam, you understand logic gates and binary arithmetic, and a lot of the mystery and magic of computers has dissolved for you.

If you actually want to learn to implement efficient algorithms and data structure in C++ you might have a long road ahead of you since loads of them are quite complex. If you're interests are purely in machine learning than I would suggest you make use of the containers and algorithms provided by std and boost.

Going more domain specific and using things like armadillo or eigen. The later is used in many popular NN libraries/frameworiks such as tensorflow while the former is (based on my subjective opinion) quit easy to use, more similar to matlab and used in a number of libraries such as dlib and opencv. These "higher" level libraries are likely even better suited for your needs since they may help you use multiple cpus and gpus for your algorithms.

Further more, if you are interested in getting something shipped out quickly check out some C++ ML libraries, my personal favorite is Dlib but its quite limited in scope. However, I assume you wish to implement your own algorithm, in which case you are in luck because most of these libraries are open source:

https://github.com/tensorflow/tensorflow/tree/master/tensorflow
https://github.com/davisking/dlib
https://github.com/opencv/opencv
https://github.com/Somnibyte/MLKit

(are some examples of such libraries).

For familiarizing yourself with C++ I'd recommend:

-> so documentation

-> [Programming: Principles and Practice Using C++](https://www.amazon.com/dp/0321992784/?tag=stackoverfl08-20](https://www.amazon.com/dp/0321992784/?tag=stackoverfl08-20)

-> Effective Modern C++

Stack overflow documentation has plenty of examples that explain things which might otherwise seem strange about the language, Programming: Principles and Practice Using C++ was written by the creator of the language, Bjarne Stroustrup, who also happens to be a university teacher, so I would say it could be considered an objectively reasonable starting point for learning C++ for someone not very experienced with programming and Effective Modern C++, while aimed at programmers that are already experienced with C++, might give you a bit of insight into understanding why old codebases look the way they do and how to improve them and not repeat their mistakes (its also quite a well written book in many aspects, quite a pleasure to read).

Also I would avoid any C++ centric book on algorithms and data structures written pre 2011 like the plague, since the language has evolved a lot and you might find yourself learning a very old.

For programming, what kind of programming is he into? Here are some cool programming books and things:

• Automate the Boring Stuff with Python This book has a lot of beginner projects that are actually useful.
  
  
• Arduino A little microprocessor that he can use to make cool projects. I'm a software engineer and I had fun playing aroung with this. Plus, you can use it for actual useful things (I'm planning on making an automatic plant waterer, but you can look online for all the awesome stuff people have made).
  
  
• Raspberry Pi Similar to the arduino but it's a full computer. For more software-heavy projects than the arduino. I'd probably recommend starting with the arduino.
  
  
• Great book about how code and computers actually work that's geared towards the "intelligent layperson" link.
  
  
• If he's already programming and wants to create games I can recommend this one.. Not good for beginners though.
  
  
• If you want to give him a well written tome about game programming here it is. Again, not really for beginners but really good for someone wanting to learn about game programming

Modern C++ (C++11 or later) books are not nearly as plentiful as those for Classic C++, but there are a few notables.

Bjarne's college text may be what you are looking for:

Programming: Principles and Practice Using C++ https://www.amazon.com/Programming-Principles-Practice-Using-2nd/dp/0321992784/ref=pd_sim_14_2/144-7765085-0122037

It is aimed at engineers, which makes it less general, but might be good for you.

Of course his general intro is also updated to C++11.

The C++ Programming Language https://www.amazon.com/C-Programming-Language-4th/dp/0321563840/ref=pd_sim_14_2/144-7765085-0122037

This is aimed at experienced systems programmers, so it may be a bit heavy for students, which makes the Primer (that you mentioned attractive).

C++ Primer https://www.amazon.com/Primer-5th-Stanley-B-Lippman/dp/0321714113/ref=pd_bxgy_14_img_2/144-7765085-0122037

Be certain to get the 5th edition.

Of Scott's books only the latest is Modern.

Effective Modern C++ https://www.amazon.com/Effective-Modern-Specific-Ways-Improve/dp/1491903996/ref=pd_sim_14_2/144-7765085-0122037?_encoding=UTF8

This is less an introduction for students than for Journeymen (Journeypeople?) programmers.

For just plain good programming style consider Ivan's book.

Functional Programming in C++ https://www.amazon.com/gp/product/1617293814

Don't be put off by "Functional." This style of programming will make your students excellent programmers.

There are some modern books of high quality that are niche.

The ultimate guide to templates:
C++ Templates https://www.amazon.com/C-Templates-Complete-Guide-2nd/dp/0321714121/ref=pd_sim_14_1/144-7765085-0122037

The ultimate guide to concurrency:
C++ Concurrency in Action https://www.amazon.com/C-Concurrency-Action-Anthony-Williams/dp/1617294691/ref=pd_sim_14_1/144-7765085-0122037

Some library options:

Despite its name, this is mostly reference. A very good reference.
The C++ Standard Library: A Tutorial and Reference (2nd Edition) https://www.amazon.com/Standard-Library-Tutorial-Reference-2nd/dp/0321623215/ref=pd_sim_14_2/144-7765085-0122037

Arthur's book covers C++17, which makes it one of the most modern on this list:
Mastering the C++17 STL: Make full use of the standard library components in C++17 https://www.amazon.com/Mastering-17-STL-standard-components-ebook/dp/B076CQ1RFF/ref=sr_1_fkmrnull_1

To what extent are you teaching C++ and to what extent are you teaching programing?

Good luck and have fun!

It depends on how much programming experience you have. If FreeCodeCamp is all you've done and have only worked with JavaScript, then I think that CS50 would be worth going through. For the first few lectures, he goes material which uses C and talks about low-level memory management and how many things work under the hood. While this isn't necessary to the daily work of a web developer, it is still good to write code while being conscious of what's happening under the hood through all those abstractions.

As /u/artotal said in his reply, learning the fundamentals of data structures and basic algorithms and complexity really go a long way. I don't think CS50 goes very in-depth with regards to this, but there's a few different sources you could learn from. You could go the hands-on route and hop straight onto sites like HackerRank and Kattis and start working your way up the problem ladders if you already have some basic familiarity. If learning from scratch, FreeCodeCamp has a nice set of videos on their YouTube channel talking about different data structures implemented in JS.

As for general progression after FreeCodeCamp, keep building projects. I'm not sure how far you're into the curriculum, but it's quite long and it's got many projects even in the curriculum if you do both front and back end curriculums. With your currently existing projects, go back and see if you can make improvements to any of them. Maybe try and move them off of Codepen (if you did them there) and to your own personal portfolio site. Refine your portfolio page and have links to your projects, your Github, resume, etc. You can have free hosting through Github Pages and you should be able to host all the front end projects there. For Node projects, you can try hosting them through Heroku, or see about free hosting through Google Cloud or get trial credits on AWS or Digital Ocean.

I hope this gave you a general idea of how to progress. Choose what you want to do depending on your immediate goal. Looking for a job? Polish that resume, get your portfolio site and projects up and running, maybe get a domain name for it. Go on HackerRank and LeetCode and practice some common interview problems. Have a bit of free learning time? Dive into the fundamentals of CS. Consider taking a look at some of the tried and true CS textbooks like this one (I'm sure that with some Googling you can find links to a pdf of it for free).

You can start out with some of the New Boston Android Tutorials - http://www.youtube.com/playlist?list=PL3D7BFF1DDBDAAFE5

The best way to learn is to pick a project and see it through to fruition. Go with something simple but not too simple, I'd recommend trying to make your own clone of this tip calculator. Don't just make it kind-of work, get it to where you would be proud to release it.

If you are completely new to programming it will be slow going at first, but there is no better time to learn than now, with some google searches you can find hundreds of free online programming courses (MIT Open Courseware and UC Berkley should get you started). You can google just about any problem and find someone who has encountered it before and solved it, sites like stackoverflow have hit the mainstream with programmers and it has become far easier to disseminate and learn best practices.

Also, Code by Charles Petzold is by far the best introduction I have ever read on computing theory, it has very little to do with conventional programming though.

Shamelessly stealing from one of the Amazon reviews:
> The average person who uses a computer to surf the web or type letters has so little knowledge of the underlying technology he or she is using that it may as well be magic. Even programmers, who typically spend their days solving problems with the high-end abstractedness of object-orientation, may be more than a little unclear about what's actually going on inside the box when their compiled code is running.
Petzold attempts, and largely succeeds at, writing a book that leaves the reasonably intelligent layperson with a thorough comprehension of each layer that comprises a modern electronic computer (binary coding -> electronic representation -> transistors -> logic gates -> integrated circuits -> microprocessors -> opcodes -> assembly language -> high-level language -> applications). At times, the reader must follow along carefully, but Petzold tries to avoid needless complication.

>What brought you that position?

My path included convert parents, BIC, a very happy childhood in a huge loving family, RM, 30ish years TBM, 10 years agnostic (closeted 7 or 8 years), going on I think 7ish years now as a Christian. I'm bookish - PhD in engineering. My agnostic period kind of grew out of the full term surprise stillbirth of our second child. I was already starting to question BoM historicity, I had issues with the whole "I know the church is true" thing / epistemology, and it was a fairly quick worldview failure after that. Then with the discovering church history. You get the idea. During my agnostic period, I held a position pretty much identical to what I hear you describing: I cared deeply about truth (still do, very much), I knew logic works (still a big fan, but more aware of its limits now), eventually felt called to try to 'get off the fence' of agnosticism, if I could do it authentically. My approach was to start reading more. Things I read: Godel Escher Bach, Tolstoy's War and Peace, Pilgrim's Progress, a bunch of CS Lewis, the bible in modern english, and a bunch of other stuff I can't remember. Some things that most impressed me about the bible: stories about what goes on in people's hearts that I could see in myself, in my loved ones, and around me in the world, the coherence of the entire narrative around the theme of redemption, the concept of Grace implied in God's relationship to His people and later extended to the individual by Paul.

> what makes you believe in the Christian God?

Here is one thing I wrote about that before.

What about some classics like Uncle Bob talks?

A lot of good design focuses on decoupling and creating components which work together but separately also.

Id first look into language agnostic design principles such as SOLID

https://youtu.be/TMuno5RZNeE
https://youtu.be/zzAdEt3xZ1M (golang)

A good book will help.

https://www.amazon.com/Clean-Code-Handbook-Software-Craftsmanship/dp/0132350882

I still keep a copy of the Gang of Four book at arms reach even tho the popularity is dwindling as OOP is not topic of most convos today. However when dealing with DI and sharable components in Golang, i find myself still falling back to abstract factories patterns. Its a good breathe of knowledge to at least glimpse at the patterns here:
Design Patterns: Elements of Reusable Object-Oriented Software https://www.amazon.com/dp/0201633612/ref=cm_sw_r_cp_api_i_7BzvDbXJC5WS4

Once you get thru these topics, you can start picking up what I consider the "hot" architectures of today:
Microservices, event based systems, domain driven design, event sourcing, and architectures aiding themselves to functional programming.

I really enjoy reading Martin Fowler blog posts: https://martinfowler.com/tags/application%20architecture.html

He covers a lot of these topics.

PS: maybe a niche and a personal favorite of mine but ive learned ALOT by researching the different types of kernel architectures. Nothing really geeks me out like those topic, but not for everyone.

A fabulous free course exists on these topics:
https://www.udacity.com/course/advanced-operating-systems--ud189

My advice is:

• Do self project and make a portfolio on git. You are more likely to be hired employer's know you strive to learn something knew everyday.
  
• If you can, read this book Design Patterns Its old but is gold. Its an abstraction of patterns commonly found on any company's code base.
  
• Don't assume you know everything and anything. Employers tend to like people who admit it when they don't know anything. Nobody likes a "know it all"
  
• Learn how to google. Stack overflow will be your best friend
  
• Learn how to debug someone else's code
  
• Be friendly and show to interviewers that you are approachable and open. The IT world is not a one man job. You will be working and be part of a team.
  
• Learn to be able to say/express how and what you think. You will need that skill to convey your thoughts to colleagues, especially to product owners / stake holders.
  
• Don't assume you'll be making this kickass app/program/web service/database from scratch. Chances are, you are highly likely to be maintaining someone else's code.
  
  I was in the same boat as you 3 years ago. CS degree anddd thousands applying for the same position as me. Luckily i got a job in the end. Started applying 3 months before i finished my exam. Ended up getting a job straight after finishing my exams as a junior software developer. :)

If you have a reasonable handle on basic data structures and actually want a good text book I highly recommend Introduction to Algorithms, 3rd Edition (MIT Press) http://www.amazon.com/dp/0262033844/ref=cm_sw_r_tw_awdm_2BF-wb1BY0EY4 via @amazon

It was by far my favorite text. I didn't start using it until grad school but some schools use it in undergraduate work so it shouldn't be too advanced for a dedicated student.

Now if you don't actually want a nearly 2k page textbook but something to keep you engaged in programming I'd recommend https://www.nostarch.com/lisp.htm Land of Lisp is a very approachable book that teaches functional programming in the context of a text based game.

Lisp is pretty different from the C family of languages and still introduces a number of great concepts that will help with most other styles of programming. Specifically around immutability and side effects.

If you want to just dip your feet I recommend the 7 in 7 series from pragprog https://pragprog.com/categories/7in7 where they walk you through seven X over a seven week period.

If you want to solve bigger problems just start a project and see what happens :)

Ps. If you have a specific topic - not game dev - that you want a book recommendation on just ask. I read way too many of them.

ALL technology? As in you're not even allowed to listen to music? Because that's what I'd recommend if you can get away with it; a lot of people listen to music while they do other things but very few people sit down and relax and focus on listening to their favorite music without multitasking, it's a great way to pass time.

Failing that, taking up drawing or writing are economical options considering you're tight on cash. A loaner guitar or cheapo from a pawn shop could be healthy hobbies, but they're tough to learn without your computer to access resources.

You said you don't like reading but I'd suggest you try to learn to love it, because it's going to be one of the cheapest and most fulfilling ways to pass time given your constraints. I think as you spend time away from technology you'll find reading more enjoyable as your mind recovers some of it's ability to focus. Just going out on a limb here (and projecting a bit), but do you often feel unable to focus on tasks like reading long passages or say sitting back to watch a movie without interruption? I know at least one author who's written a book suggesting that the way we're presented with rapid-fire and incredibly diverse information/entertainment on the internet has left our ability for deep focus impaired, while our ability to multi-task has improved.

Another option that occurred to me mid-post is that you might try to find some cheap model airplane kits or something like that, they're quite time consuming if you can be meticulous.

> Maybe now is a good time to step back and consider what kind of programming job you might want to target.

This is definitely something you should keep in mind. Try to become really awesome at one thing. That's not to say you shouldn't have a well rounded education in programming, just that someone who is simply ok at everything isn't getting a job anywhere.

Here are a few texts which I consider to be great for a novice programmer:

The C Programming Language : ANSI C

It's an older book, but it's still the best book to learn the language.

C++ Primer : C++

I used this book to get started with C++, and found it to be easy to follow and informative. Some say it's not a beginner book per-se, they may be right. I was already very familiar with C when I started.

Objective-C Programming: The Big Nerd Ranch Guide : Objective-C

If you're planning to write apps for Apple's iOS and OS X platforms, you're definitely going to need to learn this. Otherwise, don't bother.

Algorithms : Algorithms / Data Structures

This is not the be and end all authority on algorithms, but it's a great book. It's less theoretical and more concrete in my opinion.

I don't feel qualified to give recommendations for other topics like Java or web development, as those aren't really my strong suits. Happy hunting!

With regard to debugging, I would say the major hurdle for me was learning how to deeply inspect and interpret the contents in memory. It's pretty easy to step through a program and see what it's currently doing, but interpreting why it did something it wasn't supposed to do is more challenging. For me, this was a matter of repetitive "learn by doing".

To aid with this, I used gdb as a tool to reverse engineer and write a couple of keygen and serial-cracks for various freemium things randomly downloaded from the internet. This was purely for fun and not connected to my job past learning how to really use gdb. It's not as hard as you might think, though some familiarity with assembly helps. Despite looking like an early 90s bullshit interpretation of computers, this is actually a really great book if you're interested.

As far as testing is concerned, it's not something I had really encountered until my first professional programming job. Testing certainly wasn't taught to me in college. The basics of testing are pretty straight forward. What isn't so straight forward is the skill of writing testable code. It's actually pretty easy to code something up that seems to work but is utterly untestable for a variety of reasons. I think this is the major hurdle when it comes to testing, and a skill I work very hard to teach my junior peers. It just so happens to the case that testable code also tends to be decoupled maintainable code - which is beneficial for obvious reasons.

I can't offer you a lot in the way of non-fiction. If you haven't read it, Gödel, Escher, Bach by Douglas Hofstadter is a good read. It is very dense and slow reading, but can be rewarding. If you like computer science, biology, math, or music in any combination, this could be a good book for you.

The secret to picking good non-fiction is to find something you're interested in or curious about and read a book about it. Things like neuro-linguistic programming, cryptography, riding horses, biking, running, cacti of the saguaro desert, Trees of the Eastern Forests, Scuba diving, Lockpicking, Prestidigitation (aka "magic tricks"), etc.

Of other books I've loved but could not mention in my top 3, I include:

• Kushiel's Dart by Jacqueline Carey
  
• Black Sun Rising by C.S. Friedman
  
• Cryptonomicon by Neal Stephenson
  
• Slaughterhouse Five by Kurt Vonnegut (or any book by Kurt Vonnegut)
  
  That's all I can think of right now at work, but if you want more, PM me and I'll see what I can dig up.

I was hoping to get specifically into crypto/privacy. I've been learning from these books:

• http://www.amazon.com/Understanding-Cryptography-Textbook-Students-Practitioners/dp/3642041000
  
  
• http://www.amazon.com/Concrete-Mathematics-Foundation-Computer-Science/dp/0201558025/ref=sr_1_1?s=books&ie=UTF8&qid=1348702359&sr=1-1&keywords=concrete+mathematics
  
  and supplementing that with the Coursera Cryptography I class
  
  my eventual goal is to do either information security or penetration testing, but pen testing seems like one of those jobs that sounds great and seems so cool that everyone wants it. Like the job equivalent of planning on being a rock star.
  
  I've got a working knowledge at least of Java, but no programs to show for it yet (which was the source of my wanting this advice here.)
  
  Also, I have been doing this without a college, and don't really plan on going to college at any point soon.
  
  I do want to look into certifications, they were something I've had an eye on, but the opinions on their use is so varied on them I just figured I'd wait to get them until after I had a working knowledge base, then just blow through them to have the piece of paper.
  
  I've read around that the CISSP takes 5 years to take credit for, and the associates is like 3 or so. While I do want the most laudable one (i've read the DoD/Gov'ts cert requirements and it cares a LOT about the CISSP), That would mean 3-5 years of a catch-22 of not having the job to get the CISSP exp. with, because it would be my only cert so far and I can't take credit for it, therefore I have no certs and can't get exp.
  
  I've messed around with backtrack and armitage, and got through as much of Hacking Exposed (6th edition) to know at least the process, but haven't applied any of it and it seemed like it might be better to learn how things work before subverting details and breaking protocols for fun and profit.
  
  I do plan on getting the CISSP, but I'm not gonna start that process until I already have a job in the field i can use as experience to get more jobs, otherwise I'll just be sitting on my hands.
  
  Does that all seem alright, or do you have any advice? Sorry for talking your ear off, if that's what i did just now.
  

> I learned in android studio and got to a level where I could create an app. Little did I know, it was just a giant main activity with 100s f methods. My friend looked at the code and told me I needed to learn polymorphism. Now I've redone the code so it's all inclasses.

Yep. This is a really common stage in learning. It sounds like you maybe went overboard and created way more classes than you needed.

Next time I might suggest starting with your working program with just one big activity, then splitting things into separate classes one at a time.

> Well, I have to keep updating a bunch of list sizes to the main activity, but the problem is that the polymorphism has the list sizes passing through 4 classes to get to the main activity. So, I set up a bunch of interfaces that react when things are done within the classes all encapsuled in one overreaching class. I don't know.

I think you're blaming "polymorphism", but polymorphism is just a tool. You can use it to make good designs or bad designs. It's quite easy to use it to design something that's cumbersome and less effective than if you had no classes at all, and it sounds like that may have happened here. It doesn't mean there's something wrong with polymorphism.

I think you're conflating two separate things here: (1) what's a good design, and (2) how do you make your code work.

(2) is easy. If you post a small, complete program that doesn't work, we can help you understand why. We can't do that if you just post vague questions and snippets of code.

(1) is hard. This takes years to get the hang of, and a lifetime to master. At a good software company you'd learn this slowly by mentorship - you'd have a senior programmer reviewing every change you make and guiding you through the design one feature at a time. You'd get help organizing your code long before it got to hundreds of functions.

If you don't have that option, or even if you do, I'd recommend the book Design Patterns as a way to better understand how to use polymorphism effectively.

You're also welcome to post such questions here, but they have to be very specific. You have to tell us what your app does, in a lot of detail, and how you've organized it into methods. I can't give you advice on something vague like "passing list sizes to the main activity" because I don't understand the purpose of the lists, the purpose of the sizes, or the purpose of passing them to the main activity.

Edit: I didn't realize the link was just the first chapter. If you really liked it, I do suggest purchasing it. You can find it all online for free, but I do highly recommend just having this book. It's a fun read.

 

Here's an excerpt that I really love right from the beginning of the book.

>>All programmers are optimists. Perhaps this modern sorcery especially
attracts those who believe in happy endings and fairy godmothers.
Perhaps the hundreds of nitty frustrations drive away all
but those who habitually focus on the end goal. Perhaps it is
merely that computers are young, programmers are younger, and
the young are always optimists. But however the selection process
works, the result is indisputable: "This time it will surely run," or
"I just found the last bug."

Here's a link to a Physical copy [on Amazon] (https://www.amazon.com/Mythical-Man-Month-Software-Engineering-Anniversary/dp/0201835959) if you want it.

 

edit: Bonus Dilbert Comic

You can always read books. Textbooks are much better to read when you're free to browse and pick out whichever ones you like. You can get a surprising amount of reading done just by reading on the bus, on the can, and whenever you've got nothing better to do.

A popular stack overflow answer has a pretty good list. You can preview the introduction of most books on amazon.

People like to champion the internet as "oh, you can learn anything on the internet!" Which is true. But you can learn it much faster and better from a book (generally speaking).

Books provide a long format which has a chance to build upon itself. Also, everything is collected in one place for easy access. More developers ought to sit down and read good books.

Agreed. There are plenty of resources out there that will help you understand design patterns. If you're new to the concept, I would recommend Head First: Design Patterns, it might be based on Java, but the examples are simple to understand and can mostly apply to PHP as well. When you feel like you've grasped the basic concepts of design patterns, you can move on to more advanced texts, like Martin Fowler's Patterns of Enterprise Design - this is a great reference for a lot of the more common patterns. There is also Refactoring: Improving the Design of Existing Code. These are great investments that will help you with any project you work on, and will help you if you decide to use a framework like Zend which uses design patterns very heavily.

Excellent questions! If you are a CS grad you are ahead of the game. However, it all depends on what you want to do. I suggested learning programming/CS principles for two reasons:

1. The more you understand how computers, code, compliers, software, stacks, memory randomization, CPU protection rings, and the such work the better you are at hacking. You can find novel ways to get into systems and exploit them, etc.
   
   
2. You can write basic tools on the fly. It is amazing the tools you can create with a few lines of code when you have access to nothing but a GCC compiler in a *nix environment.
   
   If you want to find zero day exploits, yes learn how low level languages work. It would be very helpful in that case.
   
   Otherwise, Learn python (or whatever is popular at the time) to write your own exploit tools....or to modify existing ones.
   
   
   If you want to be apart of a red team learning lower level languages could make you a better exploiter. However, IMO, I would start with just learning the basics of hacking.
   
   
   These two books are old but they are absolute standards for anyone starting off:
   
   https://www.amazon.com/dp/1593271441/ref=cm_sw_r_cp_awdb_t1_GYIACb1Z2YXFA
   
   And:
   
   https://www.amazon.com/dp/1593275641/ref=cm_sw_r_cp_awdb_t1_zZIACbMH0WTMP
   
   
   Also, learn as much as you can on how windows/Linux/virtual machines (and containers) work. The more you know about how an OS works the easier it is to exploit.
   
   Learn to exploit, there are a ton of free sites to help you learn:
   
   http://overthewire.org/wargames/
   
   
   https://www.cybrary.it
   
   
   
   www.vulnhub.com
   
   
   http://google-gruyere.appspot.com
   
   
   
   Learn CTF challenges:
   
   https://ctflearn.com
   
   
   When you are able to hack take part in real challenges:
   
   
   https://ctf365.com
   
   
   Then start your career with a RESPECTED CERT, OSCP:
   
   
   https://www.offensive-security.com/information-security-certifications/oscp-offensive-security-certified-professional/
   
   The OSCP is no joke and it is a timed, 24 hour cert test. Yes, you read that right, 24 hours.
   
   Unless you want a government gig stay away from C|EH, it is a joke cert in the community. Again, unless you need to work for a gov agency
   
   
   
   Finally, and I cannot stress this enough.....LEARN CLOUD COMPUTING!!! It is here to stay and on-prem systems are dying a slow death. It will change how you exploit systems and how software is engineered/deployed.
   
   

How about a new language? Or writing software rather than web stuff?

After doing webdev for a while I got in to offline Java (software) development. Aside from helping me tighten my grasp on real OOP, it also caused me to shift/alter some of my design patterns. Java itself can be extremely cumbersome to write, but the process of doing so definitely made me stop and re-think exactly HOW much I want to leverage the flexibility of other languages.

Writing Java also lead me to read books, from which I took lessons I could apply to other languages. These books in particular were helpful:

http://www.amazon.ca/Design-Patterns-Elements-Reusable-Object-Oriented/dp/0201633612

http://www.barnesandnoble.com/w/data-structures-and-algorithms-in-java-robert-lafore/1100840388?ean=9780672324536&itm=1&usri=9780672324536

Obviously I'm just using Java as an example. If you already write Java, or feel great about your understanding of OOP, perhaps try a functional programming language? Lisp(Clojure)? Scala? The performance of some of these languages is really wild, and I'd think it would be possible to leverage their speed when working on large SAAS projects.

Anyways, to each their own. Obviously the other comments here have plenty of good suggestions. I know I certainly didn't regret getting familiar with SASS. And I could probably stand to spend time forcing myself to get more proficient with my editor. Right now I use Sublime Text 2, and I could either make sure I'm using all the proper key binds for traversing/manipulating text OR just go boss mode and make the switch to vim. Or even bite the bullet and use an IDE (http://www.jetbrains.com/).

Best of luck!

Hi PizzaPartify,
I believe that different companies/teams will place emphasis on different skills. When I was helping to hire software engineers for EA's motion capture studio, I liked to see candidates who showed a strong aptitude for engineering code to be maintainable. For me, this meant a familiarity with design patterns and software development processes (like Test Driven Development or Extreme Programming). In my department, much of our code was in C++ and Python. However, other departments would use languages like Java, C# or ActionScript - depending on the project.

It would be helpful to know what role you are applying to.

To answer your specific questions:

1. If you're already familiar with C++, I would highly recommend reading Effective C++ by Scott Meyers (http://www.amazon.ca/Effective-Specific-Improve-Programs-Designs/dp/0321334876). Every C++ developer should read this.
   
   Regardless of the language you're working in, I would also recommend Design Patterns by the gang of four (http://www.amazon.ca/Design-Patterns-Elements-Reusable-Object-Oriented/dp/0201633612).
   
   A game-specific recommendation is Game Engine Architecture by Jason Gregory (http://www.amazon.ca/Game-Engine-Architecture-Jason-Gregory/dp/1568814135). It doesn't matter if you intend to write an engine or not, it is immensely helpful to understand how they work.
   
   I own all of the Game Programming Gems books but use them more as a reference library. The books above will be more helpful right now.
   
   
2. I worked with Unity only briefly to prototype a game, so I can't really comment here.
   
   
3. This is tricky. I think you will need to find a passion project in C++ so that you will just naturally learn more about the language. And speaking of passion: you need to really want the job you are applying for. I have seen qualified developers miss out on jobs because you could tell they were just looking for anything (rather than really being enthusiastic about the position).
   
   I hope that helps.