Hahaha, you're right, my post sounds totally creepy, sorry about that.

What I got from you is that you're basically dealing with 2 issues:

Lack of knowledge, skills and experience: it's like you have 4 times 1 year experience instead of 4 years of experience. Seems that you miss being exposed to different challenges and solutions to those challenges.

Imposter syndrome - fed by the previous one

First, it's important to acknowledge that both these problems will follow you throughout your whole career. The very nature of our industry, whit new tools, languages, frameworks and techniques appearing litterally everyday, makes it impossible for someone to know everything. Given this scenario, we have to be smart about what and how to learn things and, at the same time, be confortable being unconfortable.

I think those are a whole new discussion (we can talk about it if you want) but I'd like to suggest some tactics that might help you on a shorter term:

Join a community

This was what made THE big difference for me years ago. I didn't know anything other than what I did at my job; the community showed me different ways of doing my work that I didn't know even existed. It's a perfect space to learn, share experiences and network. Try to join a local community that has in person meetings. I still get a lot of energy from interacting with people from outside my job.

Pair programming

I don't know if your team does pair programming, but I'd recommend it. Even if you team doesn't do it, ask people if could pair with them for an hour or so on their tasks. Learn their style, how they use their tools, their shortcuts. Ask what they're thinking as they code. Discuss the solution being implemented, talk about alternatives.

I think pairing is one the best ways to learn.

Good article about techniques for pair programming by colleagues of mine

Start a pet project

Assuming you lack experience on backend development, I'd suggest you start building a complete web application on your free time. Build something that you care about and would actually do something, so you stay motivated. You can start with something very simple and add features as you go.

I don't know if you're interested in some specific language/technology and I don't know what your team uses on your current job (it would be nice to practice on something that would be immediately useful on your job), so I'd recommend something like Rails. Rails can be simple enough for a beginner to see progress quickly and has a huge community for support.

This app can be your platform to learn and practice a complete software development lifecycle for a typical web app - stuff like OO design, HTTP and REST, MVC pattern, unit testing/TDD, integration and functional testing, version control and how to deploy and operate a system in production.

You can share your code in GitHub and ask for reviews and feedback.

Teach

There's always someone that knows less than you do about a subject. Offer help on the communities you're part of, answer questions on reddit or stackoverflow, coach a new teammate... there are tons of opportunities. Teaching will make you feel good about yourself and will help you to reflect and understand more deeply the subjects you're teaching. Confidence + knowledge.

Host a lunch & learn or brown bag session for your team/company. You could share interesting stuff you're working on, cool technologies for your team to try or any other tech related subject. This can make you be perceived as the "go to" person on some subject and as someone who's making an effort to learn and share with coworkers, bringing lots of value to the team/company.

Books

I strongly recommend you check out Clean Code and The Pragmatic Programmer. There are many other great books I could recommend but those two were the ones that changed the way I see my profession.

I can think of a bunch other tactics to help you improve your skills and confidence, but I think this is enough to start a conversation.

Ideally, our jobs should provide all the opportunities to practice and accomplish all the things I suggested you do by yourself. But to get one of those jobs, we need to take the firsts steps. My point is that we should be in control of our career, not your manager/team/company. If we want to learn something, or use some tool or technology, we shouldn't wait for the opportunity to come.

Does this make sense to you? Is this helpful?

PS: I'm curious about a couple of points:

When you say "I've always struggled to build big features", what kind of features you're talking about? Can you be more specific?

When you say "I have to spend a really long time just thinking about some problem", what kind of problem is this?

I might have some insight about those issues.

My main hobby is reading textbooks, so I decided to go beyond the scope of the question posed. I took a look at what I have on my shelves in order to recommend particularly good or standard books that I think could characterize large portions of an undergraduate degree and perhaps the beginnings of a graduate degree in the main fields that interest me, plus some personal favorites.

Neuroscience: Theoretical Neuroscience is a good book for the field of that name, though it does require background knowledge in neuroscience (for which, as others mentioned, Kandel's text is excellent, not to mention that it alone can cover the majority of an undergraduate degree in neuroscience if corequisite classes such as biology and chemistry are momentarily ignored) and in differential equations. Neurobiology of Learning and Memory and Cognitive Neuroscience and Neuropsychology were used in my classes on cognition and learning/memory and I enjoyed both; though they tend to choose breadth over depth, all references are research papers and thus one can easily choose to go more in depth in any relevant topics by consulting these books' bibliographies.

General chemistry, organic chemistry/synthesis: I liked Linus Pauling's General Chemistry more than whatever my school gave us for general chemistry. I liked this undergraduate organic chemistry book, though I should say that I have little exposure to other organic chemistry books, and I found Protective Groups in Organic Synthesis to be very informative and useful. Unfortunately, I didn't have time to take instrumental/analytical/inorganic/physical chemistry and so have no idea what to recommend there.

Biochemistry: Lehninger is the standard text, though it's rather expensive. I have limited exposure here.

Mathematics: When I was younger (i.e. before having learned calculus), I found the four-volume The World of Mathematics great for introducing me to a lot of new concepts and branches of mathematics and for inspiring interest; I would strongly recommend this collection to anyone interested in mathematics and especially to people considering choosing to major in math as an undergrad. I found the trio of Spivak's Calculus (which Amazon says is now unfortunately out of print), Stewart's Calculus (standard text), and Kline's Calculus: An Intuitive and Physical Approach to be a good combination of rigor, practical application, and physical intuition, respectively, for calculus. My school used Marsden and Hoffman's Elementary Classical Analysis for introductory analysis (which is the field that develops and proves the calculus taught in high school), but I liked Rudin's Principles of Mathematical Analysis (nicknamed "Baby Rudin") better. I haven't worked my way though Munkres' Topology yet, but it's great so far and is often recommended as a standard beginning toplogy text. I haven't found books on differential equations or on linear algebra that I've really liked. I randomly came across Quine's Set Theory and its Logic, which I thought was an excellent introduction to set theory. Russell and Whitehead's Principia Mathematica is a very famous text, but I haven't gotten hold of a copy yet. Lang's Algebra is an excellent abstract algebra textbook, though it's rather sophisticated and I've gotten through only a small portion of it as I don't plan on getting a PhD in that subject.

Computer Science: For artificial intelligence and related areas, Russell and Norvig's Artificial Intelligence: A Modern Approach's text is a standard and good text, and I also liked Introduction to Information Retrieval (which is available online by chapter and entirely). For processor design, I found Computer Organization and Design to be a good introduction. I don't have any recommendations for specific programming languages as I find self-teaching to be most important there, nor do I know of any data structures books that I found to be memorable (not that I've really looked, given the wealth of information online). Knuth's The Art of Computer Programming is considered to be a gold standard text for algorithms, but I haven't secured a copy yet.

Physics: For basic undergraduate physics (mechanics, e&m, and a smattering of other subjects), I liked Fundamentals of Physics. I liked Rindler's Essential Relativity and Messiah's Quantum Mechanics much better than whatever books my school used. I appreciated the exposition and style of Rindler's text. I understand that some of the later chapters of Messiah's text are now obsolete, but the rest of the book is good enough for you to not need to reference many other books. I have little exposure to books on other areas of physics and am sure that there are many others in this subreddit that can give excellent recommendations.

Other: I liked Early Theories of the Universe to be good light historical reading. I also think that everyone should read Kuhn's The Structure of Scientific Revolutions.

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.

You always want processing. You may or may not need graphics. I saw you say you liked fighting games. You'll need a decent rig with some capable graphics.

You wanna dev?

First, yes you need a machine, a decent one. Do you want to build it? Yes , but if not then check these out. I suggest getting a workstations because they're built for productivity. However, they're expensive.

Also, I'm not sure you should commit to a desktop. Two words: Game Jams. You might want to take part in communities involved in game making games. For inspiration, mentorship and just overall fun. If you're not familiar, games jams are when developer enthusiasts get together and build a game over a period of time. The games tend to be simple and set around a theme for the event.

In which case, look at some cool laptops. The reason I suggest getting a gaming laptop is that it will have the graphic card you need, it doesn't need to be high end, just good enough to not be a toaster. Also gaming laptops tend to be more powerful.

So from a dev point of view, they're pretty solid. Personally, I prefer workstations. If you asked me, I would get a workstation with a video card, but those are very expensive and maybe when you master your craft you can drop some real cash on it. You're new. So don't spend too much, in case the entire thing doesn't jive with you. Worst case you get a decent gaming laptop to play MK at the coffee shop. (Don't laugh, I used to play Street Fighter at a coffee shop, it's a nice vibe!)

Also, I would also check out Meetup.com. Your city or area might have groups dedicated to building games and maybe you can learn with another person. From a professional point of view, there's a lot of value in learning to work with others.

So you got your hardware, now for software.

You will likely want to start building stuff. But you're going to need some baseline stuff.

So, I say go with Unity, long term. However you need to get to a place to understand unity. So... you're going to need to learn some coding. To at LEAST be comfortable with code. I say learn the basic and intermediate stuff first then jump into Unity. If you're feeling bold you could also do the advanced.

You will need only Visual Studio and make sure during the install you ask to include Unity.

Finally, you should read Clean Code. Write good clean code. Future you will thank you.

Now, you gotta be productive.

Set up time to do what you want to do. One or two hour blocks. Commit to them. Log that time. Also, get open office, or some other equivalent and start organizing your workflow. as a develop you need purpose in your tasks. So outline your tasks. Develop you "method" for working. Maybe you like self imposed crunch where you just throw on music and go. Maybe you prefer small bursts of productivity. Whatever it is, figure it out.

Journal your work. Go back and read it occasionally. Take non-digital notes on important stuff you learn. Writing helps with retention. You have two processes you need to flesh out.

• Your development process. How something gets built, tested and delivered.
  
• Your Creative process. How you come up with a game idea and flesh out if it's good.
  
  You're going to need to get a good sense of how to build a proof of concept. This will help you "feel out" your game's mechanics.
  
  Over time, you will need to explore more advanced idea in computer science like data structures and design patterns... but for now, focus on getting comfortable with code, debugging. Hell, even make a console app text adventure game. Start there. Then get more complexity. The idea here, is to take your time, be diligent and stick to it. Slow isn't bad, not completing is bad. So take your time and good luck!

I can't speak of a specific book that is a comprehensive history of computing, but I will speak to books that speak of our culture, our myths, and our hero's.

Hackers and Painters, by Paul Graham. People are polarized about the man, whether he's too "pie in the sky" - full of shit and ego, or if he speaks as an ambassador to our most optimistic ideals of our (comp-sci) culture. The contents of this book is a collection of his essays that are inspirational. It made me forego the societal pressures within our culture and reject popular opinion because it is merely popular and just an opinion, which is a virtue no matter who you are, where you are, or what you do. All these essays are on his website, though. If you want to review them, I recommend Hackers and Painters (the essay), What You Can't Say, Why Nerds are Unpopular, and The Age of the Essay; his oldest essays are at the bottom of the page and go up - he writes about what he's thinking about or working on at the time, so you'll see the subject matter change over time. So much of this will have direct application to his middle school and high school life. I cannot recommend this book, and the rest of his essays, enough.

If he wants to get into programming, I recommend The Pragmatic Programmer. This book talks about the software development process. I'm not going to lie, I don't know when best to introduce this book to him. It's not a hard read whatsoever, but it's abstract. I read it in college in my first months and said, "Ok," and put it down. Approaching the end of college and my first couple years in my profession, I would reread it ever 6 months. It's a kind of book that doesn't mean anything, really, without experience, without having to live it, when he has an obligation to his craft, his profession. I tell you about this one since you're asking about books to tell him, because this isn't something someone would normally come up across without being told about it.

The Cathedral and the Bazaar is a telling book about the cultural differences between the proprietary monoliths like Apple and Microsoft, and the Free and Open Source Software communities that back such popular software as Linux (the most popular operating system on the planet, running on all top 500 super computers, most server computers on the internet, and all Android phones) and Chrome(the worlds most popular web browser). Indeed, this book directly reflects the huge cultural battle that was duked out in the field, in the industry, and in the courts from the mid-90s and into the 2000s. It advocates helping the community, contributing to something larger than yourself, and that none of us are as good as all of us. To paraphrase Linus Torvalds(inventor of Linux) "Given enough eyeballs, all bugs are shallow."

It's important to know who the hero's are in our culture, and they are diverse and varied, they're not just computer scientists, but mathematicians, physicists, philosophers, science fiction writers, and more. I would find a good book on Nicola Tesla, since he invented basically everything anyway (Thomas Edison was a great businessman, but a bit of a tosser), Richard Feynman was a physicist who is still celebrated in his field, and he even worked for Thinking Machines, back in the day, which was a marvel of it's time. Seymour Cray founded Cray Supercomputers and they have a lasting legacy in the field, a biography on that would be interesting. A biography on Symbolics and their Lisp Machines will make him yearn to find one still functioning (a rare gem that crops up every now and again, though he can run one in an emulator), and about the "AI Winter", a significant historic era (note: the AI Winter is over, and we are in spring, the history is both compelling and enthralling). Anything Issac Asimov published (in nearly every category of the dewy decimal system) is also compelling, and hardly dated. In fact, he's the originator of a lot of modern sci-fi. Charles Babbage invented the modern computer (though it was entirely mechanical in his day, and it wasn't actually built until 1996-2002) and Ada Lovelace was the worlds first computer programmer. A woman! Speaking of women, and it's worth young men learning this about our history, Grace Hopper was a military computer engineer who invented the term "bug".

And speaking of women, someone I have respect for, especially if your boy wants to get into game development is Sheri Graner Ray's Gender Inclusive Game Design, which may be more appropriate when he's in high school, and I consider it required reading for anyone who wants to enter the gaming industry. The book lays out plainly how video games hyper-sexualize both women, and, for some reason surprisingly to many - men, it's disastrous effects it has for the game industry, the game market, and the gaming community, and insights on how we may combat it. I have seen colleagues (men) become indignant and personally offended at reading this book, but were absolutely humbled when they took the fight to Sheri directly (we had a few phone interviews with her, always fantastic). If your boy found a problem with this book, he would do well to read Paul Grahams essay on keeping his identity small... The subject matter is not a personal attack on the individual, but on the blight, and he would be better served finding himself on the right side of history with this one, it would serve him well if he were to pursue this craft, specifically, but also any forward facing media in general.

And I also recommend some good books on math. Algebra, linear algebra, calculus, and statistics. You can get very far, lead an entire career unto retirement without knowing anything more than arithmetic and basic, basic algebra, but he could only serve himself well if he makes the decision that he is going to like maths and chooses to willfully become good at it. Outside the context of school and terrible teachers, it's actually an enthralling subject. Just get him a copy of Flatland, Flatterland, and Sphereland. Try this. There are books about proofs that break them down into laymen terms so that anyone can celebrate how special they are. My wife has a few on the shelf and I can't remember their titles off hand. Also this, the book is the narrative of some witty laymen who discover a whole branch of mathematics from first principles, the surreal numbers, an extension of imaginary numbers. It's really quite good, but might keep him occupied for a couple years in high school.

I should stop here or I never will.

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.

Hi and sorry for the late reply! The first thing I'll have to ask is what environment are you deploying into, a manually configured virtual machine/bare-metal machine, Heroku, Ninefold? Each of these environments have different (sometimes vastly different) considerations when it comes to deployment of any application. In general though, here's some things that will apply that will apply to any good deployment process (some of what's below echoes /u/codekitten's reply):

• Remove ALL credentials from your codebase: I can't stress this enough, and even for a simple project it's a good habit to get into early on. It's been enough of an issue that there are even dedicated tools to help people remove hard-coded credentials from their codebases. A good resource to explain both this, as well as the general concept of storing environment-specific configuration data outside of your codebase is this section of the Twelve-Factor App website. Personally, aside from things like tokens that Rails uses internally like Rails.application.config.secret_key_base, I will always use environment variables coupled with something like dotenv or direnv to also manage the configuration for my local development environment.
  
• SSL and HSTS: IMHO there is no (good) excuse nowadays to serve a web application over HTTP. Once again, even for simple projects it's a good habit to get into and a good thing to learn. If you're hosting your application on Heroku, all Heroku application subdomains (i.e. rxsharp.herokuapp.com) will respond to HTTPS, but it's up to you to ensure your user's will always use SSL. Rails has the force_ssl setting to do this automatically for you, which you should have turned on in all of your production and production-like environments, but you should also be using HSTS to ensure that your users always visit your site over SSL (force_ssl performs a permanent redirect to https://rxsharp.herokuapp.com but does not set the HSTS headers). The gem that I use most often to take care of setting these headers for me is secureheaders, which also helps you configure a number of other security headers like Content Security Policy headers.
  
• Continuous Integration: Let me expand a bit on /u/codekitten's item for passing tests to say that you should have a system in place that will automatically run all of your tests each time you push to your repository and holds you accountable when things break. Continuous integration is a huge topic that I won't dig too much into here, so I'll just point you two two indispensable books on the subject: Continuous Integration: Improving Software Quality and Reducing Risk, and Continuous Delivery: Reliable Software Releases through Build, Test, and Deployment Automation. Conceptually, you will learn almost everything you need to get started and thensome on the topic from those two books. Once you get your CI configuration in place, you will get in the wonderful habit of always making sure your build passes locally before you push to your repository. A good CI script will:
  
  • Run static analysis tools like RuboCop and Brakeman
    
  • Run all of tests
    
  • Notify you when a build fails and when it gets fixed
    
• Automate Everything: One of the most important things to learn about deployment early on is automation. Apart from initiating the deploy (and arguably even initiating the deploy itself), everything about your deployments should be automated to the fullest extent. There are several tools in the Rails world that most people use to accomplish this, most notably Capistrano and Mina. If you are using a platform-as-a-service like Heroku or Ninefold, see the documentation for one of those on how to automate various aspects of your deployment process.
  
• Deployment Smoke Testing: In my experience working in the Rails world, it seems that not a lot of people automate their post-deployment verification, even though it's very easy to do! It can be as simple as having a post-deployment hook that uses curl to hit a status page on your site that returns the currently deployed revision, and rollback the deploy if it receives an error. It can also be as complex as running a suite of RSpec examples that utilize something like Serverspec to assert the state of each one of your application servers (obviously this one doesn't work as easily in environments like Heroku). In the end, the important things here is that you automate EVERYTHING when it comes to your deployments.
  
• Database Migrations: First of all, don't forget to run them! If you're using something like Capistrano to script your deployments, the command to run a deployment that includes a database migration is cap production deploy:migrations, not cap production deploy. On Heroku, you need to run them manually after you deploy using something like heroku run rake db:migrate. One further topic here that I highly recommend you explore is that of zero-downtime migrations. A great introductory article on these is Rails Migrations with Zero Downtime over at Codeship.
  
  These things are all general items that belong near the top of any checklist for deployment (Rails or otherwise). Hope this helps!

Programming is a tool. I suggest finding another interest that you can apply it to. Robots, graphics, music, animation, sports, economics -- the possibilities are endless. Pick your favorite area, look at what kind of problems there are in that area that people use programs to solve, figure out how those sorts of programs work, and try to solve some of those problems yourself.

A few interesting examples:

• Project Euler has a set of challenges relating to both math and computer science that will stretch you to learn more about both.
  
• Python Challenge is basically a series of puzzles that challenge you to do new and interesting things with Python. Granted, several of the puzzles are quite similar and some of the libraries they reference are deprecated, but it's a place to start for programming challenges.
  
• Programming Computer Vision With Python talks all about using programs to do things like find objects in pictures and track them even at different sizes and angles. Lots of great examples.
  
• Programming Collective Intelligence talks about putting together data from different sources (primarily websites) and finding patterns. It deals with many machine learning concepts in ways that are practical and interesting. Things like modelling and predicting, optimizing, clustering (finding similarities), searching and ranking, and pattern recognition.
  
• Arduino Robotics describes many robots you can build with relatively common parts that can be programmed using the inexpensive, C-based Arduino microcontroller platform. I've made several of these myself.
  
• Digital Signal Processing is all about writing software that takes advantage of advanced math to manipulate signals in many ways. It's invaluable for audio, but you see it used with graphics, digital communications, and many other areas.
  
• There is a subset of sports fans that really enjoy statistics and software can be very valuable for them. Things like comparing players across eras, predicting future performance, and helping to find high-value players. The general field is called Sabremetrics. I looked deep into it in relation to major league baseball. Two books that I found valuable are The Book: Playing the Percentages in Baseball and Baseball Between the Numbers.
  
• Programmable games are cool too. Things like CROBOTS, CoreWar, RoboWar, and Robot Game. It's just as fun building the simulation environment as it is building the bots that compete within them.
  
• Pick up any book on algorithms. Learn to apply the basics like binary search, insertion sort, radix sort, memoization and linear programming, Dijkstra's algorithm, and Newton's method for root finding.
  
• Grab another book on data structures. Make sure you understand the differences between arrays, linked lists, hash tables, and trees. Learn about unique and useful things like binary trees, radix trees, heaps, and queues.
  
• Learn how to write better code. I recommend books like Code Complete and The Pragmatic Programmer.
  
  Whatever you do, as you clearly pointed out, you have to be interested in it or you'll grow bored and give up. Find something that is interesting to you and pursue it as wide and deep as you can.

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!

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.
  
  
  
  

I'm a technical PM for two teams, as a well a contributing dev on both teams.

While the skills are definitely different from programming a few things I've found that helps:

• Get to know AGILE really well. Read the manifesto, read about scrum vs kanban . Understand each's strengths and how to do the process correctly for both. I tend to think SCRUM is like fitness, you have to do it right to get the full benefits. If I go the gym and work out then, eat a gallon of ice cream everday, I won't be fit.
  
  
• Understand how to write good user stories, look into different patterns people use . For example the "As a <user> " format is quite popular but really understand how to flush out stories .
  
  
• Avoid strict timelines (I know you mentioned it in the OP) but a PM can't be 100% rigid on timelines and even suggest them . The way that works for our entire company is we base everyone complexity and use the fibonnaci scale to estimate complexity by having multiple people on a team vote. I (as the PM) look at past velocity (how many points we completed) and then project out how long something will take based on the point values estimated by the team. This works FAR better than "oh it will take 2-3 weeks". People are bad at time estimates, complexity estimates are a much better gauge.
  
  
• Practice your networking skills and diplomacy skills. Part of being a good PM is having established relationships with other teams and getting things for your team. A good product owner is a leader, but not a dictator. You don't tell the team what to do, you set the vision, and remove any blockers in their way. As part of this too is being available to answer questions.
  
  A few books you should read:
  
  
• Notes to a Software Team Leaders Even though its focused on being a lead/supervisor, you can get a lot of good insight on how to help guide the vision of a team.
  
• [Scrum: The Art of Doing Twice the Work in Half the Time] (https://www.amazon.com/Scrum-Doing-Twice-Work-Half/dp/038534645X). Really good book on understanding the spirit behind scrum, with real world examples. Not very technical , more about why rather than what scrum is. I've read this several times.
  
• The Phoenix Project. Good book about breaking down barriers between teams and working towards a shared goal. It is devops focused, but I believe product managers would benefit from reading this as it illustrates the importance of shared ownership, automation and avoiding silos.
  
• How to Win Friends and Influence People. Great book on interpersonal relationships and how work with others.
  
• The Clean Coder. A book focused on professionalism for developers (not so much the code, but overall environment/culture). This is a good resource to understand the dev cycle in the real world and what teams should be doing to be professional. This will help you when making decisions on specific things to focus on.
  
  In terms of sprint plannings, just remember it's a negotiation. You're not there to tell people what to do. Rather you have the stuff you would like done, but you negotiate with the team on what's possible and what's not. I've seen too many PM's get pissed cause their teams couldn't do 100% of what they wanted and that's not right. Rather a good PM, imo, brings options and lets the team decide how much they can handle. There have been times when I've gone into sprint plannings and non of items made it on the sprint, and that's ok.
  
  Sorry for the long rant!
  

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.
  

That's an interesting pattern you have going on there. I don't know what kind of background you're coming from, but one of the nice things about Python is that, being dynamically typed, you can pass almost anything to a function at run-time.


What that means is, you can have a function like a spell that expects a character object, whether it's p1 or p2 is irrelevant. It holds the logic of how to access the object and alter the attributes. There's a LOT that goes into how you design that, but that's a thing that literal books have been written about.


So, as a brief example, you might do something like this:

def fire_spell(target):
target.spell_hits('fire', damage=2)
return target

class Character:
def init(self, name, health=10, mana=10, immunity=None):
self.name = name
self._health = health
self._mana = mana
self._spells = {
'fire': fire_spell
}

@property
def health(self):
return self._health

@property
def mana(self):
return self._mana

def cast_spell(name, target):
self._spellsname
return self

def spellhits(self, type, damage=1):
if self.immunity == type:
return None
else:
self.health -= damage
return None

So let's break that down a bit:


fire_spell: Exists outside of the characters. I would probably put all my spells in a separate module, that way I can import them, and add and remove them at run-time from the characters. That enables you to do things like have spells that aren't accessible prior to a level up, or some other mechanic. This isn't too different from having a separate class for the moves, since you're trying to namespace the moves, but I'll get to where that's a little odd here in a second.


self._health: This is just an attribute, but note the leading underscore. This is a pythonic convention that tells anyone who is using your code not to use this variable to access the thing that it points to. That is it would be best to leave it private. Python doesn't have private variables, so this is as good as it gets. We're all adults here.


@property: This is an example of a built-in decorator. If you don't know what decorators are, there are TONS of tutorials out there. Essentially, they modify how a function works. This one makes it so that instead of having to call the function, e.g. player1.health(), you simply access it as an attribute a la player1.health. Why on earth would you want to do this though? Well, any code in the function will run prior to returning the attribute! This allows you to modify what the calling code receives when it accesses the attribute. You want to have a conditional health buff based on the zone that the character is? Boom, way easier with this pattern. What to have the mana get dropped to 0 because of a status effect, easy peasy. And as soon as the effect clears, it can go right back to where it was! Basically, @property is really cool.


spell_hits: This is a method on the Character object. This you know. But why is it there? Well, designing a game is essentially designing an API. You may have heard of API around town, usually people are talking about web APIs, but the term is Application Program Interface. It applies equally to what this is. The Character class exposes an API to function inside of your program. They can expect that if they're going to receive a Character then they can act on it in a certain way. This is actually where you start to understand why certain programmers really aren't fans of dynamic typing. Python gives precisely 0 shits what you pass to this function. You can pass it a list of integers and it will not be annoyed. Well, until you try to call spell_hits. Then you get PropertyError: list object has no method 'spell_hits'. This won't happen until runtime. Then you're stuck chasing down which part of your gaht DANG CODE PASSED IN A DAMNED LIST!!!!! This probably won't happen to you with a small program, but I like to add context!


return self: Why would you do that? Well, we're back to the concept of API design! It's a pattern used for a "fluent interface". This pattern allows you to utilize method chaining, which is a really nifty thing. For example, let's assume that you want to run specific series of methods on a certain user input, then you could do p1.cast_spell(p2).use_item(p1).another_method(). This is a pattern that you see in a lot of libraries. It helps wrap your head around it if you write some code yourself that does it.


As far as your code is concerned, there's on thing that really sticks out:

Attributes.init(self)
Moves.init(self)

You don't need to explicitly call __init__. The __init__ function is what a lot of pythonistas refer to as a "dunder method", short for "double-underscore". I prefer to call them "data-model methods", since that tells you what they're actually a part of, instead of describing how they're written (which is totally useless information). A bit pedantic? Totally, but I wouldn't be a programmer if I didn't have a pedantic pet peeve (how's that alliteration!)


Data model methods are called when they need to be, and in the case of __init__ that is when you initialize an object. Example:

class Thing:
def init(self, name):
self.name = name

t = Thing('bobby brown')
print(t.name)

That will output 'bobby brown' because we assign the newly initialized Thing object to the variable t. Without capturing the object with a reference to a variable, they will be garbage collected. Basically, the Attributes and Moves objects that you're initializing will not be attached in any way to the player. You would need to do something like

self.attributes = Attributes(self)

Which would allow you to reference the new objects inside your player. Garbage collection in python isn't something that you'll need to be concerned about often, but I mention it because it's nice to know that python uses reference counting. Well, C Python does, and you're probably using that, so....


Overall, I think that what you need to get coded (pun intended) into your brain is the idea of frist class-ness, specifically as it relates to python. This concept is what makes decorators possible, and underlies the design patterns related to classes. I would also highly recommend the official tutorial as a place to find solid info on basics.


Past that, really it comes down to design choices. There's a million other ways than the one that I gave you to do this. Each one has a good reason to do it, and each one has trade-offs. This is where the rubber meets the road! Real programming boys! If you're interested in reading something that might help, I recommend Clean Code as a good read on designing good reusable software. The design book I linked above is kind of dense and uses Java, which could be confusing if you don't have experience with it. Clean Code is more generalized.


TL;DR: Functions accept objects, so pass the player object to the function and alter the health there. Then go read a LOT of stuff on OOP design patterns, cause they're hella hard.

I got my start by taking AP CS in high school. However, I had already gone to college and that was a while ago, so I read some books on the commute to/from work.

Initially, I read Sams Teach Yourself PHP, Mysql and Apache all in one to learn PHP.

Immediately afterward, I read Murach's Java Se 6 and Beginning Java Objects to learn Java.

Most recently, I read a portion of C++ Primer Plus, but got very sick of it. I've read most of Accelerated C++

I have a few other books on C# to read when the time comes to actually write code.

By the time I had read all of the above, I felt pretty confident on how to structure a program, regardless of language. As such, I was able to pick up Python and JavaScript quite easily just by reading online documentation at Python.org and W3Schools. When I'm writing a web app, I'll rely pretty heavily on PHP's and MySQL's online documentation to help me with whatever syntax quibbles I may have.

I still want to read Game Coding Complete and I'll probably want to find a few resources on programming within XCode.

They all tend to follow the same programming paradigms, to be honest. Java did a good job in getting me into an OOP mindset and C/C++ did a good job at helping me think about how to program things without layer of abstraction. Once I learned these concepts, it was pretty easy to get started with a new language. Programming in PHP can be super sloppy, but taking what I learned from other languages, I'm usually able to write fairly clean code in PHP (especially when I learned how to use classes).

I wouldn't recommend all of the books above, to be honest. I didn't have much ability to do online training at the time and compiled lists of books weren't nearly as useful at the time, so I relied mostly on Amazon book reviews. I'm sure you can find a few choice books on each language you want to learn and go that way. If you were to read books, I think Accelerated C++ is a good book, but works best if you already have some experience programming. I remember like Beginning Java Objects more than Murach's, though both are great as references (which is why they're both still in my bookshelf). C++ Primer Plus spends too much time teaching C and not enough time teaching C++ (you spend pages upon pages learning about C-style strings, aka char arrays, rather than just using the String Class, but I digress).

Ultimately, I could read a bunch about a language, but I never truly learned the language until I started writing in it. I've written a handful of programs just as proofs of concepts and I recommend you do the same while learning any language.

I was right where you are now about 6 months ago. I'd done some unit tests in previous projects and could kinda see the point in using them for certain things, but I didn't understand the need for writing tests first, and didn't understand the value in the red, green refactor cycle.

I can tell you six months ago I started working for a company that believes heavily in TDD, and after going through the initial pain barrier, I now can't see any other sane way of writing code.

There were a few hoops I had to leap through in order to get to this point. One of them was due to the fact that I simply wasn't testing things correctly in the past. You should always isolate your tests to the EXACT thing you are testing in each case - so you should never really be connecting to the database, or depending on other modules etc. Any dependencies therefore need to be injected into the system under test and mocked accordingly, so you know you are isolating the thing you want to test.

You also should never be testing implementations, which is why you should never have to test private methods. You only care that the public methods of a class will return whatever you expect under the conditions you are testing for. This is crucial, because it's this that makes it really easy to refactor your code later.

When you take this approach for everything you do (combined with doing red, green, refactor), you find yourself soon entering a luxorious position of being able to refactor things at a higher level just to make things cleaner and easier to understand.

Just this week I took a system with over 2500 unit tests and refactored some of the fundamentals of that system - found some abstractions and moved them higher up the chain + extracted some interfaces to make the code easier to extend without modification, and all the while I knew everything was working because my unit tests proved it. This is part of the core of a system that deals with literally millions of users each day (seriously), and I did so without fear.

This approach means the code is constantly getting cleaned and tidied up as we go along.

The red/green/refactor approach works something like this:

• write a failing test (this is important, because simply going for a green pass right away can sometimes bite you - perhaps the test is providing a false positive? You should always see the test fail first for this reason)
  
  
• Make the test pass - I tend to do this in a sane way, but I don't try to engineer my code so much at this point. Just get it passing. The key to this is to only test the expected behaviour of the class, not to test the implementation - we only care about the result, not how the result is achieved. Doing this brings us to the next part:
  
  
• Refactor. This means we can do obvious stuff like removing duplicate code, and then generally chopping and changing stuff around to make it easier to understand and less complicated.
  
  The refactor step is crucial, but because your tests should be rapid (because we've mocked out all dependencies), you can refactor in very small steps and run the tests each time you make a small change. This way you can neaten up and tidy your code in small, safe, incremental steps, and you keep doing so until you are happy that it's easy to understand and give you the flexibility you need. Once you're happy, you move onto the next test.
  
  The entire cycle is quite quick actually - much of the complexity comes down to to learning the best way to test and how to mock out dependencies etc.
  
  Our suite of around 2500 tests takes about 15 seconds to run, but as I'm working on a feature I may only be running one test at that point, so it'll usually take less than a second to run the tests as I'm refactoring. Toward the end of the process I run the entire test suite to make sure everything still passes.
  
  I went from not believing to seeing this work in practice, and now I honestly don't think I can work anywhere that doesn't do TDD. I would be happy to teach other people how to do it in a company, but as mad as it sounds, to me now, not doing TDD is like saying you don't want to use version control. This has all changed in the last 6 months, having seen it work in practice.
  
  Here's a book I highly recommend: http://www.amazon.co.uk/Growing-Object-Oriented-Software-Guided-Signature/dp/0321503627
  
  I love the title of that book "Growing Object Oriented Software Guided By Tests" - this it the thing - working this way allows you to "grow" your software, and the tests really do guide you towards the solution you actually need (this is powered by the refactor step).

Rust is currently premature but that is only temporary. You don't have to restrict yourself to only a single language. Try it and see how it goes. Rustbyexample and the guide set the barrier pretty low as far as trying things out (although, windows support may currently only be mediocre). Rustbyexample in particular because everything can be run in place (without downloading anything). Concepts in one language extend to others so learning one helps with others.

---
Some of the following comments about Rust may also extend to other language like python. For example, python has a well organized and seemingly comprehensive documentation set on their main site which is a huge help. Other (newer) languages may also.

If you intend to learn it using the internet only (without printed books) then C++ may not be a good choice (in my experience). This C++ tutorial is pretty good but it is extremely brief compared to a book like Accelerated C++ which is compact, detailed, and covers much more material than the tutorial will (it may be difficult for a beginner though).

Rust doesn't currently have the luxury of referring to good books for instruction. So best practices and coding conventions are being baked directly into the compiler/guidelines pages (currently WIP)/the guide. This is really convenient compared to C++ where resources are much more scattered (aside from books).

Inevitably, if you try writing something though in either language, you will get confused/perplexed by something regardless of the quality of documentation. In those cases, having IRC for help is incredibly helpful. They can save you hours upon hours of mystification. The Rust IRC is extremely extremely helpful in that regard.

Rust has cargo which makes testing new things incredibly easy. My experience with C++ is you find a new repository you want to test, you download it and spend the next 2 hours trying to get dependencies in order so you can compile it. With cargo, you often run this and you're done:

git clone site:repository
cargo build

The C++ compiler is notoriously unhelpful also which extremely confusing especially to a beginner. It is commonly the case that it finds some issue on line 12. When you eventually find the error, it's on line 20 (the compiler points you to the wrong location). What kind of issue could it be...maybe you forgot a semicolon. In general, the rust compiler is much more helpful with regard to error messages. If there is a confusing error message, the compiler team would like to make it better. If you're still confused, there is always IRC.

C++ has a lot of IDE support which is very helpful for advanced projects. Rust currently doesn't (Python doesn't seem to either). This will probably improve in the future. Also, IDE support often costs money depending on the language.

Well I left school in 10th grade, travelled around and worked odd jobs for most of my 20's until one day while working a particularly shitty job I realized if I didn't make a change soon I'd be doing jobs like that for the rest of my life! So I went to university and studied something unrelated for a few years. Somewhere along the line I clicked a link on Reddit that said "Try Ruby!" and it took me to a site kindof like Code Academy with a tutorial for Ruby. I tried it out, got instantly hooked and started spending all my free time programming!

Eventually it got to the point where programming all the time made me fail a few units so I dropped out of uni. I enrolled in a programming course but that didn't work out either, so I decided to take six months and just teach myself programming full time. It was a really awesome time, I'd wake up every morning and work on my projects, take online courses and read programming books all day!

Eventually I started running out of money. I didn't think I was good enough yet but the fact that I was rapidly becoming destitute gave me the kick I needed to start applying for jobs. I was incredibly lucky in the fact that I ended up getting hired at the first place I applied. Apparently they chose me over the other candidates because of my "life experience" and the projects on my Github, although the fact that I was willing to work for peanuts helped as well haha.

That was over six months ago and I'm still really enjoying it. If I were to offer some advice it would be to just stick with it. Even when you doubt that you are good enough, or smart enough, or that this whole learn programming idea might not work out at all and you'll never get a job - keep at it! If you enjoy programming and put the effort in then someone, somewhere will give you a chance, and all you need is one chance.

Also, make sure to take projects through to completion and post them on your Github. One simple, well written project is more valuable then 20 half finished ones. Code your projects knowing that your future employer will be reading it and deciding whether or not to hire you!

To that end, I'd highly recommend Clean Code. This book really helped me, but I'd recommend reading it after you've written a project of your own. Then, as you read through the book, go through and refactor your code.

Finally, when you're thinking of projects, don't worry about trying to create something amazing straight off the bat. Pick anything that interests you, maybe scratch an itch, or even re-implement something that already exists. At the end of the day the idea does't matter as much as the fact that you've spent the time and effort to build something. If you look at my projects, they're boring as anything! But they were good enough to get my foot in the door.

All the best!

If you really want a book, there are a few that I've come across that I've liked and will suggest. Eloquent Javascript is a good one (it's free online!)

https://www.amazon.com/Eloquent-JavaScript-Modern-Introduction-Programming/dp/1593272820

Depending what you want to learn to do, also good:

https://www.amazon.com/Web-Design-HTML-JavaScript-jQuery/dp/1118907442/ref=pd_lpo_sbs_14_t_0?_encoding=UTF8&psc=1&refRID=YZ1P5N33ZRNPZG6SNM27

You just asked about books, but I would suggest unless you REALLY know you learn best by a book, I'd start with online tutorials (I liked Codeacademy) just to quickly get your feet wet. Codeacademy was a good way to learn the basic syntax you'll need. The books I've read, while great, tend to go deeper (not good at this stage IMO) than online tutorials which negate your "quickly" condition. Looking back, I didn't get a lot from the books until I was comfortable making code that did SOMETHING (and not much more) on my own. To me, that's the most effective way to learn quickly these days. It's easy to get sucked down a rabbit hole of feeling like you need to be an expert to start but looking back this is the plan that would have saved me a lot of spinning my wheels: 1st, do online tutorial (just 1 MAYBE 2); 2nd, then code SOMETHING (just to see you can make the computer listen to you); 3rd, When you feel like you can do something but don't understand exactly why or how it works THEN I'd get a book. That's when you'll get the most bang for your buck IMO. It's so easy to spin your wheels thinking you're one book or tutorial away from becoming an expert. It's cliche but the best thing really is to learn a little and then start making things. Take advantage of supportive programming friends or communities and don't be afraid to ask for help. You will learn more by making silly mistakes than if your code magically works the first time. Hope this helps!

I've been here a few times in my decade-long career.

To start, this isn't something that only happens to junior developers. Trying to approach a large existing code base can be a real challenge, even when you have lots of experience.

You're not going to understand the whole application in a day. Probably not even in a week, and probably not even in a month. On some large code bases, I've regularly run into new code *years* after I first started working on the application.

What I've found helpful is to pick a small part of the application; preferably one that's related to a feature you're trying to add or a bug you're trying to fix. Find what looks like the entry point of that small part of the application. In a web app, it could be a method in a controller class. Or it could be a method in a service class somewhere.

Once you've found that entry point, read through the code one line at a time, and try to make sure you understand what's happening at each point. If the method you're in calls another method/function, jump to that and go through it one line at a time. On code that's particularly complex, I'll grab some sheets of lined paper, and devote one sheet to each method I go through.

As I go through each method, I'll write out the whole thing by hand as pseudocode. In order to do this, I have to understand what the code is doing. Some people might find it more effective to do this in a text editor. I find that there's something about the process of physically writing it out on paper that really helps cement my understanding.

Now, the whole writing out part isn't worth it if you just need to go in and do a quick bug fix. But if you've been handed responsibility for a chunk of code and you'll need to understand it deeply, I've found it to be a useful approach. I think it can still be helpful even if you're not solely responsible for a piece of code, but will have to work on it heavily.

Start by deeply understanding one important part of the code. Then move on to understanding another important part. Soon, you'll start to see patterns and understand how these important bits of code fit together.

If you're not yet sure what the important parts of the code for you to understand are, then a good way to find out would be to look at the repository's commit history to see which files have the most commits over time. The places that change the most often are likely the ones *you* are going to have to change, so they are a good place to begin. You can find instructions on how to do this here:

https://stackoverflow.com/questions/5669621/git-find-out-which-files-have-had-the-most-commits

That assuming your code is in a Git repository. If you team uses Mercurial, you can look up instructions on how to do the same thing. If your team uses Subversion or heck, even CVS, you can probably accomplish the same thing. If your team doesn't use source control at all, then start spiking your morning coffee with rum or Kahlua because that will make your job significantly less painful.

For a look at using Git commit history to find the most important code - and the parts with the most technical debt - I enjoyed a book called Software Design X-Rays.

I've found the book Working Effectively with Legacy Code to be quite helpful in showing me different ways to approach an existing code base. Even if you don't apply all of the techniques the book suggests, I think it's still useful for finding out ways to find 'seams' in the code that you can use as points of attack when refactoring, adding features, or even just choosing a place to start learning a new bit of code.

If your employer will let you expense the cost of eBooks, you might find these interesting. If you can get access to Safari Books Online, both these books are available on there, along with a metric ton of great software development books. You might not need to pay for it - in my city, everyone with a public library account can access Safari for free. Maybe it's similar where you are?

Also, if you have a particularly frustrating day, feel free to come on Reddit and send me a DM. I might just have some useful advice. And if I don't happen to have useful advice on a particularly topic, I'll at least be able to come up with an on-topic smartass remark that will help you laugh and feel better about the code that frustrated you.

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!

I'll preface this by saying i've done a little bit of hiring and helped my boss look at candidates so i'll try to explain why interviews might not be coming your way.

Also be wary that i'm bias. I don't really understand the idea of a "boot camp"; You can't leave your job and become a teacher or a lawyer in 6 months, why is a developer different? I guess it just seems a bit offensive to just assume that the field has such a lower barrier to entry that you need next to no training to be work ready.

Ok rant over.

Some tips/advice:

• Go to meetups. Whether it be a nodejs or an express meetup find what is happening in your area and do your best to get along. You'll meet people and build up a bit of a network which will help gain some respect even if it's within small circles. Many of the people will have jobs and might be able to hook you up
  
• You currently don't get interviews because you're easy to discount from a list. If a business gets 20 applicants an easy way to narrow down is by degree/experience. As somebody without either you're just culled while the list is narrowed down so you probably never get past that first step. That's why the above is vital. Also if you're rejected somewhere try to find out why, follow them up and see if you can improve yourself. I know many people who've done comp-sci/programming at uni for 4+ years and still can't get a job, you're going to need to work hard to get ahead of these people
  
• Reason 2 people won't give you an interview is you're a big risk/investment. To get you where up to scratch in tech they're going to need to invest time in you, get you mentored, train you and help you which is $$$. The fact that you've dropped your previous degree and done a 6 month course I know my boss and I would raise a red flag at, how do we know you won't get bored in a year and after all the investment you just leave? Not saying you are like this at all but trying to explain what goes through peoples heads when they look at you
  
• Not sure what jobs are like in your area but it's probably worth looking at what tech is popular. Is C# the king of your area? Learn C#. Is python the most popular stack? Learn python. People get too caught up in trying to use something cool and current rather than something that will be useful. You can write beautiful code in any language.
  
• Read some good books. Most people have done a 3 year degree at uni to get to your position so in some aspects you'll be massively behind. Reading something like clean code(best book i've read on development) will help you get up to speed. Understanding how to get requirements is as important as being able to write the code.
  
• Make sure you're applying for the right positions, again I have no idea what you're looking at but you need to be looking as low as possible. Anything without the word junior in it they'll write you off instantly. Call some businesses and see if you can find out what they look for in a junior, maybe they like seeing more side projects etc.
  
• Contributing to open source is often a good idea, while some people hold it up as all important I think it's just good as it shows you can work with others and understand the idea of getting issues/features done and have the ability to come into a library/application and understand it enough to contribute.
  
  Portfolio critique:
  
  
• Nowhere does it mention what sort of job you are after(unless I missed it)? It just launches into name then skills, having something like "developer" or "web developer" I think would help me
  
• Skills are way too saturated, you can probably remove all the browser images, i'd take away ajax, and depending on your target audience html/css. If you call yourself a dev and can't do html/css you're not worth looking at
  
• Personally i'd put a contact form on there, you say "be the next chapter" but don't give me an "easy" way of getting in touch with you, drop a form in so I don't have to do more work
  
• All your projects look like assignments from your course(they might not be). I'd try to diversify those because I just assume when I look at them you've had help or have not actually done it yourself and is something i'll often question with our applicants

I don't know of any one source that teaches "good testing principles". There are thousands of sources and Sturgeon's law is working against you. A few sources are predominantly good, most have bits (often the same bits) of genuinely good advice in-between chapters of bland, uninsightful repetition, many are appropriations of popular acronyms by closely or distantly related professions (no, you're not "testing" a requirement specification, you're just reviewing it), and some sources are just plain bad.

I had an opportunity to attend Dan North's Testing Faster course and would strongly recommend it. In my case it was more helpful for formalising my own experience than learning concrete new things but other attendees did absolutely "learn new things". He made a point that "TDD" and "BDD" are both inaccurate names and that something like "example-guided development" would have been far more honest; he recommended a book, I think Specification by Example, as a good resource to that end (and noted that that name, too, is technically inaccurate). He also confirmed that Cucumber is a solution looking for a problem.

Test Driven Development: By Example by Kent Beck is a classic, and as far as I can remember, decent. It's maybe a little old now, and it definitely misses some subtle points about maintainability of automated tests in general (or perhaps rather, doesn't really address that).

I've skimmed Code Complete 2. I don't remember it in detail but my overall impression of it was that the sooner it becomes irrelevant the better, because that would signify our profession maturing (if not quite reaching maturity). A lot of its contents would be considered basic by contemporary software development standards and that's a good thing. I don't remember what it says about testing. One thing in a very late chapter (33.8?) stuck with me, though: that seniority has little to do with age and your approach to software development will be formed early on.

Working Effectively with Legacy Code by Michael Feathers is excellent, perhaps the most practically applicable one here.

Sandi Metz is famous in the Ruby community for speaking on this topic and there are recordings on YouTube. From what I've seen her material also mainly addresses beginners but it's fast and easy to consume and her form doesn't bother me the way Martin's does.

One piece of advice I picked up from one of those mostly-mediocre sources had to do with naming in tests, trying to capture the essentials. If you're relying on a particular property of a piece of input to test behaviour, make sure this is evident. Conversely, if any input would satisfy, avoid drawing undue attention:

fn bees_can_fly() {
let some_bee = ...
let bumblebee = ...
let dest = ...

assert fly(some_bee, dest);
assert fly(bumblebee, dest);
}

fn bees_can_pollinate() {
let some_bee = ...
let flower = ...

assert pollinate(some_bee, flower);
}

Testing is about developing confidence. There are many kinds of testing and many things to develop confidence in. For automatic tests it's more about checking (arguably not "testing") that you retain correctness in the face of continuous change. Automatic tests that obstruct that change or compromise your confidence are not helping you and should be rewritten or removed. Reliability of tests is usually more valuable than coverage, for instance.

I. BACKGROUND INFORMATION

• What was your major in college?: Computing science.
  
• What was your career/vocational journey like once you graduated from college?: Turbulent.
  
• How did you prepare for entry into your profession?: Co-ops, reading dozens of articles and books about how to be a programmer.
  
• How did you locate & secure your current job? : Twitter, surprisingly.
  
• What specific degrees or experience is necessary for this kind of work? : "Be a good and unusual programmer." CS degrees are always helpful but not necessarily requisite.
  
• If you were to redesign your college experience what would you do differently? : One time I took Software Engineering II instead of Algorithms II, and I still regret it. Universities don't do practical stuff well.
  
  II. CURRENT ROLE INFORMATION
  
  
• What is a typical work day like for you? Tasks throughout the day?: Shower, commute, standup, lunch, coffee, programming, commute, take-out, draw comics, watch TV with girlfriend.
  
• Do you have opportunities for varied schedule, such as telecommuting; flex time, or job sharing? : Yes.
  
• What are the most interesting or challenging aspects of your job?: I learn new things all of the time, because I've never worked in a job where I have to maintain cloud infrastructure or work with mobile devices.
  
• What are some of the difficulties and frustrations of your work?: Maintaining cloud infrastructure, working with mobile devices.
  
• What are the most significant changes facing your field/organization?: We're getting bigger, fast, and we're not sure how to attract good talent, filter out bad talent, and keep things from becoming a bureaucratic nightmare.
  
  III. YOUR INTEREST IN THE FIELD
  
  
• What experiences would you recommend I have (coursework, internship, volunteer, campus involvement, etc.) to prepare for a job in this field? : I could answer this ALL DAY. Get a CS degree, it's good for you. Don't do unpaid internships, it's bad for everybody. Try to get a commit into an open-source product that you think is cool.
  
• What does it take (personality traits, strengths, and competencies, experiences) to be successful in this field?: If you're in any way different from the herd of young white males, you need an incredibly thick skin and a lot of personal resolve, and you're going to deal with a metric tonne of stupid entitled bullshit from people who have really only ever learned computers and little to nothing else. If you're young and white and male, uh... you're pretty much set, but try to be kind to others.
  
• What do I need to have on my resume to be considered for employment in this field?: Programming languages. No food stains.
  
• Can you recommend resources that offer helpful information about the field? : CodingHorror, Joel on Software,
  
• What are some related occupations that I might investigate? : Tech Writer, DevOps/Sysadmin, Data Analyst,
  
• What professional organizations would you recommend? Publications to read? The ACM releases some surprisingly good magazines. I like Linux Voice quite a bit, too.
  
• What specific advice would you give a person entering the field? Be kind to others. Don't believe in the meritocracy. Socialize with your peers. Join the student society.
  
• Can you provide me the names of two or three other people in this field who might talk with me and provide additional information? May I use your name? : No.
  
• Would you be willing to review my resume if I emailed it to you? : Probably not?
  

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.
   
   

I'm still not an expert yet, so I can't promise that my recommendation is the best path. Looking back at where I struggled and what worked for me, I'd say the best order to learn programming from the beginning is:

• Basic problem-solving
  
• Basics of programming
  
• Introduction to your chosen language
  
• Software design and object-oriented programming
  
  If I was helping someone start in programming, I'd have them go through the first chapter of Think Like A Programmer for basic problem-solving techniques, then Optional Bits – which my friend wrote – for programming basics, then Codecademy to learn the syntax of the language they're interested in (Treehouse is a good alternative if Codecademy doesn't have the language you want or if you learn better from video lessons).
  
  Problem-solving is the best place to start because it's going to drive how you look at every program you write. Good problem-solving techniques also help build confidence, which is really important for a beginner – lack of confidence really held me back my first year of coding. I also found it easier to understand the different courses I took and books I read once I got a better grip on how to solve problems.
  
  After that, learning programming basics should always come before learning a specific language. It makes learning new languages easier and, combined with problem-solving, helps you to understand how to put together a program together. If you can do that, then it doesn't matter which language you pick; the syntax is just filling in the blanks.
  
  Learning a language at this point would just be figuring out what keywords the language uses – you won't have to learn both programming and language-specific syntax at the same time. A basic introduction like Codecademy is probably good enough for this step if you've filled in their blanks with the other steps first.
  
  Then software design will help you learn things like OOP, coupling and managing dependencies, single responsibility, etc.
  
  Again, I'm still in the early stages of programming myself, so I can't promise this is the best way to do it. In retrospect, I think that order would have worked a lot better for me when I first started. Hope it helps!

I'm going to go against the grain here with my recommendation. I'm a guy who was in a similar position years ago. I've since transitioned from web development to game programming and have working knowledge of 7+ languages.

Dude, don't sweat these feelings you're having. You're just at a wall. We all reach different kinds of walls in this career and they're really the best thing ever. It means you're about to jump ahead in skill by at least 10x. You just got to find the trigger for it. Be patient and try different things. Go check out Udacity and do some courses on there. Also this is the time to start reading books. Not just any cheap book you find. Good books that will give you the perspective of an industry professional. Books like JavaScript: The Good Parts, Code Complete, The Pragmatic Programmer, or The Little Schemer. Also it doesn't matter what language the books are in to enjoy it. 98% of all programming languages are the same anyways, which you'll soon learn. For the most part, they just have moderately different ways and syntax to do the same thing.

I would recommend not switching platforms from the web. One of the most important skills guys like us can have is seeing where technology is heading and betting on the right horse. It's very clear that webapps are going to be even more important in the future. You can already make desktop apps with web technology naively in pretty much all major OSs now.

I say learn JavaScript front and back. Read JavaScript: The Good Parts and JavaScript: The Definitive Guide cover to cover. Once you learn JavaScript it'll be very easy to transition to any C-based language, which is most of them. In fact I credit JavasScript for giving me the basics to jump to just about any language comfortably and pick it up in a few weeks.

After that, learn a good server side language like Java, Python, or C#. (C# is in very high demand, and has many applications) Or learn all three and you'll be very well positioned career wise. Well, make sure to get some experience with SQL too for good measure.

Also if you want to have a good challenge instead of being bored on those easy things, like drawing shapes, why don't you try Udacity's fine WebGL course? Jumping in the deep end isn't bad as long as you don't expect it to be easy.

Hello! /u/RageBill has already provided a great response, but I still wanted to add a couple of my own thoughts.

1. If you are brand new to programming I would encourage Python as your first programming language to learn as it is relatively simple to pick up and has a lot of online resources.
   
2. Programming requires a base level of intelligence that I personally think most people have. I think it mostly requires learning to think like a computer.
   
3. There is an open source MIT course that I would recommend. There are more recent ones, but the basic principles of programming don't change.
   
4. There are a lot of books, I think that two books that may be helpful for getting started would be this one and this one
   
5. If you know English I think you'll be fine.
   
6. Python, Java, Golang
   
7. Python first, then Java I think :)
   
   I would also suggest seeing if your highschool or university offers any computer science courses, and if so, sign up for the beginner class!
   
   Best of luck!
   
   Edit: most people will go back and forth all day on which language you should learn first, which are the most useful, etc. If you’re just starting out it can be easy to become overwhelmed with decision paralysis. If you’re just starting out you’ll want to pick a language based on how easy it is to pick up, and the level of support the community at large provides the language (how easy is it to find answers to problems on google?).
   
   Especially if you’re brand new, the goal is to learn the basics and fundamentals and not necessarily wrestle with more advanced or “obscure” technicalities or concepts.
   
   For these reasons (among others), the vast majority of entry level university computer science courses stick with python. If you google search the top ten most popular programming languages python is almost always on that list, along with Java.
   
   I would recommend starting with python while you learn the basics and fundamentals of programming and computer science.
   
   Of course these are just my thoughts and opinions and plenty of people will disagree. The point of what I’m trying to say is: don’t spend too much time debating which programming language to learn first, just pick one! You can always learn more later!

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!

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 thing I noticed upon looking into your code, and I do apologize if it sounds a bit harsh, please forgive me: It's very disorganized, you have non-constant globals (nasty), and very sparse comments (not useful when trying to figure out code, try to at least have simple descriptions of what a function does), your map is hard coded in game (not bad for simple example, but try reading it from a file later on). I'm also curious why you're doing

struct inputstate curstate = {false, false, false, false, false, false, false};

within main, calling

inputstate curstate = //blah

should be sufficient. Calling struct will create a new structure, although maybe in this case it's making an inputstate. Either way, it's an odd line. Putting struct before inputstate is unnecessary.

I strongly suggest you learn more about C++ and Object Oriented programming, as it will solve these issues with organization and global variables you're having, if you use the ideas correctly. Since it seems like you do know some programming, I would suggest Accelerated C++.

Now, on to your questions:

> Is there a problem with using an IDE?

No way, and don't let anyone tell you there is. Visual Studio is an insanely powerful IDE, and I use it myself and absolutely love it. If you're comfortable with VS there's no need to switch because people say it isn't 'proper'. However, learning to use a simple text editor, g++ on command line and makefiles will be valuable, even if only as a learning exercise. That is why you should try to learn it. I know both, but prefer working with VS, intellisense is too good to deny hahaha.

> Do people only use vim/text/command line

It's personal preference really

> How to generate make files

Cmake can do it, and you may be able to do with an extension from VS, but I'm not sure

> Quickstart tutorial for vim/make

Look up the g++ compiler for linux (on windows minGW) and get vim running. Although I prefer Sublime Text 2 for text editing.

> Advantages of VS

Tons, if you learn the IDE it is another very powerful tool. My personal favorite thing in VS is the fantastic code completion, I've not found anything on par with it from any other editor.

> Can I do int a = b

Yes. I'm a bit confused with your wording though, if you're implying that a would equal b at all times, that is false. a = b at the time the expression is evaluated. If you want a to reference b you need a to be a pointer to b's address like so

int a = &b

Then doing

a

Will return the value of b at the time you've called *a

> Where can I get more help?

See the recommended book above, when you feel you've learned the concepts in there well, move on to a more advanced book listed on SO's C++ book list

I hope this covers your questions

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 say this all the time, but: Who would have thought that in the 2012, the greatest OS war of our day would still be BSD vs SystemV (iOS vs. Android)?

Generally, a focus in Windows is going to take you into corporate IT, building internally-oriented tools to support organizations. Here you'll want to learn bout VMWare, the full Microsoft stack, and look closely at tools designed for Enterprise support. There's less demand in this arena for nix, but also less chance to make a real impact on the world. Sure, there's something to be said for helping maintain the compute clusters inside of banks, or using Altiris or similar tools to manage hundreds of desktops for gigantic offices. I've done this myself, but I didn't have very much fun.

For my money, where you want to be is in web operations, building the systems that drive popular websites. Think about Instagram, Etsy, Netflix, companies that move enormous amounts of data around on the cheap, with relatively tiny staff. Read the blogs by the infrastructure team behind Etsy, and you'll realize quickly that these guys are geniuses.

Here you'll want to learn about how to interact programmatically with cloud compute providers, such as Amazon AWS, Rackspace Cloud, and the OpenStack providers that are starting to pop up, like HP. (A cloud provider is generally not just virtualization, but virtualization coupled with an API. It may sound small but it's a big difference!)

Here's some reading: If you want to learn a lot about nix operating systems, check out The Armadillo Book and The Practice of System and Network Administration.

If you're interested in learning web operations-oriented sysadmin, which is a VERY interesting place to be, also check out The Art of Scalability -- well, the first 2/3 anyway -- and the followup book, 50 Scalability Rules.

And especially, especially read and understand this, because there won't be many web-oriented companies still in business by 2014 that don't follow this process: Continuous Delivery.

Good luck! You picked a GREAT time to get started in the industry. The 00's were pretty boring by comparison. :)

EDIT: I KAN SPEEL

From Data Classes and Sealed Types for Java:

>Digression -- enums
>
>If the problem is that we're modeling something simple with something overly general, simplification is going to come from constraint; by letting go of some degrees of freedom, we hope to be freed of the obligation to specify everything explicitly.
>
>The enum facility, added in Java 5, is an excellent example of such a tradeoff. The type-safe enum pattern was well understood, and easy to express (albeit verbosely), prior to Java 5 (see Effective Java, 1st Edition, item 21.) The initial motivation to add enums to the language might have been irritation at the boilerplate required for this idiom, but the real benefit is semantic.
>
>The key simplification of enums was to constrain the lifecycle of their instances -- enum constants are singletons, and instantiation is managed by the runtime. By baking singleton-awareness into the language model, the compiler can safely and correctly generate the boilerplate needed for the type-safe enum pattern. And because enums started with a semantic goal, rather than a syntactic one, it was possible for enums to interact positively with other features, such as the ability to switch on enums, or to get comparison and safe serialization for free.
>
>Perhaps surprisingly, enums delivered their syntactic and semantic benefits without requiring us to give up most other degrees of freedom that classes enjoy; Java's enums are not mere enumerations of integers, as they are in many other languages, but instead are full-fledged classes (with some restrictions.)
>
>If we are looking to replicate the success of this approach with data classes, our first question should be: what constraints will give us the semantic and syntactic benefits we want, and, are we willing to accept these constraints?

Umm, I think Python is a good language to start with. It's forgiving and low on boilerplate code. I haven't read it but Learn Python the Hard Way by Zed Shaw is supposed to be decent (and it's free online). I didn't like Learning Python published by O'Reilly. I'd just read reviews on Amazon if Learn Python the Hard Way isn't working for you. Whichever you end up with, I recommend typing all examples from the book into the computer by hand. Something about doing this really helps make things stick in your head. You'll also make the occasional typo and have to debug your program which is something we programmers spend more time doing than any of us care to admit.

I think it is important to try to think of something you want to make and have it in mind while you are learning the language. It can be any software but I recommend a video game. They are really good for this because you can just think up a simple concept or implement your own version of an existing game. Having a goal makes it so you are constantly solving the problems you will encounter while trying to reach that goal which is the most important part of programming (more so than learning the syntax of the language). This is actually the highest rated Python book on Amazon and is all about gamedev with Python.

After you've learned Python to the point where you are comfortable (no need to master it), learn other languages to grow as a programmer. Once you've gotten a couple languages under your belt it's actually really easy to learn even more languages (unless it's a very odd language like Haskell, Lisp, or Brainfuck). The problem solving skills you've acquired often work in any language and you learn some new techniques as you learn new languages.

• Accelerated C++ is the go-to these days for C++.
  
• The C Programming Language is often recommended for learning C but it's pricey and there are dozens of good books on C to choose from.
  
• Head First Java gets recommended a lot for learning Java.
  
• C# In Depth is very highly rated and happens to be written by the guy with the largest score on StackOverflow (a kind of Q&A for programmers).
  
• The D Programming Language I really enjoyed.
  
• Programming Ruby 1.9 is often recommended but it felt more like a reference manual to me. There are higher rated books on Amazon.
  
  

Depending on what you want to learn:

PYTHON SPECIFIC

You mentioned building websites, so check out the flask mega tutorial. It might be a bit early to take on a project like this after only a month, but you've got time and learning-by-doing is good. This'll teach you to build a twitter clone using python, so you'll see databases, project structure, user logons etc. Plus he's got a book version, which contains much of the same info, but is good for when you can't be at a computer.

The python cookbook is fantastic for getting things done; gives short solutions to common problems / tasks. (How do I read lines from a csv file? How do I parse a file that's too big to fit in memory? How do I create a simple TCP server?). Solutions are concise and readable so you don't have to wade through loads of irrelevant stuff.

A little while down the road if you feel like going deep, fluent python will give you a deeper understanding of python than many people you'll encounter at Uni when you're out.

WEB DEV

If you want to go more into web dev, you'll also need to know some HTML, CSS and Javascript. Duckett's books don't go too in depth, but they're beautiful, a nice introduction, and a handy reference. Once you've got some JS, Secrets of the javascript ninja will give you a real appreciation of the deeper aspects of JS.

MACHINE LEARNING
In one of your comments you mentioned machine learning.

These aren't language specific programming books, and this isn't my specialty, but:

Fundamentals of Machine Learning for Predictive data analytics is a great introduction to the entire process, based upon CRISP-DM. Not much of a maths background required. This was the textbook used for my uni's first data analytics module. Highly recommended.

If you like you some maths, Flach will give you a stronger theoretical understanding, but personally I'd leave that until later.

Good luck and keep busy; you've got plenty to learn!

Hey man. I'm currently doing what you are trying to do. I'm in my 4th-ish month now and having a blast. Right now I'm diving into javascript and I'm finding that that's where I'm having the most fun. Even though it's a fun time, I have to stay disciplined because sometimes I do fall off the horse. I try to make sure that I am studying 5 times a week 8 hours a day, but I don't always hit that mark. Pretty much trying to make it a full time job. I feel like I'm not quite job ready yet, maybe 2-3 months of learning and building projects. Thats the thing, just keep building websites. Here's a list of project ideas and follow FreeCodeCamp and do their challenges.

I recommend looking at FreeCodeCamp. Its free and they have a good curriculum and the best part are the Javascript challenges and mini projects they have you do and there is a pretty solid community and Gitter chat. Check out Jon Ducketts HTML & CSS and Javascript Books. Eloquent Javascript, from what I'm told, dives into JS a little deeper and I'm reading that currently. Lastly, I would also subscribe to something like Treehouse. It's $25 per month and they have a huge library of videos that are pretty good.

edit: I want to add also that there really are a ton of resources out there. So if one of the resources I suggested doesn't work for you, dont sweat it, you will be able to find another. But I do recommend learning from multiple resources instead of just leaning on one.

It can be kind of overwhelming diving into all of this stuff so please feel free to ask if you have any questions. Feel free to PM any time

I generally agree with the other replies that a vanilla computer science degree is better than a game degree, but let me use the example of the University of California Santa Cruz (UCSC) game degree to offer a balanced comparison.

At UCSC, the only difference with a computer science versus games degree is one class in the senior year. The fundamentals of both degrees are identical - you take the same math, physics, and programming in the game degree as you would in the CS degree. Only in your senior year does it differ, where as a games major you do a 1 year elective working on gaming group projects using Unity. If you did vanilla CS instead, you would use that year to take something like operating systems, artificial intelligence or databases. Deciding which one is a better fit for you partly depends on your philosophy of the purpose of school:

• Ivory tower camp - If you feel that a university is best served teaching theory and fundamentals, rather than masquerading as a trade school, then you might agree that learning operating systems or databases in a "pure" manner, without worrying about production concerns like working in a group, would be the best use of your time while you have the privilege of being in school.
  
  
• Emphasis on practicality - If instead you concede that while theory is nice and well, the practical needs of the working world sometimes take precedence, then you might feel that the year of working on gaming projects with others and being able to point at a concrete example of something you did would be time well spent in being able to land that first job.
  
  You can see this difference of philosophy being played out in not just the debate over a gaming degree program, but in things like the programming language of choice for first-year students, where some schools lean toward the practical (UCSC uses Java and C++) and some toward the theoretical (MIT traditionally used Scheme and now uses Python).
  
  Specifically at UCSC, I would say the pros and cons are as such:
  
  Pros:
  
  
• Get to study and spend class time on what is presumably your main interest - game development.
  
  
• Dedicated time to a group project that at graduation, you can cite on your resume and be able to say, "I made that."
  
  
• Possibly make contacts with game industry veterans through the program.
  
  Cons:
  
  
• Spend a one-year class being forced to work in groups and deal with the messiness of production tasks rather than being immersed in 'pure' theory like in a more typical computer science course.
  
  
• Slightly negative connation among the uninformed of having the words "game degree" on your resume and possibly having to defend that your fundamentals are as sound as a vanilla CS major.
  
  The first question you should ask yourself is whether the school you're looking at has a comprehensive undergraduate education and a good reputation, like UCSC, or if it's a specialized trade school like Fullsail or DeVry (stay away) with a bad reputation. Not all game schools are bad - both Digipen and Guildhall at SMU are notoriously challenging programs and in my experience working with a handful of their graduates, I found them to be quite competent. Allen Chou will be graduating Digipen with his first job at Naughty Dog (which was Naughty Dog's first time they've hired someone straight out of school rather than someone with industry experience, though it should be noted that Allen earned a previous bachelor's in electrical engineering before attending Digipen). And USC's game school is well known for having produced Journey developer thatgamecompany, among others.
  
  As for the poor working conditions known at most gaming companies - yes, in general you will work more hours for less pay in the gaming industry than you would outside it. Yes, the industry is rife with constant layoffs. It is likely you will need to move all over the country and possibly world as you chase jobs throughout your career. It's up to you to decide if working on games and with other game developers is important enough to you that it's worth that sacrifice. Many people don't find it worth it, and they are not weaker for choosing another path. It's a personal decision of how much it means to you to work on games; alternatives are arguably more sane.
  
  For working at the kind of companies you mentioned like Bethesda and Blizzard, you will need to be an expert at C++. Because C++ is such a large and complicated language to first tackle, I recommend learning C first. My book of choice is C Programming: A Modern Approach by KN King, which is also highly recommended in the C programming FAQ. Or if you prefer a shorter book, many people have learned from the C Programming Language by Kernighan and Ritchie.
  
  For learning C++, there is only one book you need to know to start with: C++ Primer by Stanley Lippman, which is also the #1 recommendation of the C++ FAQ and highly reviewed elsewhere. You do not need to worry whatsoever about C++ becoming obsolete by the time you graduate. But you do have plenty to worry about mastering the language, because there is a lot of material to cover.
  
  I'm a moderator at /r/TheMakingOfGames and I would recommend perusing some of the videos there that show behind the scenes of development companies (though arguably, the bright side of development). Some examples:
  
  
• Behind the scenes of God of War 3 with the programming team
  
  
• Since you mentioned Blizzard, read Patrick Wyatt's articles on the development of Starcraft. He was a lead programmer at Blizzard before leaving to found ArenaNet and making Guild Wars.
  
  
• Nine examples of dirty programming hacks to fix baffling bugs is a Gamasutra article that might give a glimpse at the harried side of game development, when under pressure and lacking time.
  
  
• Naughty Dog's lead programmer Jason Gregory talking about their interview process and culture

Sure, like most people, I started with Python. I didn't start on codeacademy though, I started on program arcade games.

By the way, I should mention that at the time, I was a night manager at a Hostel so I got LOADS of free time to myself, and then when I got home I had even more free time so there was lots of time to practice.
In the first 3-4 months I learnt the basics of functions and classes and how to use them. After that time had passed, I dug deeper and bought Learning Python and read that a lot. I learnt pretty quickly about the cool things about Python like list comprehensions, anonymous functions (Lambdas), operator overloading, all that stuff. By the way, that book is not a beginner's book, it's a book on pretty much everything about Python

I kept programming in my spare time, I made a lot of crappy things and gradually my code got cleaner and easier to maintain. I made things that interested me, like a MIDI parser, a reddit bot that converts images to ascii Python C#, a bruteforce directory scanner and some other stuff. As you can see, I was pretty busy. This is what's important. By all means, do Project Euler and participate in Daily Programmer but don't expect it to nail you a job. That stuff is useful, but a lot of those are just algorithms, not programs that will impress the person interviewing you (who might not be technical in the first place).

Eventually I just sort of 'got' Python, and decided to learn other languages that interested me. For some reason, that was C. Choosing to learn C was a really good choice but at the time I found it too difficult so I gravitated towards slightly newer languages like C#.

When I started to think my programs had some sort of quality to them I applied for jobs. I looked at job listings and if I saw a requirement that I didn't have i.e. (Version Control) then I'd learn it.
The caveat with learning Python at the time, was that it left me pretty useless (bare in mind I live in Wales in the UK, not uber-progressive,technology wise). The majority of the listings wanted PHP, or VB.NET (yes you read right)

Eventually I got my lucky break with a duo of awful businessmen, they didn't know what they wanted and I didn't know how to deliver, but I tried and I learnt a butt-load as I tried to make their product. Their product was an entire website (frontend, backend and DB) that was to start off small and grow internationally, and they wanted it in 10 weeks... Needless to say, they didn't keep me on (surprise surprise) but with that experience I managed to nail a decent job with other developers using a similar set of skills. By the way that job with businessmen was in VB.NET, not an awful language but why not C#?

The new job is good, I create backends for websites, create frontends from photoshop files that are handled by our designer and I also create plugins for an in-house CMS (Think Joomla and similar stuff). This current position is in PHP, it has it's quirks - naming standards vary wildly, the $, foreach loop is backwards in syntax, -> instead of ., and a bunch of other stuff, but it's easy to use.

As it stands currently, I'm working on trying out different architectural patterns. The good thing about the position I'm in is that it's lots of small projects so I can do something new with each new project. Maybe I'll try a different design pattern, maybe I'll go MVP over MVC, I'm pretty much free to learn and do as I want since there is no codebase (well there is a codebase, but I can still try out new methods) for a module that doesn't exist.

TL;DR

• First 3-4 Months learnt basics (functions, classes, loops)
  
• 5 Months onwards - Read 'Learning Python' and made programs
  
• 6 months onwards - Tried out new languages
  
• 8 Months on - basic SQL queries and commandline stuff
  
• 12 months on - Applied for jobs, a lot.
  
• 16 months on - Got first job with bad businessmen
  
  
• 19 months on - Got second full time permanent position and it's fun
  
  
  Hopefully I answered what you wanted
  
  

I know how you feel, my college was practically the same. Here are some resources that helped me through:

https://www.youtube.com/playlist?list=PLlrATfBNZ98dudnM48yfGUldqGD0S4FFb

TheCherno has a really nice C++ tutorial. Might not be the best on modern standards, but if you are looking for a place to start, this is a good one, really explains stuff nicely.

​

https://www.amazon.com/Programming-Principles-Practice-Using-2nd/dp/0321992784/ref=cm_cr_arp_d_product_sims?ie=UTF8

https://www.amazon.com/Primer-5th-Stanley-B-Lippman/dp/0321714113/ref=cm_cr_arp_d_product_top?ie=UTF8

These two so far is the most recommended books I could find in this thread, Programming Principles has more nice exercises and is what I personally used, but to be honest just go with the one that clicks for you. read through the preview chapters if you could find them and choose the one you like.

​

https://codeforces.com/

https://www.hackerrank.com/dashboard

https://www.codewars.com/

I think this is what helped me the most at the start if you don't know what to do, solving problems really helps you get comfortable with the basic language syntax, programming logic and is a lot of fun.



Lastly, Google search is your best friend, seize it. Don't be afraid of making a lot of mistakes because you are going to make many AND be willing to explore! Because chances are, there is always going to be a better modern way to do something. Try to know the advantages and disadvantages(Important) of each way if you could, it all may seem so cryptic at first and confusing(it probably is) but it will all click someday.

​

Learning C++/Programming is a life-time learning, Good luck on your journey!

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
  
  

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

The biggest hurdles I had motivating myself to work on a project was never coding itself. It was always setting up the compiler, IDE, environment, finding something to work on, etc. The biggest one for me is blank page syndrome.

You don't need to convert to linux if you don't want to but it is good to get some experience in it if you can. I spent sometime setting up a headless Ubuntu server to manage my torrents and be network storage. It took a lot of time starting from scratch but the experience has helped me out.

http://www.ubuntu.com
http://www.reddit.com/r/linuxquestions
http://ubuntuforums.org/

If you want to continue with Java (which is a good choice). I believe the most popular IDE is Eclipse. It has great plugin support and has been used everywhere I've been. You can use it for development on android phones as well if you want to play around with mobile development.

http://www.eclipse.org
http://developer.android.com/tools/sdk/eclipse-adt.html

If your college is like mine, most of the later courses in computer science will not involve much coding at all but will involve a lot of math and knowing popular solutions to common problems (sorting, searching, graph theory, combinatorics). If you feel like you need to brush up on a language, there are a lot of web resources and books to help you.

http://www.codecademy.com
http://www.amazon.com/Effective-Java-Edition-Joshua-Bloch/dp/0321356683
http://www.amazon.com/Head-First-Java-Kathy-Sierra/dp/0596009208/ref=sr_1_2?s=books&ie=UTF8&qid=1382580434&sr=1-2&keywords=head+on+java

Computer science and software development is a broad field which makes scaling it daunting at times. The only way to make it less daunting is to just dive in and do it. Pick a project and work on it. You will encounter problems you have no idea how to solve and that's great because now you've found something you can learn (usually through Google).

Solve problems in manageable bits. If you try to implement your whole program at once it will seem impossible. Implement small portions of your project at a time. Trying to create a Java chat client? Just work on getting some basic sockets to work and build a library you'll be able to use going forward. This will make the goals seem manageable and help you modularize your code. It helped me with not feeling overwhelmed about my project's scope.

I hope I didn't sound condescending. I just wanted to share some things that have helped me. I don't think you are in a bad spot, you just need to stay motivated and find some things to work on to help you learn. If you have any specific questions I can try to help out, but there are other people on this sub that are far more knowledgeable than me.

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.

If you want a serious book recommendation: Learning Python 5th Edition by Mark Lutz. It's a monster at 1600 pages but to say it's thorough is an understatement. I got the ebook so I can quickly search through it on my phone. Even though I wouldn't consider myself a beginner anymore, I find between this book and the Python Cookbook I find answers to most of my problems (unless they're related to a library).

You can also read Learn Python the Hard Way (my introduction to Python 2). Which is free but not anywhere near the scale of Learning Python. As a warning, there's some coarse language used in it.

If you don't know any Python -- and this will probably stir the pot a little -- learn Python 3. BUT learn how to make it Python 2 compatible. Sure, you'll give up things like advanced tuple unpacking and yield from (to name two off the top of my head) and you'll probably have to use six but when the day comes that you can fully move your library to just Python 3, you'll be thankful.

If you feel comfortable enough with Python to begin approaching a web framework, I would personally recommend Flask. I'm sure quite a few people would disagree and they probably make valid points. But Flask is easy to start with:

from flask import Flask

app = Flask(name)

@app.route('/')
def index():
return "Hello World"

if name == 'main':
app.run()

Miguel Grinberg (you'll see him float around /r/Flask and some of the other Python subs occasionally) has both a great blog series and a great book on building Flask projects. It's not the end all be all of Flask knowledge and honestly, I'd like see more written on working with bigger projects, but given Flask is only 4 years old I'm not surprised.

For Django, I've heard lots of good things about Two Scoops of Django but I've not read it (though, I need to at some point).

I'm unsure about other frameworks like Pyramid or TurboGears or WebPy.

You'll also want to have working knowledge of HTML (not hard), CSS and Javascript (much harder). And getting chummy with libraries like Bootstrap and JQuery/Angular/whatever is probably a good idea, too.

There's also specific concepts you'll want to be familiar with depending on where and what you work on: things like REST, JSON, Ajax, CSRF, etc.

I like this book for C++ if you want to learn C++. Python is easier though and most people start with Python. I like the book Learn Python the Hard Way (it's actually a pretty easy book lol) but there are quite a lot of books that are good for Python. (and I'm like 99% certain there are free versions of these books available on the web)

That's probably a good way to see if you like coding. Personally I love it 'cause it's a lot of problem solving, and then forcing a computer to do your evil bidding work.

Then for the chemistry part. I think everybody on the planet and their brother loves this book (it's also free on google). That will help you learn about the theory behind the software.

I also think you should talk to a professor who does computational work to let you toy around with it. I've had two advisors now in comp chem, and I get the feeling if a student came to either of them and said they wanted to play around with the software and see what comp chem is like, both of those professors would probably have been happy to set them up with an account to a supercomputer and show them a few tricks to setting up jobs, running simulations/calculations, viewing data, etc.

IMHO,

step 1: Read https://www.amazon.com/Pragmatic-Programmer-20th-Anniversary-2nd/dp/0135957052/ref=dp_ob_title_bk

step 2: Read https://realpython.com/python-pep8/ and https://docs.python-guide.org/dev/virtualenvs/

step 3: Write a REST API which takes arguments from the URL, uses these arguments to run some predictive model of your creation, and then returns the result; since you already know Python, I'd recommend using Flask, there are many free tutorials, just google it. If using Python, I highly recommend using PyCharm (the free community edition is enough) over Jupyter or Anaconda, the latter will let you do many bad things which would trigger a red warning in PyCharm (such us doing import in the middle of the file).

step 4 (optional, but recommended): Learn the basics of Java (this tutorial should be more than enough https://www.tutorialspoint.com/java/index.htm ) and read https://www.amazon.com/Clean-Code-Handbook-Software-Craftsmanship/dp/0132350882

step 5: Write a publisher application which reads a csv, xml, or json file from disk (for bonus points: from someone else's public REST API for data, for example https://developer.walmartlabs.com/docs/read/Search_API ), and turns the data contained within into a list of python dictionaries or serializable objects (btw, read up on serializing, it's important), and then sends the results into a kafka or rabbitMQ queue. I would strongly recommend sending each item/record as a separate queue message instead of sending them all as one huge message.

step 6: Learn how to use cron (for bonus points: Airflow) to make the application from step 5 automatically run every second day at 8 am

step 7: read the closest thing in existence to being the data engineering book: https://dataintensive.net/

step 8: Write a consumer application which runs 24/7 awaiting for something to appear in the queue, and when it does, it calls your rest api from step 2 using the data received from the queue, adds the returned result (predicted price, or whatever) to the data, then runs some validation / cleaning on the data, and saves it in some database (SQLite is the easiest to have running on your local computer) using an ORM (such as SQLalchemy).

step 9: Add error handling - your applications should not crash if they encounter a data-related exception (TypeError, IndexError, etc.) but instead write it to a log file (as a minimum, print it to the console) and continue running. External problems (connection to the database, for example) should trigger a retry - sleep(1) - retry cycle, and after let's say 5 retries if it's still dead, only then the application should crash.

step 10: For bonus points, add process monitoring - every time your application processes a piece of data, record what category it was in a timeseries database, such as influxdb. Install grafana and connect it to inlfuxdb to make a pretty real-time dashboard of your system in action. Whenever your application encounters a problem, record that in influxdb as well. Set grafana to send you an email alert whenever it records more than 10 errors in a minute.

Step 11: More bonus points, add caching to your application from step 2, preferably in Redis (there are libraries with helpful decorators for that, e.g. https://pythonhosted.org/Flask-Cache/ )

I'm assuming you are familiar with Spark, if not, then add that to your learning list. A recommended intro project would be to run some aggregation on a big dataset and record the results into a dedicated database table allowing for fast and easy lookup (typical batch computing task). You could also rewrite the applications from points 5 and/or 8 to use spark streaming.

I also heavily recommend learning how to use docker and kubernetes (minikube for local development), this is not only super useful professionally, but also makes it much easier to do stuff such as running spark and airflow on your home computer - downloading and running docker images is way easier than installing any of those from scratch the traditional way.

One crucial advice I can give is the mindset difference between data science and data engineering - unlike in data science, in data engineering you normally want to divide the process into as small units as possible - the ideal is to be processing just one [document / record / whatever word is appropriate to describe an atomic unit of your data] at a time. You of course process thousands of them per second, but each should be a separate full "cycle" of the system. This minimizes the impact of any crashes/problems and maximizes easy scalability¹. That is of course assuming that the aim is to do some sort of ETL, if you are running batch aggregations then that is of course not atomic.

¹ As an example, if your application from step 5 loaded all the data as one queue message, then the step 8 application would have to process it all in some giant loop, so to parallelize it you would have to get into multi-threaded programming, and trust me - you don't want that if you can avoid it (a great humorous tale on the topic http://thecodelesscode.com/case/121 ). You also have to run it all under one process, so you can't easily spread across multiple machines, and there is a risk that one error will crash the whole thing. If on the other hand you divide the data into the tiniest possible batches - just one item per message, then it's a breeze to scale it - all you need to do is to run more copies of the exact same application consuming from the same queue (queue systems support this use case very well, don't worry). Want to use all 8 CPU cores? Just run 8 instances of the consumer application. Have 3 machines sitting idle that you could use? Run a few instances of the application on each, no problem. Want the results really fast? Use serverless to run as many instances of your app as you have chunks of data and thus complete the job in an instant. One record unexpectedly had a string "it's secret!" in a float-only field and it made your app crash? No problem, you only lost that one record, the rest of your data is safe. Then you can sit back and watch your application work just fine while the colleague who decided to use multi-threading for his part is on his fifth day of overtime trying to debug it.

Getting much off-topic here, but:

Programming is kinda like art. It doesn't matter if you're using oils or watercolours or crayons or charcoal or pencil or a Biro, just do it. You can pick up other art-forms later, and it'll be much easier to once you're learnt one. What's more important is that you start, have an interest, and are willing to practice and learn.

That said, it'll likely be easier to pick a language that has a good beginner community around it as a first language. Python is an example with a huge beginner community. Perhaps you might prefer to start with an interactive tutorial like the free interactive version of How to Think Like a Computer Scientist, or you'd prefer to read a book like Python Programming for the Absolute Beginner, or perhaps both! Doesn't matter.

Once you're reasonably comfortable with a language, you can pick up more. A language you might want to familiarize yourself with eventually would be C, since it's practically the lingua franca for systems-level programming. If you're interested in emulation, you will eventually want to become familiar with the assembly language for the types of CPU(s) you're interested in emulating.

Good luck.

I'm a computer science undergraduate, so I can only tell you about things I've gone through in my curriculum. Which course is right for you depends on what you want to learn.

edit: Whoops, missed the part where you said you were looking for an ebook. In the software design patterns section below, I link to the canonical book on design patterns. Also, Donald E. Knuth's The Art of Computer Programming is a book I haven't yet read, but is known to be a must-read resource for computer scientists. Lastly, check out the Think series by Green Tea Press. It's a growing selection of free, accessible ebooks on major computer science topics.

Algorithms and Data Structures: This topic is about what makes one program run more quickly than another. For example, how much faster is one sorting algorithm from another? Or, what is the best way to store a list of items on the byte-level if I expect a lot of insertions and deletions from the list? This course is one of my favorites, since it really helps get you into the computer scientist mindset. Some people have difficulty with this topic, though, so be prepared.

Assembly programming: If you want a better understanding of what happens when you compile a program, try learning how to program a few easy programs in a simple assembly language like ARM. Assembly programming is basically on the level of what the CPU understands: move this data from RAM to a CPU register, perform this simple arithmetic operation, save this value in this register to RAM. It also helps to learn how GCC compiles a C program to assembly code, and then to binary. There should be plenty of educational resources online about this.

Software design patterns and software engineering: This was broken into two courses at my university. The first course, Design Patterns, was about common patterns that are seen when programming in modern languages, particularly (but not limited to) object-oriented languages. Check out the book on design patterns by the "Gang of Four." The second course, Software Engineering, is about how to work effectively in groups on software projects. This is mandatory learning if you want to work at a tech company!

Computer Systems Organization: I just finished this course. Perhaps this is more what you would be interested in, since you said you were interested in the low level stuff. Computer systems organization is basically about how computer systems work on the level of circuits pushing electrons about, and the pros and cons of modern CPU designs. You learn what happens on each clock tick of the CPU. Knowledge of assembly programming is basically required before you learn about this. This topic is more on the Computer Engineering side of things, but it is important for computer scientists to know as well.

Network Programming: If you would like to understand how the Internet works, how data is transferred between networks, or how programming ties into networking concepts, this is the class for you. You learn things like how packets are sent across networks, how to calculate the time it takes to reach another host on a network, and how the whole system works that lets you connect to the internet, find another computer, and send data to it.

Operating Systems: I haven't taken this course yet (next semester!), but as far as I know, this course is about fundamental concepts that guide operating system design. This includes things like handling hardware/software interrupts, memory paging and multiprocess task switching. There are probably more things that I just haven't learned yet.

Those are some of the major subjects I have come across so far. Hope it helps get you started out!

Before anything, I want to ask if you're really going to work with C, whose support in visual studio is really poor, or if you're going to work with C++. My question is: are you sure you'll be working with C? Isn't it C++?

I've seen a lot of people say C when they mean C++. Given how bad is the C support in visual studio, I imagine this may be your case (i.e. someone told you that you'll be working with C programming using the Visual Studio IDE).

If this is really C, then I don't have much to give you, but if you'll be working with C++, then there are some to consider.

I know there are books targeted at teaching C++ together with the Visual Studio tooling. I don't know if they're any good though.

Microsoft has its channel9 website. It has several videos covering how to use Visual Studio and also several videos on C++. Here are some of their video series which seem good:

• https://channel9.msdn.com/Series/cplusplus-language-library (one of the teachers here seems to be Kate Gregory, who has given an interesting talk (IMO) at cppcon about teaching C++)
  
• https://channel9.msdn.com/Blogs/Sam/C-Language-Programming-with-Visual-Studio-2010-Ultimate-Pro-or-VC-Express - This one seems to be about C (not C++) on visual studio.
  
• https://channel9.msdn.com/Shows/The+Knowledge+Chamber/C-A-Language-for-Modern-Times - In there you'll also find some "isolated videos" like this one (like the previous one), which don't seem to be part of any series but are interesting anyway.
  
• https://channel9.msdn.com/Events/GoingNative/GoingNative-2012 - In here you can find videos about this GoingNative conference, which is pretty much about C++ and the importance of native code. This is fairly advanced, but that's the sort of thing you can find as well.
  
• https://channel9.msdn.com/Series/C9-Lectures-Stephan-T-Lavavej-Core-C- - This is a series of videos by one of the people at MS who is part of their C++ standard library team (Lavavej). It covers core C++, which is pretty much the C++ language (I've watched some of these lectures and found them really helpful).
  
• https://channel9.msdn.com/Series/C9-Lectures-Stephan-T-Lavavej-Standard-Template-Library-STL- - Like above, by the same person, but this one is about the C++ standard library (whereas the previous one is about the core of the C++ language)
  
• https://www.youtube.com/user/CppCon - This is the youtube channel for the cppcon. You'll find tons of presentations in here. Several of them actually can be watched by a beginner C++ programmer (this is specially in your case given you're already a programmer) and be understood. Some of them can help you learn about C++ programming.
  
  A book I really liked is Accelerated C++, by Andrew Koenig and Barbara Moo (https://www.amazon.com/Accelerated-C-Practical-Programming-Example/dp/020170353X/). It's not very up to date considering how C++ changed since this book's publication date, but it's still good as an introduction IMO.
  
  For modern C++ introduction book, you can take Bjarne's A Tour of C++ (https://www.amazon.com/Tour-C--Depth-ebook/dp/B00F8CWGOS/).
  
  All of these materials I've posted in here are supposing you're interesting in getting up to speed fast. I believe Kate Gregory's course and Lavavej's two series will really helpful.

> Is this a good way to highlight the code I used to build on top of the scaffold?

I did see it originally, I wasn't entirely sure that's what it was though. As to if it's a good way? It's a two-edged sword. The good side is that I do get to see your code, the bad side, however, is that it's not really what a README is for. I guess it's just indicative of how Github's being used lately-- remember that Github is supposed to be a repository of git projects, not really a portfolio. The README is supposed to be "how can I use this", or "how can I contribute to this".

It might just be my own personal bias in that negative side. I do appreciate the code sample. Some more critique if you don't mind? Note, I'm a professional developer, about 15% of my time is spent on node.js so things I say might be nitpicky but knowing the idioms can really help when it comes to writing JS code in a team.

$scope.vote is a really big function. The work is also nested in a setTimeout as an anonymous function. In general, you should break functionality out into small, bite-size functions-- maybe no bigger than 5-10 lines. This allows for maintainability, too, because smaller functions can be unit tested whereas large functions, especially anonymous functions, cannot be.

There are magic numbers a lot of places. i; i < 4; i++, what is 4? It's the number of photos to show, right? Name that constant, so it's easy to read. Also, super small thing but the idiom is usually for (var i = 0; i < 4; i++) { .. }, seeing i being defined elsewhere led me to believe it wasn't zero or it was dynamic (but it wasn't).

In fact, variable naming is a big thing too.

if (page.photos.royalty === 4) {
var k = 3;
} else {
var k = page.photos.royalty;
}

What is k? What are 3 and 4?

if (photoArray[0].url === instagramPhotoUrl || photoArray[1].url === instagramPhotoUrl || photoArray[2].url === instagramPhotoUrl || photoArray[3].url === instagramPhotoUrl)

This is a mess. First thing, you're only using the else block, so check out DeMorgan's Laws. Basically, !(a || b) === !a && !b. Secondly, you can write it better in a number of different ways, the easiest of which (and the way I'd probably write it) would be to create a separate function call that looped over your photoArray and returned true if instagramPhotoUrl did not exist in your [[array]].url. Once it returned true, you can set your tempObject, and then break. Note, you should use break instead of setting uui = 20 for readability.

Finally, $http.put('/api/v1/Pages/' + page._id, page).success(function(data) { });. If you don't need to do anything with the returned promise, you don't need the success function. Degenerate functions clutter up the code. The documentation for it is here: https://docs.angularjs.org/api/ng/service/$http#put

I'm not trying to be a dick here, please don't think I am. I'm a regular here in /r/learnprogramming because I love helping people, and especially people who program in one of the top languages I know. You can ignore everything I said if you want, I'm only trying to help. Code readability is among the most important things you learn when you start developing on a team. In fact, I'd recommend this book: http://www.amazon.com/Clean-Code-Handbook-Software-Craftsmanship/dp/0132350882 . It really opened my eyes when I read it, hope it can do the same for you.

> My main question is this: is the market for Javascript developers in SF similar to that in other cities and will I find similar levels of success?

SF has a huge boner for node.js, so the JS developer community there is huge. There are also a number of jobs, probably the most out of any city, for modern web frameworks (node and rails are gigantic).

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!

I think I get what you're saying, and I was in a spot like this for a while myself, although for me it was more about trying to figure out "how do I debug my code?" - everything's focused on the language itself, and not so much on the peripheral skills. I eventually found resources that helped and I started making progress, so let me pass on some advice.

First up, if you're getting stuck with your IDE, trying getting rid of it for a while. Instead, just use a text editor and invoke your compiler and run your programs through the command line. This will force you to figure out what you don't understand about the build process, and once you do begin to understand it and grow beyond it, you'll be able to go back to your IDE and more easily figure out how to do all the new stuff you just learned in there. The other benefit is that after a few rounds of compiling godawful novels of commands to include and link everything in a decently complex project, you'll be desperate for a better way and have a motivation to learn about Makefiles (or automated build systems in general) which you mentioned not really understanding, but by this point you'll be intimately familiar with why they were created. To learn about them, Google is really your friend - there are a ton of tutorials online and some of them are decent, along with plenty of templates and such to get you started.

But that's only part of your question, I know. For the more general stuff, I have two major suggestions. For general 'peripheral' coding knowledge, I'd actually recommend Effective Computation in Physics. It's aimed at academic researchers and focuses on Python, but those things don't really matter; the best parts of it are the ones that aren't language-specific or domain-specific at all. Because it's written for people who may be trained as physicists (or biologists, or chemists) first, it works up from ground zero and actually explains things like unit testing, debugging, project organization, version control, and everything you need to have a self-sustaining small-to-mid-sized project, which is what it sounds like you're struggling with right now. My other suggestion is that if you're confronting more abstract issues, like design, you could check out The Pragmatic Programmer, which has a lot of good suggestions for avoiding bugs and increasing reusability and ease of maintenance. It's also targeted at small-to-mid-sized projects, but I find most design books for industry-scale stuff to be almost impossible to get through if you're not actively working on a large design team for a real-world application (though if you need that level of sophistication, there are some options if you poke around Amazon).

Apart from those things, you might also consider directly searching for some of your questions, like "how do I organize a software project directory" - I've found surprisingly helpful mini-tutorials from random university CS sites that way, usually as part of the intro or syllabus for a programming class. Oh, and if you're having trouble even getting started on what you want to do, see if you can't break it down further - make a toy engine that does one thing, then add one more thing, then add something that ties those pieces together, etc...

Anyway, hope something in here helps you, and good luck!

Let me start by saying good code is code that solves the business problem at hand. For someone that really cares about internal quality of software that was a hard thing to accept.

You didn't quite define what you mean by "good" in your question, so I assume you mean adherence to SOLID principles. I've long thought like this too but realized adherence to some metric by itself is not very helpful, exactly because you end up in situations where your code is overdesigned, or worse, has the wrong abstractions.

What helped me figure out where the line is was stepping away from SOLID and focusing on Test Driven Development (TDD). TDD is great because it forces you only to write as much code as you need, not more not less. But in order to write testable code you'll have to apply SOLID principles. So you end up with code that reaches just the abstraction level you need to solve the business issue you're trying to solve.

The interesting aspect of this is that there's no clear universal line you can draw and say "this is too much design!" or "this is too little!". What I've observed is that there's just the right amount of design, and interestingly that's, at least in my opinion, a function of how much change you expect. Writing a 100 line hack to do something that you'll never change again is perfectly good code - it does what you need it to, it has certainly no wrong abstractions or over design. But as with most software, change is inevitable and with change internal quality becomes more important. If your code has good internal quality changing it is easier. The better the internal quality, the easier, within limits. So finding the line is an interesting exercise to balance the cost of design vs the expected rate of change.

If I may recommend some reading here:

• Sandi Metz' blog post on the cost of wrong abstractions and I highly recommend her other blog posts
  
• Growing Object-Oriented Software, Guided by Tests helped me figure out how to think about software quality and how to better design it

I'm a software developer with about 5 years of experience , and I used to have the same sorts of problems where I would over-commit to getting work done and under-deliver. To summarize, I changed to where I only commit to tasks that will take 1-2 days or less at a time, and I make it very very public what I'm working on in order to manage both my and my team's expectations. Here are the gritty details (ymmv of course):

1. I got my team to start using a ticketing system and explicitly define what we are working on with explicit acceptance criteria for each ticket. That way you know where your finish line is. There other huge benefits to this but its outside of the scope of your personal workflow. This of course takes buy-in from your team, but at the very least start a board on trello with "todo", "in progress", and "done" columns, and try to keep the number of items "in progress" to a minimum, and work on them until their finish. A cardinal sin here is to move something from "in progress" back to "todo". This thing you're setting up is called a kanban board
   
   
2. I break the work I do into 1 or 2 workday 'chunks' on our team board, so I don't lose interest or chase another issue before the work I'm doing gets finished. Keep in mind that some workdays, depending on how heinous your meeting schedule is, a workday may only be 4 (or less :[ ) hours long. An added bonus to this is that its easier to express to your team what you're working on, and after practice chunking up your work, you and they will reasonably be able to expect you to finish 2-3 tasks a week. There are always snags because writing software is hard, but in general smaller tasks will have a smaller amount of variability.
   
   
3. As I'm coding, I practice test-driven development, which has the benefit of chunking up the work into 30 or so minute increments. While I'm making tickets for the work I do, i explicitly define the acceptance criteria on the ticket in the form of tests I'm going to write as I'm coding ( the bdd given-when-then form is useful for this ) , so the flow goes write tests on ticket -> implement (failing) test -> implement code to make test pass -> refactor code (if necessary)
   
   
4. This is a little extreme but I've adopted a practice called 'the pomodoro technique' to keep me focused on performing 30-minute tasks. Basically you set a timer for 30 minutes, work that long, when the time elapses take a 5 minute break. After 5 or so 30-minute intervals, you take a 20-30 minute break. There's more to it, but you can read more here. Again, this is a little extreme and most people don't do things like this. Here is the timer I use at work when its not appropriate to use an actual kitchen timer (the kitchen timer is way more fun though). There's a build for mac and windows, but its open source if you want to build it for something else.
   
   
   Side note: in general I limit my work in progress (WIP limit) to one large task and one small task. If there are production issues or something I break my WIP limit by 1 and take on a third task (it has to be an emergency like the site is down and we are losing money), and I make sure that whatever caused the WIP limit to break gets sufficient attention so that it doesn't happen again (usually in the form of a blameless postmortem ) . If someone asks me to work on something that will break the WIP limit by more than one, then I lead them to negotiate with the person who asked me to break it in the first place, because there is not way one person can work on two emergencies at the same time.
   
   Here's some books I've read that lead me to work like this
   
   

• [Kanban: successful evolutionary change for your technology business] (https://smile.amazon.com/Kanban-David-J-Anderson-ebook/dp/B0057H2M70)
  
  
• The DevOps Handbook: How to Create World-Class Agility, Reliability, and Security in Technology Organizations
  
• The Phoenix Project: A Novel about IT, DevOps, and Helping Your Business Win
  
• Continuous Delivery: Reliable Software Releases through Build, Test, and Deployment Automation
  
  As you may notice, the latter 3 books are mostly about how to quickly and reliably ship software. Developer workflow is a big part of getting that to happen, and many people have some of the same problems we do.
  
  I could go on like this for hours because I fucking love kanban. Feel free to PM me if you want to chat about your specific problems. There is figuratively nothing that I would rather talk to internet strangers about.
  

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)!

> Another thing I want to know is which programming languages/tools I should read up on. In my experience I've pretty much only used Java, Git and some basic HTML/CSS and Javascript. I know this is largely dependent on which team I end up on, but I might as well read up on something in the few weeks between graduation and my start date (early July).

AFAIK, we only use Java for the Android versions of our mobile products (MyChart for mobile; and Haiku). Most of our applications use HTML/CSS/JS, though, with use of these technologies increasing as we move away from VB6.

We do not use Git; instead, we use SVN. Maybe spend an hour learning how SVN differs from Git, if you'd like. But a lot of our SVN workflows have an extra layer of automation and hand-holding on top, so realistically, a deep knowledge of SVN isn't particularly useful or necessary for most developers.

I assume you've heard we use VB6 and M. Our internal training materials for these languages is superior to anything you'll find outside Epic. Don't bother hunting through an antique books store for tomes on either of them.

If you're bored and want to learn some job-relevant stuff, consider the following:

• C# and ASP.NET. You'll very likely be trained in C# during your first month or two here, but it doesn't hurt to have a head start. You'll also be trained in the framework that we implement on top of ASP.NET. You never really learn about the ASP.NET layer directly, which is a bit unfortunate; I think it would be good for you to do some reading about that.
  
• TypeScript. We'll have started switching over from JS to TypeScript by the time you get here. You may not understand how awesome this is. Trust me: it's mindblowingly awesome. TypeScript alleviates the pain of development for the web browser in a way that almost no other language/framework does (you have to start getting into esoterica like Emscripten to do any better than TypeScript, and then you start running into impedance mismatch issues).
  
• Learn how to think from a testing-first point of view. I estimate that less than 1% of our code is covered by some kind of automated test (a unit test, an integration test, whatever). This is part of why we have such an enormous QA division (not that QA is entirely replaceable by automated tests, obviously). I don't recommend learning any particular framework (we have internal resources for the frameworks we use). Just learn how to write testable code; how to write good tests; how to develop with testability in mind; etc. Genuine test-driven development is not really feasible for most of the projects I've looked at, but even small steps in the direction of testability help.
  
• Related to the previous point, learn how to deal with legacy code. This is not a skill you are likely to have fresh out of college, but it is a skill you will need in most software companies, and especially at old ones like Epic. The standard tome on this is "Working Effectively with Legacy Code". If you can find a cheap copy, I recommend buying it and skimming it. You probably won't really get it until you actually start working with our code, but better to be prepared than not.
  
• Find a spiritual guru and have him teach you how to attain inner peace. This will help you not rip your eyeballs out every time you have to deal with VB6.
  
  > I guess my main concern here is that I just want to know if I should expect to be putting in 60 hour weeks.
  
  I have never worked a 60-hour week at Epic (unless you count time spent sitting in airports / on airplanes as part of the workweek, in which case I've worked one 60-hour week). My typical week is 35-45 hours (which, granted, is on the low end; 40-50 is more typical).

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

Hi, thank you. :)

You should learn C++ using C++ Primer by S. Lippman. (Not to be confused with C++ Primer Plus which was linked here before). Just be sure to learn modern C++, not "C with classes"! Then I recommend reading Effective C++ and Effective Modern C++ by Scott Meyers. Effective Modern C++ has some awesome examples of modern C++, but it also contains pretty hard edge-cases, so be aware of that.

The best way to learn Lua is by this book. It's very well written and I consider it to be not only the best book about Lua, but one of the best programming books ever!

Lua Users wiki is also very useful and contains lots of resources and sample code.

I also recommend checking out SFML Game Development book which is well written and contains some game programming patterns. You'll find it very useful even if you don't use SFML.

Oh, and Game Programming Patterns is a great read too.

___

Now, how much experience should you have with C++ to make games with it? That's a hard question! You should just start learning it and try making some small games with SFML or Corona. You'll see what you have to learn for yourself. :)

I learnt from these 2 books
Web Design with HTML, CSS, JavaScript and jQuery Set
https://www.amazon.co.uk/dp/1118907442/ref=cm_sw_r_cp_api_i_Y1MQCbH3QGBW6
I highly recommend them, they aren’t really tutorials on how to code but goes into excellent detail on everything you need to know. They do include code examples and website concepts such as design, how to structure, ease of use etc...

If you want to progress from this, you can start looking at databases and collecting user data etc... the PHP practice is a bit outdated but it is a very good tutorial book to get started
PHP & MySQL In Easy Steps
https://www.amazon.co.uk/dp/1840785373/ref=cm_sw_r_cp_api_i_C7MQCb9JHJP5G

I’m also hoping you’ve came across w3 schools at some point but just incase you might want to have a look at this website as well, it’s great for information all website related
https://www.w3schools.com

This was my path and I’ve done 2 courses of web design at uni and there isn’t much more they were able to teach me that I hadn’t already learnt from those books. Obviously a bit more advanced stuff but tutorials and resources are always available online for that.

If you have anymore questions don’t be afraid to ask! Like I said I’m still a student who self taught all this and it’s not my job but I hope it will be in the future for me too, so hopefully a professional might be able to offer you better advice :)

I don't think there is anything you need to cover before the class, if it's a good class. However, I would suggest the following -- not before class, but probably before, during, and after class:

• If the class goes reasonably well, pick up this book. It's a collection of best practices for Java. You will learn bad habits in class, and this will help. (It's not necessarily the class's fault, it's that Java warps your brain in all the wrong ways.)
  
• For Java, learn Eclipse, and learn it well. You may find you prefer other IDEs, but Eclipse is among the most popular, it's open source, and Google builds things on it, like the Android and Dart SDKs.
  
• Learn source control. It doesn't matter which you pick up first -- in my opinion, SVN was easier to learn, but Git is the best all around, once you get past the learning curve. And once you learn a distributed VCS like Git, you can use it on class assignments -- which I recommend doing, whether it's required or not. (And always make sure you tell your VCS what to ignore. Like, ignore .class files.)
  
• That said, learn to do things without the IDE, so you understand what the IDE is doing for you.
  
• Extra credit: Learn other JVM languages, like JRuby, Clojure, or Scala. In particular, learn at least one with a good REPL. This may be confusing, because you're using more than one language at once. But it also helps when you want to explore how a Java library actually works, in real time. I haven't found a good Java interactive shell, which is why I use JRuby's IRB for that.
  
• Google any term I used above that you don't understand.
  
• My experience with a community college was much worse than my experience with a university. If a university isn't practical, I understand... If it fails you -- that is, if you find yourself asking the professor questions that they can't answer, or if their answers don't make sense, don't be afraid to come back here or to StackOverflow.
  
• If the in-class projects aren't big enough, start one out of class! Practice is what makes you a better programmer and better with the language, and the best way to practice is to give yourself a project that you're actually interested in. Work your way up from Hello World, but if you find yourself not wanting to practice, you probably need an exciting project.
  
• Don't stop with Java. Learn other languages, learn other ideas. That said, when you find something you're really into, specialize and master it -- but you'll still always need to be stepping outside of that. Keep in mind that your skills in all likelihood will become obsolete. You don't need to chase every programming fad, but you do need to stay on top of the pulse of the programming community.

I have to say linux profiling has seemed to me to be a fast-moving target, meaning you'll get scattered results if you search. But, there's this which seems up-to-date: http://en.wikipedia.org/wiki/Perf_%28Linux%29

Then there's Ulrich Drepper's 'What every programmer should know about memory' (long series, but worth skimming at least, if your code is memory intensive. At least read about cache-coherency and cache-lines): http://lwn.net/Articles/250967

But the biggest thing is to get the algorithms right. Sounds like you want image-processing books. Also, GPUs are just absolutely the right place to do this stuff, and there are probably libraries already out there for it; speaking of which, did you know about OpenCV? It even has some stuff implemented on the GPU (as CUDA). I root for OpenCL, but the fact is, almost everything out there, libraries, and books, is written for CUDA.

> All the software is written in C++: I am interested in unlearning bad habits and writing better and easier to maintain code.

I suggest Effective C++ if you haven't read it yet. Also, Herb Sutter's 'Exceptional C++' series (a 'digest' version is C++ Coding Standards: 101 Rules, Guidelines, and Best Practices).

Never read it myself, but I hear 'Code Complete' is good. Maybe, too, Martin Fowler's Refactoring book - it shows lots of little awkward, problematic patterns and what to do about them, with good discussion. Each cleanly separated out - it will refer back and forth, but you can read the bits one-at-a-time. Good bathroom reading :)

Re: algorithms: Ugh, I don't know. It sounds like you'll want some metric data structures, dealing with space as you do. There's http://www.amazon.com/Foundations-Multidimensional-Structures-Kaufmann-Computer/dp/0123694469, and I don't know what else, maybe some Knuth? But probably, you should learn undergraduate-level data structures and algorithms, Big O stuff. Any used CS Data Structures + Algorithms book should help with that.

Do not fear spending money, as a former boss said, "books are free" ie they pay for themselves if they save you an hour's debugging later. Good luck!

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.

The Anti-Pattern###

What you've got here is similar to the "Arrow anti-pattern", but may also be part of the "Redneck conditional" anti-pattern. Its hard to tell without seeing the rest of the code.

Here's an article that covers the redneck pattern. It links to some great resources for fixing the Arrow issue at the end. This Youtube Presentation: The Clean Code Talks -- Inheritance, Polymorphism, & Testing and a pretty good overview on Coding Horror: [Flattening Arrow Code](http://blog.codinghorror.com/flattening-arrow-code/
)

This Is Normal###

I end up with this pattern a lot on my first pass through prototyping a program. Sometimes its faster to write something quick and dirty - generating code as you think of it (redneck conditionals and all), then go back through and pull out redundancies and rework things to avoid !isTrue lines and other less than good code.

I think this has to do with how spoken language needs to be compiled into thought 'just-in-time'. We front-load our conditionals simply because the mind is not good at keeping more than a page full of words running at any given time. Its only natural to think about problems this way.

This is why languages like Perl and Scala appeal to me - it lets you say things like "do this thing, unless that" and sometimes feels like poetry.

Let it Haunt you at Night ###

Never be comfortable with code like this. Good developers strike a balance between writing good code, and shipping code.

Being a great programmer is 90% sweat, and another 90% discipline. Taking pride in your code means you don't release what you've written into the wild unless there is a good reason for it. If you can help it, don't let prototype code become production code. When in doubt, go with the mantra of "fuck it, ship it", but don't sweep bad code under the rug. Ignoring the problem of technical debt will come back to haunt you one way or another..

And remember: "Always code as if the person who ends up maintaining your code is a violent psychopath who knows where you live."

Why It Is Important To Fight It###

If there is never time (or demand) to clean up this awful code, all you end up doing is building up technical debt, eventually leading to the lavaflow antipattern and other more disastrous patterns.

My rule of thumb for keeping things DRY is the rule of three.

Do this enough, and in time you will start to see opportunities to rewrite your code as you do it. Basically you start to think like a programmer and metaphorically 'speak the language'.

What Happens When You Don't###

Fighting this way of programming is what elevates a good programmer to a great programmer.

The truth is that this is the default/naive style that comes out of procedural programming. You can become so good at this style of coding that you become an Expert Beginner
.

These expert Cowboy Coders look amazing to management. They able to sling code around fast and brute force their way through code like a mad man. Many 'expert' programmers, even ones who've been in the industry a long time, fall back on copy/pasting code so often that when they end up copying the same bug through out their codebase they don't even take a second thought. This style of development seen normal to them, and being riddled with bugs is just the cost of doing business.

Entire organizations can find themselves full of these types of programmers to the point that the culture shifts from wanting clean code to one that ends up being little more than a drawn out death spiral.

From my experience, this style of coding is very easy to do in languages like COBOL and FORTRAN and can be the default style in larger codebases that were minted before Structured Programming took hold. This lead to the often quoted line by Dijkstra: "The use of COBOL cripples the mind; its teaching should, therefore, be regarded as a criminal offense.".

This can lead to organizations shooting themselves in the foot and losing their best programmers. The codebase becomes riddled with bugs that seem to be near impossible to stamp out, and the ticket workload becomes so intense that you end up with the Crunch Time organizational anti-pattern just to fight the effects of technical debt. I can't see a self-respecting programmer lasting long in such an environment.


----

I've been trying to find organizations that are passionate about their code quality, and serious about their company culture. If you know of one, please let me know.

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.

In addition to what others have said, you need to learn some programming, web and scripting languages + frameworks:

I would make sure to know/learn following in order:

1. HTML / CSS : online: https://www.codecademy.com/ OR book: https://www.amazon.com/Web-Design-HTML-JavaScript-jQuery/dp/1118907442/ref=sr_1_3?ie=UTF8&qid=1543201752&sr=8-3&keywords=html
   
2. Javascript: same as above, some javascript frameworks would not hurt, Angular, Node, etc..
   Note: while learning web stuff, try to learn as much as you can about how the web works, technologies used, etc. Your networking knowledge should help here
   
3. Python: checkout blackhat python book, https://www.codecademy.com/ for basics
   
4. SQL: https://www.codecademy.com/ then mini project: Make a small app in python that utilizes SQL database, all running in cloud AWS or similar. Using frameworks and such
   
5. C++ or C: If you feel comfortable go to C, otherwise I would start with C++ or even C#/Java first to get a grasp of the these programming languages that IMO are easier to learn at first. Python will help here.
   
6. Other things such as bash, Perl, ruby will come in handy, but you can learn them as you go later.
   
   To practice things security related:
   
   

• https://pentesterlab.com/ : black Friday deal active or huge student discount always on: This is a nice set of mini-challenges to start with.
  
• https://www.elearnsecurity.com/course/penetration_testing_student/ : Nice beginner start
  
• https://www.hackthebox.eu/ : To get your hands dirty
  
• Help with hackthebox: https://www.youtube.com/channel/UCa6eh7gCkpPo5XXUDfygQQA (ippsec), would also recommend VIP subscription
  
• https://www.virtualhackinglabs.com/labs/penetration-testing-lab/ : harder boxes
  
• https://www.offensive-security.com/information-security-training/penetration-testing-training-kali-linux/ : Endgame for basics, if you get this cert, from here it's towards advanced certs and bettering yourself. Debatable opinion though :)
  
• Next things: Reverse Engineering, Malware Engineering, Assembly Language learning, Writing your own scripts and tools while staying LEGAL :).
  
  Black Friday deals:
  
  https://www.reddit.com/r/AskNetsec/comments/9yza56/2018_list_of_black_friday_netsec_resources/
  
  https://pastebin.com/aLBfQT6H
  
  ​
  
  ​
  
  Extra books: https://nostarch.com/hacking2.htm (The art of exploitation) (not a super beginner but it's on sale now)
  
  Disclaimer: I am a software engineer, so the security field is new to me as well but for now I am doing hackthebox :).

I read your question as having two parts:

A) How do I get better at taking a project and breaking it down into smaller tasks?

B) When I encounter an error, how do I get better at finding the cause of it?

There are a few answers to this-- a toolbelt of techniques.

1. Writing stuff down in an organised way.
   
   Basic, but very powerful. Your brain can only hold so much at once. If you keep a notebook by your side or a text file open, you can dump your thoughts into it and give your brain an advantage in keeping track of the things you learn. Better yet, when you run into an error, approach it like the scientific method: Form a hypothesis and come up with ways to test that hypothesis.
   
   
2. Debugging tools like print() and import pdb;pdb.set_trace()
   
   These are ways to look at "what is my code currently doing?" and "what is the value of this variable right now?". They let you gather the information.
   
   Debugging: The 9 Indispensable Rules is a great book on how to use these tools effectively.
   
   
   
3. Automated Tests
   
   When you encounter an error, write a little program which reliably triggers the error. Here is a tutorial on how to use py.test, a tool for writing such programs. The Goat Book is a longer intro to writing Automated Tests.
   
   
4. Modular code design.
   
   You want to split your code up into parts which make it easy to understand. That way, when you see an error, you can more easily read the code where that error comes from. How do you do this? A great book to start with, once you've gotten the ability to write some short scripts, is A Philosophy of Software Design. Another great book is Clean Code. You'll notice that these books sometimes disagree with each other. That is because this technique is a big part of what makes up the craft. Welcome.
   
   
   
   ----
   
   Note: I'm found a bit hard to understand the last sentence. I think that it got mixed up with the sentence before it.
   
   I hope you don't take this as condescending--perhaps you had to dash off a response on your phone. But I'm willing to take the risk of condescension because this advice is far more important than the question of python-vs-java:
   
   Alongside learning to write in a program, it is also important to make a strong habit to write English with solid grammar. Why?
   
   
5. The skill of noticing when some written structure seems "off" and the compulsion to fix it will serve you well when writing and debugging code.
   
   
6. As you learn to program, you're going to need to ask questions of others. When you do this, you want to empower your answerer as much as possible so they can succeed in to helping you. Read this blog post by Julia Evans
   
   
7. As mentioned in #1, the skill of "read this code to find the structural problem" and "read this paragraph to find the structural problem" are very similar. So, if you ask a question without having taken the time to re-read and fix up your grammar, then readers are going to think you also haven't taken the time to carefully read the code you're asking about. So, you'll find it harder to get help.

> I just delivered a 20k lines/~50 pages project in AngularJS/Web API/PhoneGap without a single automated test.

Oh my... a few things:

First, I all but guarantee there are unforeseen consequences hiding in your code. I'm pretty sure you'll end up debugging something at some point that will boil down to "oh, I didn't consider an empty list", "oh, I got that boolean comparison wrong", etc... Sometimes it can get more complicated, as in "oh, I didn't consider the case that this concurrent routine terminates before that other concurrent routine". Testing is all about throwing out your assumptions about how you think the code works and validating how the code actually works. In a way, you are debugging now so someone doesn't have to later. And yes - your code contains bugs ;P

Second, to be testable, code needs to have a certain structure. I assert that well testable code happens to also be properly composed code. There are a lot of ways to blast yourself in the foot composition-wise. When you sit down and write tests, you might find that your composition is all over the place. It's surprisingly easy to write completely untestable code, and that's not something you generally want to get into the habit of doing.

Lastly, do you expect your $company to just take your word that "this works"? Unit tests are a demonstration of correctness. I'm sorry, but the harsh reality is that your mouth doesn't count for very much. So, either formally prove the correctness of your code, or write some tests.

I challenge you to take a few days and slap some unit coverage over your codebase. You will be amazed what you learn about your own code. There will probably be a good number of instances where you think "oh, I didn't think of that.." If you find it's difficult to actually test your code, you might think about the composition and how you can improve the testability of what you've written.

I very strongly recommend you read Beck's TDD. I'm not advocating for full-on TDD, but the book does a great job of explaining why testing is important and how you should organize a test.

Once you've got an idea of how to write unit tests, come back and ask about integration vs. end-to-end testing.

Disclaimer: I'm still a student, so if you want to, go ahead and disregard my response. On the other hand, I have put in many hours contemplating this very question.

In "Coders at Work," Peter Seibel interviews the founder of JSON and JavaScript architect, Douglas Crockford.

Seibel poses the question
> Have you ever had problems ... (with) people who've been successful in one language (who) sometimes have a hard time giving up their old ways, even when working in a new language where they don't really make sense?

Crockford's response:
> I don't care. I just want to know that you know how to put an algorithm together, you understand data structures, and you know how to document it. (...) Generally, I prefer generalists. I want someone who's capable of learning any of those APIs but isn't necessarily skilled in any one.

In The Pragmatic Programmer, authors Andrew Hunt and David Thomas say
>The more different things you know, the more valuable you are. As a baseline, you need to know the ins and outs of the particular technology you are working with currently. But don't stop there. The face of computing changes rapidly -- hot technology today may well be close to useless (or at least not in demand) tomorrow. The more technologies you are comfortable with, the better you will be able to adjust to change.

The emphasis in comfortable is mine. It doesn't say the more technologies you master or are proficient at. Instead, being comfortable with many different areas, topics, technologies, languages, etc., will allow you to express your value to an employer in many different ways.

Now, specific to your current position. I have been with my current company for 9 years now. I started out as a cashier, moved into management after 9 months, and now I am a service technician working with all of the networking, computers, surveillance, construction, project management, etc. I am essentially a corporate representative with a LOT of autonomy, responsibility, and I wear a lot of hats. I am also the highest paid technician in the company for these very reasons. My job is perhaps one of the most stable in the company given the amount of general knowledge I have about the areas I work on actively.

Now, software might be different in that knowing a lot about everything is incredibly hard. However, picking a couple of specialized areas and being comfortable with many other areas is very likely to make you a valuable employee. It allows you to think up insightful solutions to multi-disciplinary problems. You can be the hero who comes up with novel solutions to larger problems, whereas people who specialize in C++, JavaScript, or Haskell might only know how to solve the same problems in their respective languages.

From what I can tell by reading the literature, those are the differences between people who specialize and people who generalize. I think you are experiencing what it's like to be good at generalizing. Incidentally, I would also equate CEO's, CTO's, COO's and other C-level people to generalists. They are capable of abstracting away the minutiae and details of their problems and delegate to others in order to get stuff done. They focus on big-picture stuff and let the specialists (accountants, technicians, programmers, drivers, etc) deal with the details.

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.

Too bad I didn't start my github project out in python, most of it is in bash. For some reason github tells me on the code scale I have 80% in python O.o. Maybe I do some things in similar fashion with .shinc modules for the main script. If you're interested in retro gaming, you could always help me and JC with RetroRig. Most folks like to make games with python to start out, and once I find time myself, I play on going through the book Python Programming for the Absolute Beginner. I've leafed through it, and heard reviews from folks I know, and they love the book. It's a great way to sharpen up the skills. As far as projects, there are probably some sites that could help parse OSS/FOSS projects based on yoru interests.

GitHub only seems to sort/search by trending projects. The suggestions for OpenHatch is nice, and seems promising. They reason I started my project, was not because I like programming or anything (I am not a programmer by any stretch, but very technically minded), but because I loved the idea of making what I am doing. I started out small, and loved every little accomplishment I achieved. I now have a contributor, who also visits this subreddit, /u/beaumanvienna, and it's the most fun thing in the world to bounce ideas of people. Just think of programs you use, and how you can make them cool. The best work you could do and work on, is work you love and are interested in. Then you will be extremely proud of your accomplishments at the very minimum.

Edit: spelling.

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.

I've been programming for 23 years now. I was originally self taught and have worked with many people who are self taught. In my opinion, working with people who are self taught is usually a much better process than someone who has only ever learned from school based assignments. Since you were never told otherwise but you are super motivated to make things work, being self taught can definitely leads to many bad habits.

For example, the very first game I wrote was in BASIC and I didn't know about loops or subroutines. The entire logic of the game was written using a 10,000 line block of if elses which described all possible ways the game could play out. However, I did eventually learn about subroutines and loops and am constantly looking to improve my code. That is the key piece that you need to remember and put forward when working with others. Let them know that you're always looking to improve yourself. Try not to get defensive about your work if it is criticized. Instead, explain why you chose to do something that way and ask for suggestions on improvements.

It sounds like you're on the right track already and that given time, you'll be a top notch hacker. Keep pushing yourself to improve and refactor your code.

Two books that could be useful for you to start with writing / rewriting code to be cleaner and more professional.

Clean Code
Refactoring: Improving the Design of Existing Code

Best of luck!

By making things and putting them on GitHub, and then you can link to your GitHub portfolio on LinkedIn. Any company worth working for will care more about the quality of your work than your certifications.

If you're asking how to learn programming in the first place, it has never been more accessible! There are countless books and guides out there for any topic imaginable. So what I told apprentices at the last company I worked was, start by reading Clean Code by Bob Martin, to get a feel for the mindset with which to approach programming.

And from there, just start making stuff-- 'Breakable Toys' we call them. After print("Hello World") the first thing I made was an unbeatable tic-tac-toe game, and then a bunch of other random stupid stuff before I learned to do anything interesting or marketable.

OPINIONATED STATEMENT ALERT: You must make your first project in Elm! :) it's by far the most beginner-friendly language I've ever worked with, and really just an overall delight (even for non-beginners). Even though it's not the most marketable language right now, it's the best intro you could have into programming, and will give you a great foundation to learn other languages!

Edit: Also worth looking into apprenticeship opportunities. The only well-known one I can recommend in good faith is 8th Light's which I believe is free until they start paying you-- so a better deal than college I would say! Thankfully, many smaller local businesses are starting to embrace the apprenticeship model as well, so keep those opportunities on your radar.

I think others have said what needed to be said, but I'll throw out one more piece of advice:

Get a teddy bear.

No, wait - hear me out!

A lot of people advocate code reviews with other developers, to keep themselves honest. When you're about done adding a feature to your project, you should review the code with another developer. After going through this a few times, many developers learn to clean their code a bit, before letting another developer see it. How you solve it, isn't how you should leave it.

Well, it turns out that this mental act of getting ready for a code review is where you get a lot of the benefit of code reviews. Meaning, for a lot of the value of code reviews, you don't even need the expense of a code review! Just the act of preparing for one, makes your code better.

So, I've heard of getting a code review teddy bear.

When you think you're about done, adding some new feature to your code, get ready to code review it with your teddy bear.

And then you have to explain all of your changes and new code to the teddy bear, aloud. Use English, and tell it what each line of code does.

And then don't add comments to explain the tricky bits! Rewrite your code so that the tricky bits are readable. And if you can't rewrite it so that it's readable, then encapsulate those tricky bits inside methods with simple names, simple parameters, and no access to global variables.

GOOD LUCK, AND KEEP TO IT! It'll make you a better software professional in your main career! Tinkering is good! Don't get frustrated!

Maybe try reading "Refactoring"

http://www.amazon.com/Refactoring-Improving-Design-Existing-Code/dp/0201485672

Just to get the mental wheels turning.

And maybe try: "Working Effectively With Legacy Code" to inspire yourself...

Not really related to mobile development, but he should still really enjoy these if he hasn't read them already:

• Clean Code (http://www.amazon.com/Clean-Code-Handbook-Software-Craftsmanship/dp/0132350882) anything by Uncle Bob tends to be easy to learn and extremely useful
  
  
• Seven Languages in Seven Weeks (http://www.amazon.com/Seven-Languages-Weeks-Programming-Programmers/dp/193435659X) really fun read and a good way to quickly learn a little about a lot. Great for a jack of all trades
  
  
• The C Programming Language (http://www.amazon.com/The-Programming-Language-2nd-Edition/dp/0131103628) a book every dev, no matter the domain, should read
  
  
• Land of Lisp (http://www.amazon.com/Land-Lisp-Learn-Program-Game/dp/1593272812) because learning functional programming makes you a better programmer
  
  
• The Pragmatic Programmer (http://www.amazon.com/The-Pragmatic-Programmer-Journeyman-Master/dp/020161622X) I actually just started this one last night so I can't say much about it. Including it anyway because really smart people recommended it
  
  
• Eloquent JavaScript (http://www.amazon.com/Eloquent-JavaScript-Modern-Introduction-Programming/dp/1593272820) really good "intro" to JavaScript. Even if he's already familiar with the language, there maybe be a lot more to it than he know about (closures, prototype, "this", functional programming, etc.)

Not Android, but, much of what konk3r said in his comment is packaged nicely and easily consumable in Refactoring by Martin Fowler. Before you begin coding Android, understand Java and what it takes to write maintainable code. Any mildly intelligent chimpanzee can write code; it takes a talented programmer to write code that others (or even the dev himself) can maintain.

Other things:

• Understand list views. They're ridiculously complicated but there are very few apps that don't need them, and I can count on one hand the number of developers in my company that I've come across that can implement them correctly.
  
  
• Model-View-Controller. If you don't know the paradigm, look it up. iOS/Objective-C does a lot better job of lending itself to the paradigm naturally, but that does NOT mean that it is not applicable in Java. Separating your UI from your business logic/data is crucial and will save you SO MUCH PAIN later in maintenance stages.
  
  
• Understand the Activity lifecycle. Re-read the documentation and experiment until you understand its ins-and-outs.
  
  
• Never use hardcoded strings. They're a nightmare to maintain and completely impossible to re-use. For Android, UI strings should go in strings.xml (this means, if text appears in your app UI, it better be a string resource). You may also opt to use them for non-UI things, but I prefer constants in well-named files.
  
  
• Understand when you need application context versus activity context. Understand the differences in the two. Use them appropriately.
  
  
• Android is open source and apps are extremely easy to unravel to their source code, so, don't be shy about pulling down someone else's app and dissecting it to figure out how they implemented that cool functionality. Google's apps especially. Obviously don't commit copyright infringement, but a good programmer knows when to write from the ground up and when to not reinvent the wheel.
  
  
• If you're passing information between activities, use Parcelable, or the Android Gods will smite thee. NOT serializable.
  
  
• Utilize Android's helper classes. Did you know they have a TextUtils class? It is great for String functions (like checking if a string is null or "" with isEmpty();).

edit Supposedly this guy is OG in data science. http://www.datasciencecentral.com/profiles/blogs/hitchhiker-s-guide-to-data-science-machine-learning-r-python




My friend has a bio background and doing well as a data scientist consultant. I wouldn't shy away with a lack of math.

I'm still an amateur, so take this with a grain of salt.
I'd also like to share my strategy for learning data science so far.

I have a math background, which is useful but not required. Knowing linear algebra and differential equations, some analysis stuff is useful for developing a deeper intuition into how the machine is learning, but not necessary. IMO data science is a life long journey as it can be applied to many fields. It may be useful to learn more math later on as it get's deeper, but surface level knowledge should suffice.

For linear algebra, I've found the first lecture to be the most useful. http://ocw.mit.edu/courses/mathematics/18-06-linear-algebra-spring-2010/video-lectures/ It basically describes how we can translate lines into vectors and find solutions. It may be useful for continue learning, but in the beginning I believe surface understanding should suffice. If you're looking to build new data analytic tools, understanding the maths at depth is a must. But if your goal is to apply the tools already in existence, you can get by with a brief understanding.

For example, I have a weak statistics background; for the things I don't know I look them up on wikipedia, various sites, etc. The goal is not necessarily to learn the material as you would for an exam, but to develop a broader understanding of what the material is and how it is relates to machine learning. When I read this material I probably retain only 5-15% of the information, but I read enough to let me move on. Never get stuck on one piece of information for too long. I've found if I get stuck, I can move on and the brain just kind of figures out how it fits into the puzzle.

With your background Andrew Ng's course on coursera https://www.coursera.org/learn/machine-learning should be suitable.

I watch these videos only once on 2x speed. My goal is not to retain the information but to index it. Much of what is useful will be learned by practice, by watching the videos on 2x it's like skimming a text. It allows you to index, that way you know where to look if you need greater depth in the future. For example, you don't have to memorize the cost function, but it's important to know why the cost function is constructed the way it is, and what it's use is.

I then supplement by reading this: http://neuralnetworksanddeeplearning.com/

and doing these problems http://www.cs.cmu.edu/~tom/10601_fall2012/hws.shtml

This is the most useful resource I've found tbh:
http://www.kdnuggets.com/

I have a weak programming background, so for learning python I've found this text useful for practice and learning the language: https://www.amazon.com/Automate-Boring-Stuff-Python-Programming/dp/1593275994?ie=UTF8&Version=1&entries*=0

This text is very basic, useful in general if you don't have a compsci/compeng background, but doesn't have direct applications for data science. For a more data focus wrt python: https://www.coursera.org/specializations/python . You do not have to pay for any of these courses. Just search for the specific course and enroll, for example, https://www.coursera.org/learn/python-data

That's pretty much where I'm at.
I believe the most important thing is to train our brains to think as the machine would. It's important to utilize our intuition and natural parallel abilities of the brain, as ultimately these are the techniques we are attempting to replicate.

I also come from a strong math background, and love "mathematical programming," and have probably faced some of the same obstacles you're about to face.

Anyway, the one are where I suspect you lack the most (and your code seems to confirm this) is in the area of clean code, architecture, and software design. And no, I'm not talking about adding comments ... but rather time-tested practices that make code much easier to debug, maintain, use (as an API), and add/remove features by other software engineers whom you've never met.

Perhaps the fastest way to get you up to speed on modern practices is this book:

http://www.amazon.com/Clean-Code-Handbook-Software-Craftsmanship/dp/0132350882

After that book, start reading books on software design and architecture.

Peer code-reviews are also an amazing way to improve. If I had more time (I wish I did), I'd probably give your code a detailed code-review, and possibly refactor your code because your code is not "bad" per-se, but could be SO much better. :) When you look for a job or internship, ask them about their development process or cycle. If you hear anything about "unit tests" and "code reviews," that's probably a good thing.

> Should I apply even though I am still learning the requirements?

PHD in mathematics, which the ability to code? If I was in a hiring position, there would be a good chance I'd hire you.

I'm just two months into my first real job for programming and have a few books I've been going through.

Clean Code is a book not just about writing code, but good code that is easily maintained and passed down to other people to understand.

Working Effectively with Legacy Code was a great read coming into company that has been around for 20 years and is on the third iteration of their product.

I am doing web development so You don't know JS, Javascript: the good parts and then Javascript The Definitive Guide have all been a great help.

If you aren't much a book person, Pluralsight.com is awesome for info on tons of different technologies and is well worth the monthly cost. Go follow every major name in your preferred technologies on twitter. They will tweet all sorts of cool things to learn about. Also, PODCASTS!!!. I don't even listen to music anymore. If I'm in the car alone I'll be listening to Dot Net Rocks or Javascript Jabber.

Lastly, there are subreddits for every tech imaginable. Go subscribe to them and hit everyone up for where they get all their info!

You only need one book: The C Programming Language, 2nd Edition.

However, I would also recommend you own C: A Reference Manual, Fifth Edition, especially for the C99 coverage. Not needed immediately, by any means, but well worth having - the reference section of K&R will serve you well for quite a while for any C89/C90 coding.

A fine supplemental book is C Programming FAQs. Much of it is available online as the comp.lang.c Frequently Asked Questions, but the book adds material and polish.

Once you're ready for advanced C knowledge (I'd guess after at least a year of substantial C programming, but only you know when you're ready and interested enough), you really want to read Expert C Programming: Deep C Secrets, by Peter van der Linden.

There are some other very good books that have more or less direct applicability to C programming. The two I would call out are The Practice of Programming and Programming Pearls. Both worth far in excess of the asking price.

Good luck, and welcome to the deep end of the pool. The water's fine.

I agree, I think software development skills are going to only further bleed into other stem disciplines in the future. Plus it can be a back up skill if traditional engineering ever gets tiring. That way you're not tied to only one employment source.

I'd also steer away from VBA or .NET and get better at python (for the data analytics in research) and learn C (for potential robotics applications). I normally wouldn't recommend C as a first language since it doesn't do as much for you as other languages, but this FREE edx Course does such a great job of teaching it interactively that I think it's worth it in your case: https://courses.edx.org/courses/course-v1:Dartmouth_IMTx+DART.IMT.C.01+1T2018/course/. I like this course because they have a in built C compiler and a visualizer that shows you what each command you type would do to the program.

CS definitely bleeds over into some disciplines. Especially since you have an interest in research and robotics. I think a combination of ME + a CS minor can get you a foot into some research and/or robotics internships.

As for books, I think a combination of Think like a Programmer and Head First C and Head Start Python would be great "beginner books"


Then if you find out you really like programming you can get into best practices and how to build bigger complex programs with a book like Code Complete.

But before all of that just get the basics with python, then move to C if you ever decide to move into robotics.

CPA turned data engineer/scientist checking in. Used to work in FP&A for a bank handling all their technical needs. Spent my entire career so far between business departments and IT departments.

As for #1, if you like where you're at then try to beef up the technical skills to the maximum you can in that environment. Take the time to master SQL by learning the advance uses (windowing functions, recursive queries) and tune some of your queries that take a while to run. As for Excel VBA, I really suggest you start learning a proper language like Python and use that instead. VBA was my first professional coding experience, but it kept breaking (new office versions, Mac users, windows updates, etc..). I now write Python and R regularly and I wish I started sooner. Start small with scripting then start dabbling in more object oriented programming. A good book to start with is Automate the Boring Stuff with Python: Practical Programming for Total Beginners https://www.amazon.com/dp/1593275994/ref=cm_sw_r_cp_api_0BTSybPKF1S0S

Mastering SQL and having scripting skills gets you closer to a technical role than a business role. At a minimum, it makes you worthy of an interview for more Business Analyst and Business Intelligence roles.

As for #2, I need to give you a little bit of a hard time. Just head to Indeed.com and search for 'finance SQL'. TONS of opportunity live at the intersection of finance and IT all over the world. Moving straight to a pure development role will be a challenge, but start scanning the jobs you find most attractive and figure out what your gaps are. Even if you don't plan to leave, use those job descriptions to talk to your leadership about your technical goals.

As for the CPA, IT'S A HUGE ASSET. Sure you may never sign off on an audit statement or be a tax preparer, but your CPA is proof you understand business. I'm now a Senior Technical Manager focused on financial intelligence in the cloud industry and regularly consult with Finance how to solve weird accounting problems. Once you slide over to the technical side, your CPA and your business experience give you a perspective you'll have never had if you started off as pure technical.

I'm actually headed to San Mateo tomorrow and spending the week there. PM me if you want to grab a coffee.

There's OO design, and there's particulars as to how to implement things in C++. I'm totally with unapersson as to, that the Os you make are as often conveniences or design helpers as representing real world objects. Ie that it's implementation objects. I don't remember how much OO design advice Effective C++ has, but it's a good book to get someone to intermediate C++ programmer. C++ Coding Standards by Herb Sutter and Andrei Alexandrescu talks at a fast clip about a lot of taste and design issues; I haven't looked at the 3rd edition of Eff. C++ but, from earlier editions, the difference is that Coding Standards is more dense, and sophisticated; Eff. C++ more basic (from what I can see, Coding Standards does cover the same material as Eff C++, but in a very compressed form, only the most minimal discussion; maybe not what you want when you're seeing the material for the first time.

As for pure OO design, I've heard that straight-up Grady Booch is still the best, but I have no experience of it.

I will say, if you want to be good at C++, you'll have to spend money on books (but get your company to buy them perhaps - compared to programmer time, books are free), and time on reading them; there are a lot of best-practices, technicalities and real pitfalls that are not immediately obvious.

edit:

> Also, should I be studying data structures/algorithms in unison with OOP?

Definitely. Have you learned the basics, stack, tree, queue, hash tables (or set, map, vector, unordered_set, unordered_map)? You /must/ know these. (priority_queue and list too, less so maybe.) If you can though I'd read (somehow) about other data structures, spatial ones especially in your case; they can really make your program more efficient and thus able to do more.

edit edit:

I have to say, the above books are for long-lasting code; probably for games your best bet is to look at how other programmers write their games (smaller, simpler, even in other languages - it can be hard to understand large, sophisticated codebases) and, just the necessary experience you gain from writing your own.

Disclaimer: I'm an undergraduate and don't know shit.

I think the best way to learn is from the small parts, up. So, first learn a structured (preferably OO) programming language. Python will do, but I'd recommend something with compilation and static typing. Python is great for scripting and has its purpose, but designing and implementing a complex system in Python is a nightmare. After learning that, learn how to write your classes, methods and just generally structure your code better. I highly recommend Clean Code for that. After understanding good class design and code structure, start learning about higher-level concepts on how those well-defined classes should communicate with each other and be decoupled. Important concepts to learn are coupling and cohesion, polymorphism, inheritance, etc. All the basic OOP concepts. From there, you can move onto architecture. The book I used in my courses was System Analysis and Design, but there could very well be better ones out there.

Edit: Oh, and it's helpful to at least be knowledgeable of common design patterns. I really like SourceMaking's approach and explanations, but once again there's tons of good resources out there.

+1 for having a descriptive readme.md & GIF demos.  Do that forever.
 
I didn't look through your code super thoroughly, but I did notice that you're parsing some settings manually from text files.  I recommend using PyYAML for improved ease of use, especially as complexity grows (JSON & INI are also common options, but IMO YAML is the most readable & flexible of the three).
 
Here's an example:

settings.yaml

music:
extensions: [".mp3", ".wav"]
path: "home/jackson/Desktop/music"

movie:
extensions: [".mp4", ".mkv", ".avi"]
path: "home/jackson/Desktop/movie"

image:
extensions: [".jpg", ".jpeg", ".gif", ".png"]
path: "home/jackson/Desktop/image"

test_yaml.py

import yaml

def load_yaml(file_path):
with open(file_path, "r") as file:
return yaml.load(file)

settings = load_yaml("settings.yaml")

print(settings["music"])

{'extensions': ['.mp3', '.wav'], 'path': 'home/jackson/Desktop/music'}

print(settings["music"]["extensions"])

['.mp3', '.wav']

print(settings["music"]["path"])

home/jackson/Desktop/music

for file_type in settings:
print(file_type, settings[file_type]["extensions"])

music ['.mp3', '.wav']

# movie ['.mp4', '.mkv', '.avi']<br />
# image ['.jpg', '.jpeg', '.gif', '.png']<br />

 

-----

 
Aside from that, I recommend reading Clean Code (the video series is great also, I'm working through it now. Videos 0 & 1 are free).
 
The script you shared is small enough to where a random person (and/or your future self) can look at it and figure out what's going on without too much effort, but there are some implementations that would be much harder to manage & understand in a larger project (unnecessary global usage, nested loops, large amounts of abbreviated variable names, functions containing multiple streams of logic that would be better situated in helper functions, etc.).
 
The resources I mentioned above cover a lot of common pitfalls that lead to unmaintainable code, along with elegant solutions that will help you to write code that is clean/maintainable/reusable/easy to understand/etc.

If upgrading your application from Yii1 to Yii2 requires a rewrite, then switching to Laravel or Symfony will also require a rewrite.

If you have read Clean Code: A Handbook of Agile Software Craftsmanship by Robert C. Martin, then you might remember the Grand Redesign in the Sky - if not, take a look at What is Clean Code?:

> The Grand Redesign in the Sky
>
>Eventually the team rebels. They inform management that they cannot continue to develop in this odious code base. They demand a redesign. Management does not want to expend the resources on a whole new redesign of the project, but they cannot deny that productivity is terrible. Eventually they bend to the demands of the developers and authorize the grand redesign in the sky.
>
>A new tiger team is selected. Everyone wants to be on this team because it's a green-field project. They get to start over and create something truly beautiful. But only the best and brightest are chosen for the tiger team. Everyone else must continue to maintain the current system.
>
>Now the two teams are in a race. The tiger team must build a new system that does everything that the old system does. Not only that, they have to keep up with the changes that are continuously being made to the old system. Management will not replace the old system until the new system can do everything that the old system does.
>
>This race can go on for a very long time. I've seen it take 10 years. And by the time it's done, the original members of the tiger team are long gone, and the current members are demanding that the new system be redesigned because it's such a mess.
>
>If you have experienced even one small part of the story I just told, then you already know that spending time keeping your code clean is not just cost effective; it's a matter of professional survival.

Unless you and the team you work with has already asked and answered these questions, maybe there are more interesting questions to ask, for example:

• What are the actual costs of a rewrite?
  
• What is the business value of rewriting the application?
  
• Perhaps the business is better off improving the current system than rewriting it entirely?
  
• What can we learn about coupling our application to frameworks from this situation?
  

If this is your first programming language its a tad unfortunate that it has to be C++ but by no means does it mean it is bad or anything. In fact its the language most aspiring computer scientists started out with in college prior to the 2000s.

You can start off with
Programming: Principles and Practice Using C++ and then going onto The C++ Programming Language, 4th Edition after completing the first one. There is also C++ Primer that is also highly recommended as another book for starting out.

A book along with web searches when you have questions will get you pretty far. Having someone to ask questions if you get stuck on something conceptually is also useful. The best advice I can give you is to really play around with the language as you are learning and do most of the practice exercises too. Stroustrup also has solutions to the exercises from the first book I mentioned online. Hopefully you have some months available to learn the language. On top of that you might need to learn some computer science topics like data structures as well. You just can't rush these things but you can accelerate it a little.

As for me, my C++ knowledge is 'rusting away' by the day. I learned the STL with C++ when it was made official only a couple years after (like over 10 years ago). Nowadays you have Boost and the language itself has changed. I have not presently needed to update my C++ knowledge to what is latest and greatest but I shall.

Also worth pointing out is that In my experience, when you work with different companies you might find that you never use official C++ libraries and most current language features, but you are supporting legacy stuff that was first written maybe 20 years ago when not even built-in STL was available. This means either you are going to use some now-arcane implementation of someone's version of base libraries or the company rolled their own from the ground up many years ago, and because its so well entrenched in the code-base it continues to be used many years later. Not a big deal, but you might want to find that out for yourself, that if you are learning the latest and greatest of library and language features - you might or might not be using it in practice with your company.

You can PM me if you have questions but I'm not sure I can commit the amount of time you might need in a tutor role.

It seems as though you're focused on a particular method for your deployment strategy right now and it may be useful to take a step back and see if your requirements have already been met by recommended patterns.

What you're describing in the above is an integration workflow, and there are many well tested strategies already out there for integrating code (depending on your language/framework, this work may already have been done for you). Most importantly, these strategies rarely suggest cyclical actions like your FTP^(*) transfer from html back to "Remote1".

Ideally, you want your flow to look something like the following:
git repository -> integration steps -> build -> build artifacts -> artifact repository -> deployment tool -> deployed code

Note how this is a unidirectional flow, with nothing being pushed back into the Git repo. You may need to pull artifacts in from multiple build pipelines depending upon your requirements, but if you see the flow being reversed (committing back to git), you should carefully consider why you're doing so and ensure that there's not a better solution^(†). Additionally, while you may very well not need some of the previously listed steps, you should understand what each of them is and make an informed decision about whether or not it should be included.

I would strongly recommend spending some time diving in to Continuous Integration and Continuous Delivery/Deployment (CI/CD) and the patterns used within those methodologies, keeping in mind that CI/CD does not start with automation, but with understanding your code and requirements. One book I would strongly suggest is Continuous Delivery by Jez Humble and David Farley (https://www.amazon.com/Continuous-Delivery-Deployment-Automation-Addison-Wesley/dp/0321601912). It's starting to show its age a bit, but the fundamental ideas are still there and there's a lot of value to be gained from reading it.

Focus your reading on the what and the why before you move on to the how. There are tons of articles out there on how to build fast and efficient CI/CD pipelines, but if you don't have a solid understanding of why the pipeline should be there in the first place and what value it adds, it's easy to see articles of this nature as pointless exercises or end up building something that doesn't really fit your requirements.

​

* This is a warning sign, by the way. If you find yourself thinking that FTP is the solution, consider it a red flag; step back and re-evaluate.

† There are some common patterns which result in committing code back to a git repository, but they solve rare use cases and tend to generate a significant amount of debate. In particular, some say that generated code should be committed back to a repository. As an alternative, I would suggest considering generated code to be a build artifact and storing either it or resulting binaries in an artifact repository rather than trying to commit back to git.

You don't have to know anything about programming going in, as aixelsdi mentions. If you want to get ahead, here's some information which may help you do so. The rest is up to your own initiative. It can never hurt to know more about CS or more languages, as long as you don't waste time complaining about what's better in [insert language of choice].

I wouldn't recommend learning data structures and algorithm analysis before coming to UCI. Not because they aren't fundamental, they are. But because most people find it harder to learn those abstractions before learning the tools that utilize them (Python, C++, etc), which is why ICS 46 and CS 161 aren't the first classes taught. If you like math proofs more than math problems then maybe go that route, it could be helpful as iLoveCalculus314 mentions.

Languages: The CS introductory series (31-32-33) which you'll be taking first year is taught in Python. It switched to this because it's a good first language as a teaching tool. Right after you're done with Python, 45C will teach you C++ and 46 will use C++. The lower division systems core (51-53) generally use C or C++ but it differs by professor. Knowledge of Python will be useful in making your first year easier. Knowledge of the other two will make your next three years easier because they're common mediums for upper division courses. But you should be able to pick up a new language for a specific problem domain by the time you reach upper division.

Courses: If you want to get a head start on planning your courses, check the UCI Catalogue - Computer Science page. At the bottom it lists a sample of what your schedule over the 4 years might look like. That page is for the "Computer Science" major, for other majors in ICS see here.

Course Resources: You can actually view the Schedule of Classes without being a UCI student. Select a term (like Fall 2014) and a department (like I&C SCI) and it will list what classes were offered that term. Most lower div will be I&C SCI, most upper div will be COMPSCI. From the results you can go to the websites for those courses to see a syllabus, books used, etc. For example, here are the current websites for the introductory series ( ICS 31, ICS 32, ICS 33 ).

Your course professors and books and assignments will NOT be identical to those, but looking at what's currently taught will give you a pretty good idea of what the course entails so you can pre-learn anything that sounds difficult.

Books: If you have to pick one book to learn before coming to UCI, I would highly recommend C++ Primer, 5th Edition. It's very well structured as a self-teaching tool AND as a reference manual. You won't come away with any Python knowledge, but picking up Python as someone versed in C++ is easier than the other way around, and you'll find 45C much easier as well since you can focus on language quirks rather than fundamentals.

If you choose to learn Python first, Introduction to Computing Using Python: An Application Development Focus is the book currently suggested for ICS 31/32, and Learning Python (5th Edition) is suggested for ICS 33.

Another solid circlejerk book in the CS community is Code Complete, but I wouldn't recommend reading that until later on since it's more of a "best practices" book.

> Python with Github? Of course I can google plenty of guides, but the fact that I read many of them and still don't use it, shows me that I don't think the guides were good or sufficient (or I just suck at google). To me (for now) it feels like a big hassle with the commits, etc. for a very small profit (despite the sharing with other people). Is there a good and concise resource that you'd recommend?

Is it really GitHub you need help wrapping your head around, or is it git itself that causes the problem?

>101 of bad habits/beginner mistakes link/resource? I've seen plenty of links now that say "don't import *!" or similar stuff. But never a real compilation. Can also be about habits of programming or little shortcuts or tricks and tips, not only common mistakes people new to Python make. I know I'm asking for a lot but it might help and turn out to be very useful.

Well, there's the Zen of Python, which you can see for yourself at the REPL using import this. But for more concrete advice... if I found a compilation like that, I don't know that I'd trust it. A lot of these things are subjective. And anyway, if you're expecting to be able to read through something like that and magically get rid of bad habits, I can tell you it just doesn't work that way. You need to practice, and you also need to focus on the positives rather than negatives. Get used to the techniques by which code is improved. If you like physical books for this sort of thing (I don't), the best I can recommend is this one - you might be able to find online versions, but as far as legality goes, you're on your own to figure that out.

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.

CompTIA content is too much theory imho and having to renew them every 3 years now seems less appealing to me.

I'd say you head for the CCNA directly. While studying CCNA, you can use the Network+ study materials for any theoretical aspects you don't understand. N+ covers these better than most CCNA study materials.

Security+ is very nice but again, renewing every 3 years is not appealing. However, it does teach you a lot about security processes and a bit of law, compliance and standards.

There are other security certifications, some vendor dependent like the CCNA Security or the Juniper ones. If you're using these products, they are worth having otherwise, there are not many vendor-neutral ones as good as Security+. Careful with some of the vendor-specific ones, they tend to be more like adverts for products instead of certifications, basically "my product can do that!"

For Python, you are right. It's an excellent language for writing quick scripts for automating things. I personally liked Learning Python as reference, but if you're a beginner then Dive into Python3 might be appealing. Head First Python is also good but a new edition is due in 2015 I think.

You might have to choose between Python2 and Python3. Yes there are incompatibilities and not all libraries are available for Python3 yet but if you're starting from scratch, start with Python3 directly.

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.

Yeah man, Haybro is right. I would say learn c# first, since you don't have to worry about memory management as much (though don't forget about it :) ). There is a check list I go through for c# and it is as follows:

• understanding different basic data types (ints, floats, bool, string) and how to manipulate them (especially strings)
  
• understanding the difference between properties and fields.
  
• If and switch statements
  
• Ternaray Operators
  
• Basic Mathematical Operators (*, +, =, etc);
  
• understand the difference between = and ==, and not operators (!(true) and !=)
  
• Advanced Mathematical Operators (+=, % for modulus , << left bit shift operator)
  
• Arrays and Lists
  
• Dictionaries and Keypairs
  
• Understanding objects, classes and constructors
  
• New Keyword
  
• Access Modifiers and Static
  
• Understanding references and null values
  
• Inheritance
  
• Indexers
  
• Namespaces and using
  
• Partial Keyword and why it's a good idea to limit the use of it
  
• Abstract classes and interfaces
  
• Delegates, Events, Action and Func
  
• Understanding generics and using <T>.
  
• Casting types with 'as' or direct and understanding the difference
  
• Serialization
  
• Comments and Regions
  
• Threading
  
• ref and out keywords and why they can be bad to use
  
• IEnumerable and Yield Return
  
• Enums and flags
  
• Understanding Loops (while, foreach, for and do) and the differences between all of them
  
• continue and break keywords and how to use them in loops
  
• try,catch and finally
  
• Understanding methods: void, return types and parameters
  
• overloading methods
  
• Knowing what the params keyword is and how to use it in methods
  
• what virtual and override are and how they can be used
  
  I found this tutorial series to be very good (although it doesn't focus on game development which is a shame).
  
  Once you have these fundamentals, the you can start programming in a game engine (personal I like unity because there are a ton of tutorials out there for it :) ).
  
  After you have got confident with using Unity and c#, you'll probably want to start learning about design patterns and decoupling techniques. [This free online book] (http://gameprogrammingpatterns.com/) is amazing, and I would recommend it to everyone:).
  
  Other books like Clean Code and The Art of Unit Testing have helped me a lot too.
  
  With coding, it because more about creating code that is easy to change. At the moment, I am looking into using StrangIoc along with MVC to achieve decoupled, clean code:).
  
  Hope all this helps man.

I'd take a more tools- and methodology-driven approach. The programming language itself is secondary by a long shot. It's hard to be convinced of this when you're starting (hindsight is 20/20), but the fact is you don't need to spend hundreds of hours "learning a language." To a newbie, learning to program and learning a language is almost synonymous, but the latter is a far smaller subset of the former.

Here's how I would guide the younger me:

1. I would start by learning some of a language. The Pareto Principle (i.e., the 80/20 rule) applies here. In many languages you can spend a lifetime really exploring the details, but you'll largely forget these details through disuse. Why waste your time with that? It shouldn't take much more than a day to learn what you need to move past this step.
   
   
2. Learn very high level concepts of programming methodology. Engineering is about making complex systems easier to manage through things like encapsulation, information hiding, and abstraction layers. This is key to making software and is a lot more important than language-specific details.
   
   
3. Learn your tools inside and out. Learning a text editor is actually a great way to learn how to program. After all, a great text editor like vim is fully programmable. Things like snippets allow you to think about programming on a higher level beyond "do I need a bracket here?" etc. Another important tool is a debugger. There are some folks that advise against them, but it's incredible how much you'll learn by watching the way your code transforms your input. The third vital tool I'd suggest is using version control. Make a github account and use it in conjunction with your vim configuration files so that you may continually refine your environment (and never lose it, thanks to git).
   
   
4. Learn to use test frameworks, and then be adamant about writing tons of tests (preferably before writing any code).
   
   I think this is a great foundation. You don't need a lot of books, but I think Code Complete is a great one stop shop. I would probably also add something like Growing Object-Oriented Software because I feel Code Complete is a bit lacking when it comes to the actual practice of testing (though it provides a great overview of it).

I think the first confusion here is that the language is a entity in the construction of a program. Does the type of a house that is built depend on what type of hammer the carpenter used to put up the walls? Or what kind of wrench a plumber used to put together the piping? Sure, the carpenter or plumber could've used a crowbar to do their job, but was it the right tool for the right job?

The right tool to build an Android app is Java. If you need better performance, and you don't need Google APIs, you can include C or C++ to further improve performance at the cost of added complexity.

There are a lot of different abstractions to add the ability to use other languages on the platform, but this comes at the cost of performance, and added potential points of failure (more abstractions = more potential bugs not caused by the coder.)

Heavy number crunching (especially on a RISC architecture) may push the device to its limits. Do yourself a favor and learn how to use the right tool for the right job. This book is both entertaining and informative, and this book will get you started in on C++ in a short amount of time.

C++ is the inspiration for Java, and the creation of Java is what caused C# into being. As such, the syntax for all of these languages are tightly woven between each other. I wouldn't doubt that within 15 minutes of light reading on Java you'll be up and running in its entirety.

C++, while being a slightly more complicated beast, isn't inherently an overly complicated one. The Object-Oriented concepts are all there to be leveraged.

While you say you're not a professional programmer; I think you'll find that broadening the languages you do learn will improve your ability to convey your thoughts and concisely implement them.

Best of luck!

I can't help with MATLAB much, but with Java I'd recommend a couple things.

For books, The Java Programming Language, from the creators of Java is an excellent resource. Another book that is not specifically Java related that I recommend is The Pragmatic Programmer: From Journeyman to Master, as it is a great book on programming practices and good things to know. I've read or looked at a bunch of the books by the Pragmatic guys and they are all really good if you ever get into other languages as well.

In general though for all programming, the most practical way to learn is to start with simple problems that interest you, or maybe ones from sites like Project Euler and just learn by doing. There are lots of great tutorials online, and if you ever get stuck, Google and Stack Overflow are your friends.

i agree. books and tinkering are the very best way to get introduced to programming.

i read my first programming book the summer between my sophomore and junior years in high school. (i don't recall how old that made me at the time. 16? bah, i'm getting old.) anyway, that book was Herbert Schildt's The Complete Reference: C++. i found it really interesting, but knowing what i know now Python (The Quick Python Book and Learning Python are good) or Java (I learned on Thinking in Java, but Effective Java is supposed to be good, too) are probably better places to start.

hopefully your parents support your desire to learn programming. $30-$50 for a programming book and access to a computer are a small price to pay for starting a child on a hobby that could turn into a good career!

good luck, and keep us posted! :)

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 :)

Honestly your question is almost irrelevant of programming language. Still, few pointers:

• Don't mix up database layer with logic and front-end code (if any). Separate them. You can read about MVC for starters. This way you don't end up writing math functions in the same place as you write code that handles a user clicking a button. This ensures your project has a proper structure.
  
• Write tests. If you think it's QA department's job to ensure your program is correct (or even worse, if you think that it compiling is good enough) then you are very mistaken. The more tests you write for your program (checking if functions output is correct, if it handles edge case scenarios or invalid input properly etc) the better.
  
• Classes are supposed to make code easier to read, not harder and they should be about one specific task. GraphicsHandler that generates a whole 3D grid, has like 20 prototype different shapes you can put on said grid etc is NOT a good class design. Those have to be simple. If you start seeing shitloads of methods in a class to make it work then it means you need two classes.
  
• While on the topic of classes - group up your methods by their importance. Don't shove most important ones at the bottom. If you know a method won't modify your arguments then declare it as const. Also - multithreading is a big thing nowadays. If you KNOW your method won't work with it properly and is all but threadsafe then write it down somewhere. Or add a mutex so it can't be ran by multiple threads at once. Especially important if you are writing a library.
  
• Be consistent. Nobody cares if you prefer tabs or spaces, just decide on one. Often it's project manager or company policy itself that defines it but as an independent programmer you need to learn those habits by yourself. If you decide to use camelCase notation for methods and functions then don't suddenly write methods_like_this.
  
• Practice writing GOOD comments. Often you see programmers either not writing them at all (terrible!) or not understanding the actual point of them (possibly even worse). You really don't need a comment that says "here we loop through an array". But if for example you have a Pixel color in ARGB space defined as a single unsigned int (so you have 1 byte for A, 1 for R, 1 for G and 1 for B) and you manipulate specific colors directly (via bitfields/converting it to char array) then it's a good idea to explain HOW your process works in a comment because it might not be obvious for a programmer if he suddenly sees a union or <reinterpret_cast> from int* to 4 element char array. if what you are doing might not be obvious - write it down too.
  
• Also - you have version control nowadays. Don't leave huge commented out parts of your code.
  
• Proper naming of your variables. i and j are fine for loop iterations, x and y can make sense for coordinates and a,r,g,b are good names for color values but that's about it. Write all names in a way that means SOMETHING. I very much prefer to see a variable Person new_user("Bob") to Person x("Bob"). Since afterwards I will see a new_user (which makes me think it's probably a User/Person) rather than x (which can be anything, now I need to find a declaration!).
  
• Avoid declaring your variables without defining them:
  
  int howMany;
  for (int i=0; i<howMany; i++)
  {
  //aaaaaaaaaaaaaaaaaaaargh
  }
  In this example it's obvious but often you create a new variable, forget to assign it and 100 lines later try to use it and have no idea why is your code blowing up. Most of the time ANY default value is better than not having it at all.
  
  And with this I explained roughly 1% of what a clean structure means. There are good resources on that, check out Clean Code book.

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.

Good job! Copying existing game ideas is a perfect way to learn

Some recommended reads I had saved as bookmarks if you want to dig even deeper into game programming:

Game programming patterns

Goes deep into all the different patterns of writing a good game engine. Written by one of the devs at EA. There is a free web-version if you scroll down on first page.

Game mechanic explorer

Lots of small snippets and explanations on common mechanics, like bullet trajectories etc. Only for 2d games but much easier to digest then the patterns-site.

A* introduction

A* is a fun algorithm to implement

Clean code book

This one is a must, a book you might get the most out of when working with other people but if you wanna get thinking in the terms of maintainable code and what will be expected of you at a real workplace, take the advices it gives to heart :)

And a tip for a potential next project:

One of the first games I did was a clone of Bomberman. The graphics can be pretty simple but you get to dig into cool stuff like (simple) AI with pathfinding and you can make a very simple multiplayer game out of it that isn't that lag sensitive

C# has excellent tutorials on the official Help site for Visual Studio 2013. You can download Visual Studio Community for free here. It is fully-featured and allowed for personal use (both non-commercial and commercial); you just are not allowed to use it on a development team of more than 5 people. After you become experienced with C#, learning Java is as easy as going through a textbook (also available in a physical version) and/or study guide (the latter might be a little too toy-ish for you if you're looking for job skills). If you are opposed to C# due to not liking Microsoft etc, then I'd use the previously linked Sedgewick and Wayne book and download Eclipse. Fair warning, C#'s tutorials are excellent and I've never found a better way to learn to code using a language with significant real-world use... if you choose the Java route to begin with it may be hard if you're not using a formal class. Once you know how to program, I'd say going through the MIT OpenCourseWare Intro to CS class would be a good idea to learn a different kind of language (Python, which has more scripting elements to it). C++ would make a good language to learn third, the best resources I've found so far for that are here, the book can be found as a PDF here or as a physical version here... warning, not all the material is available at all times due to the fact that it's an actively running class. A class on algorithms (book here, you may need to learn more math... probability, calculus, set theory, and the like... first, not sure what your background is on that) would be a logical step to take somewhere down the line. After that you will pretty much have most of the skills that someone with a minor in CS would get, learning the HTML/CSS/PHP chain and building a website would be a good way to round out your skill set. You should be able to get through quite a bit of this in the next 18 months. Good luck! Also, as others have said, try not to spend too much money... most of what you need can be found on the Internet, and the rest should only be a hundred dollars or so for a textbook. If another topic in CS that I haven't mentioned interests you as well, there's probably an OCW course for it, the sky is the limit once you have a firm foundation (I'd say the bare minimum for that is knowing Java and C++ and thoroughly understanding the material in the Algorithms class I linked above... still I've found C# is far easier as a first language though so if you try to shortcut it you might struggle... once you know one language the rest come pretty easily, especially if they are as similar to your first as C# and Java are, so your first goal is to learn C# [or Java if you are still that adamant]).

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

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.

It depends on whether you're a beginner to C++, a beginner to programming or both. It also depends on whether you prefer a tutorial style -- where you read closely and walk step by step with the author, or a reference -- where you skim, go at your own pace, and follow up when you need more details.

Accelerated C++ is more of a short introduction that hits all the broad strokes. It's good for someone who's already very adept but just needs to get into the mindset of C++.

Principles and practice is a tutorial style book suitable for an introductory course, and isn't a bad choice. The C++ Programming Language is more of a reference style and would be good for people who really prefer that direction.

I've read parts of How to Program Java and definitely was not impressed -- not sure how 9th ed of C++ stacks up.

I'm assuming a beginner is new to programming, but by virtue of choosing C++ enjoys the technical details that allows you to make the most of the language. My recommendation for this kind of user by far and away is C++ Primer by Lippmann, Lajoie, Moo (not to be confused with Primer Plus). This book (3rd ed) was what made me fall in love with the language in university.

It's written by people who were deeply involved in the standards, wrote actual compilers, and know how to present the material in ways that are relevant to the student. The 3rd ed also had sections that went further and explain the underlying compiler mechanism for a given feature which I found so insightful. They somehow managed to marry a high-level tutorial style narrative with important low level technical details that very much mirrors the style of the language itself. The 3rd ed also explicitly called out C++ as a mutli-paradigm language where functional style was possible (which was my first introduction to the concept of functional programming).

I'm not sure how much of that book survives in the 5th ed, but either way I recommend you read the book yourself and see if it's something that resonates for you. I'm looking through a copy of 5th ed right now, and it looks like much of that spirit is still alive. The down side is it appear it's still on strictly C++11, which given the size of the language and intended audience, I don't think is a fatal weakness.

If you want a complement to C++ Primer, Stroustrop's reference is the most complete, but to be honest I prefer C++ Reference for a working programmer.

I highly recommend ditching IDEs entirely for learners precisely because they make it harder to detect and learn from your mistakes. Get a copy of a linux distro, or install XCode command line tools, and invoke GCC/Clang directly. By the time you need to move into larger projects you'll have developed your own opinions on build systems/IDEs.

Buy The Pragmatic Programmer, read it from cover to cover. Let it change your life. It's not a specific language reference but it's pretty much required reading for any new programmer. It's about creating maintainable code, which is more of a mindset than anything, it's also a really really EASY and relatively entertaining read.

https://www.amazon.com/Pragmatic-Programmer-Journeyman-Master/dp/020161622X/ref=sr_1_1?ie=UTF8&qid=1520232423&sr=8-1&keywords=the+pragmatic+programmer&dpID=41BKx1AxQWL&preST=_SX218_BO1,204,203,200_QL40_&dpSrc=srch

Another more specific book to use as reference is the Effective C#:
https://www.amazon.com/Effective-Covers-Content-Update-Program/dp/0672337878/ref=sr_1_1?s=books&ie=UTF8&qid=1520232641&sr=1-1&keywords=effective+c+sharp&dpID=51ga39m0W5L&preST=_SX218_BO1,204,203,200_QL40_&dpSrc=srch

They make "Effective" books for nearly all popular languages, and they really are great references. If you don't understand everything in it like co-variance and contravariance google as a lot of good examples of these concepts in practice, as well as definitions. Believe me I understand that these things can get really confusing and frustrating coming from a non-academic background and trying to bridge that gap. But utilizing this book and understanding the lingo will also help you to find more answers to run on your own.

Now, as with anything in programming, the point is not to have to remember everything all the time in these books(despite what try-hard programmers on the internet will tell you). That comes with experience and you're human so don't set yourself up with that expectation. Read them once so you know what is in them, and keep them at your desk for reference.

When you need to construct an interface pull out the book go to the interfaces and give it a glance over to give you an idea on where to go.

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.

Really, that's not even something I would consider all that important to know off-hand. I actually had to go to the REPL and the docs to verify how the int function behaved with alpha-numeric strings. This is the sort of thing that people might pick up with experience, but I wouldn't say it's such a commonly used feature of the language that not knowing it reflects poorly on your abilities.

If you don't know something like this, you can just say that and use the question to demonstrate your reasoning skills and your general knowledge of the language. E.g. "I don't know how that would work off hand. But I know that python is a strongly typed language, so it doesn't do implicit casting. But where this would be an explicit casting, maybe it interprets the string as a number if a high enough radix is specified. Or maybe it behaves like ord and returns the ASCII value of the character. If I was in the python REPL, I would type help(int) to see how it works, or I would go to python.org and look at the docs."

Actually, having mentioned that last part, it strikes me that it sounds like they might have actually been talking about ord, not int.

Anyway, if, on the other hand, they're only looking for the technically correct answer to questions about obscure, unimportant, or easily googleable aspects of the language, then they're probably not very good at interviewing, or aren't all that knowledgeable themselves. I don't know if there's much you can do about that, unless you're willing to pursue an encyclopedic knowledge of the language. While it's good to be more familiar with a language, I don't think it's generally worth anyone's time to try to memorize every single aspect of it. Who cares if you don't know the exact signature for the range function, or the exact string formatting syntax to left-align text and specify a 79 character width, or whatever? That's what the docs are for.

Having said all that, the int casting question sounds like it was kind of stupid, and if you're conveying it correctly, it sounds like maybe they don't even know what they're talking about there. The dictionary question, though, doesn't sound like a trick question at all. First-class functions, and the 'everything is an object' philosophy are pretty core features of python. If that's new to you, maybe bone-up with Dive Into Python, or Think Python, or Learning Python, or similar.

Good luck!

We assign mentors (usually the more experienced team members, but can vary depending on project and resourcing requirements) to new guys who will help them get to grips with things like our methodologies, coding standards, etc.

If we end up with a team consisting of a lot of guys without TDD experience (rare, but my teams can vary depending on other projects/resources within my company), we'll occasionally run TDD workshops where one of my senior guys or myself will go through a fill worked example of TDD, and then point the new guys in the direction of suitable resources so they can self learn (although we support them as much as required).

In terms of resources, there are a number of books we have on our internal "recommended reading" list:

1. The Clean Coder : A Code Of Conduct For Professional Programmers by Robert C. Martin (http://www.amazon.com/The-Clean-Coder-Professional-Programmers/dp/0137081073). This is a good book for developers in general, but has a good section on TDD.
   
   
2. Test Driven Development : By Example by Kent Beck (http://www.amazon.com/Test-Driven-Development-Kent-Beck/dp/0321146530/ref=sr_1_1?s=books&ie=UTF8&qid=1458766760&sr=1-1&keywords=kent+beck). Kent Beck is one of the leading proponents of TDD, and this is well worth a read. I find that the fact the text is example driven really helps our developers relate TDD principals to actual real life situations.
   
3. xUnit Test Patterns : Refactoring Test Code by Gerard Meszaros (http://www.amazon.com/xUnit-Test-Patterns-Refactoring-Code/dp/0131495054). This is a bit more advanced and goes above why and how to use TDD - in fact, it's not specifically about TDD, but rather just unit tests in general. However, it explains ways and patterns that can be used to design your code and your tests correctly in order to produce quality tests.
   
   There's a lot of information on the web, but I find sometimes books are just the best source.

Alright, in that case it sounds like you can benefit from 'the general advice':

1. Make a 'vertical slice' of the game as early as possible. Networking, animation, scene loading, GUI, etc. This will ensure that every major library and tool you need gets in there early, and you workaround the conflicts between them before it becomes a burden to insert a new one. One of the big mistakes on one an early projects was to leave the entire GUI to the last minute, but because that 'conflicts' with general user input it was a huge chore to workaround certain issues after a lot of the user input code was in place.
   
   
2. Trello is a handy tool for managing tasks, but I'm sure there are other perfectly good alternatives. Despite what you use, update your task list often and make sure you break things down into bite-size chunks that can be accomplished within between an hour or an entire day. That way you're always making progress and keeping your motivation up as that list gets shorter (although it will inevitably keep getting bigger as you break things down more, or remember things you forgot originally)
   
   
3. If its taking forever and motivation is going down the tubes, cut features. Don't debate, don't haggle, just start cutting features to trim down the workload and get yourself back on track.
   
   
4. Source control. Use it. Git with Bitbucket, or TortoiseSVN and VisualSVN Server Manager are my go-to solutions. It's both a log of your activity and your only saviour when things go wrong.
   
   
5. Don't be afraid to tell people about your project, and never tell yourself someone is going to steal your idea, because you need as much feedback as you can get. And the earlier the better. My wife asked me why I'm so cavalier about telling people about my current project even though I'm only a couple of weeks into it, and its because everyone has their own project that they believe in, and when I mention my project to someone they're more likely to give advice on how to make mine better, or more like their own project (unconsciously giving away their own 'secret sauce' recipe), than they are to steal it and build out a competing product. People will only bother stealing an idea that's already been proven to work.
   
   
6. Read books on game development and clean coding practices (if you haven't already). You'll be amazed what great lessons people are willing to impart for next to nothing, or even free (like I'm doing for you right now, incidentally). Two of my favourites are Game Coding Complete and Clean Code - A Handbook of Agile Software Craftsmanship.

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!

The smaller the better. From a development point of view there is a lot of god materials on writing clean code that is easy to read, work with and maintain. (https://www.amazon.com/Clean-Code-Handbook-Software-Craftsmanship/dp/0132350882/ref=sr_1_1?ie=UTF8&qid=1468632974&sr=8-1&keywords=clean+code)

I break everything into smaller functions. Each function gets it's own file. The vast majority of my functions and scripts fit on one screen (once you get past the help and parameters). You build a library of functions that are very easy to find. Because the name of the file is the name of the function, I can look at a tree view of the folder and see all of my functions and go right to it.

When you use source control, you have all the changes and edits very cleanly defined. All the comments are more localized to that file. If you have pester tests, it is easy to pair them up and know you have coverage. If you need to track down a old version of a function, it stands on its own. You can much easier tell the last time that piece of code was changed. (even if you are looking at filesystem based backups.

These functions become reusable as modules and only have to exist once. If you copy the same functions over and over into other scripts, then you also copy bugs around. If you fix something, how do you know you fixed it everywhere it was used? If it is a standalone function in a module, improvements to that one file benefit every script that uses it (This is where you benefit from automated tests).

When you have small functions, your nesting is less deep. Your variables are also tighter in scope. This means you can use very basic simple variable names. You can call that thing $user and get away with it. Those giant scripts are full of $userName $tempUser $userObject $user2 $newUser $ADUser $userList and the longer the script, the more creative you have to get. Also in smaller functions, you can see the initiation of all the variables are you using on the same screen that the code using it is on.

The monolithic file works great when you are just in the zone and laying out code. For those 2-6 hours, you have the whole script in your head. Scrolling around is not a big deal. But when you return to it, that mental map is gone. You have to scroll all over to see what is going on. Often you will see giant blobs of comments telling you to stop scrolling.

The smaller the better and each in their own files. However small your functions are, they are still too big. My functions are about 1/3 help, 1/3 parameters and 1/3 code. I'll stop ranting there. But you get my point.

I would supplement your class with one of the many great C++ books out there, because there are many ways to learn C++ but few of them are good (or even "right") ways.

You should be careful to distinguish between best practices from C++ and the new ones in C++11, and I've found that many courses tend to teach C++ as if it's just C with some extra features.

Of note, some really good books are:

• http://www.amazon.com/Primer-5th-Stanley-B-Lippman/dp/0321714113
  
• http://www.amazon.com/The-Programming-Language-4th-Edition/dp/0321563840 (this one is brand new, so I have no reference for how good it is, but previous versions are usually at the very top of people's suggestions)
  
  At least as good starting points on the "new" C++, and I'm sure others have some really great suggestions too.

>Is there something wrong with me? Or is this a normal thing?

No, programming challenges are more about general problem solving via coding than the ability to write functioning apps. You have experience in the latter and not the former so will not be as good at coding challenges.

But like everything else practice is what makes you good at something so if you keep trying them you will be able to learn to solve them. And I think it is worth doing so, they teach you to techniques to solve some harder problems you can face in real world applications, though you might not see them as often. Overall they can make you a better programmer.

But there is a limit to their usefulness, like if you master app dev you don't master coding challenges, if you master coding challenges you won't master app development.

Solving the problems of coding challenges is a skill. It can be learnt like any other skill. I think it is worth learning how to solve them, but there is no need to become the best at solving them. If you are having trouble with all of them I highly recommend reading Think like a programmer which teaches how to better tackle problems you face and break them down into easier to solve chunks.

---

Some interviewers will ask you to solve a coding challenge. Through not always and the ones that do often use the same challenges (fizzbuzz is a classic one). Not being able to solve them will hamper some of your attempts to get a job, but won't stop you from getting any job. It won't even stop you from getting a good job as better places often ask better problems that are more relevant to the job rather than some random challenge they found on the web.

Self-taught software engineer checking in to add on to this.

Everything u/TOM_BRADYS_PET_GOAT said is true.

I'll add a few specific resources:

Computer science fundamentals are really scary and overwhelming if you're self-taught. I'd highly recommend reading The Imposter's Handbook to get started with this topic. You'll want more in-depth material afterwards on each of the various subtopics, but this book is absolutely fantastic as a (surprisingly deep) introduction to all the concepts that's framed specifically to get self-taught programmers up to speed.

After you're familiar with the concepts at a conceptual level, and it's time to just get down to dedicated practice, Cracking the Coding Interview will be an invaluable resource. This book exists for the sole purpose of helping people become better at the types of questions most commonly asked during coding interviews. It's not just a list of a bunch of questions with solutions, it actually explains the theory in-depth, provides drill and smaller practice questions, as well as questions designed to emulate specific interview scenarios at real tech companies like Google, Microsoft, Amazon, etc. It'll even talk about the interview process at those companies outside of just the questions and theory behind them.

As a more general resource that you'll reach for repeatedly throughout your career, I'd recommend The Complete Software Developer's Career Guide. This book covers everything. How to learn, how to interview, how to negotiate salary, how to ask for raises, how to network, how to speak at conferences and prepare talks, how to build your personal brand, how to go into business for yourself if you want, etc. and that's just scratching the surface of what's covered in that book. I did't even buy this book until I was 10 years into my career and it's still very insightful.

And lets not forget, being a good developer isn't just a matter of making things that work, it's a matter of writing code that readable, extensible, and a pleasure for other developers to work on. So to this end, I'd recommend any developer read both Clean Code and Clean Architecture: A Craftsman's Guide to Software Structure and Design

Depends on what language or area you want to specialize in.

But the basics are important. Not so much being able to solve those stupid white board tests (I would not shoot for a company that does those as a self-taught first job individual. You'll just be discouraged. I've got 6 years experience and I doubt I could pass those stupid test without extensive studying.)

It's hard to say, b/c of some of it is...just exposure and your ability to think about abstract problems. I'm honestly not sure how to word it. But people who have had to go through academic training. EG Algorithms, data structures, modeling, etc... seem to just have a better understanding of abstract processes (if that makes sense).

Some things I feel are personally important.

Clean Code: https://www.amazon.com/Clean-Code-Handbook-Software-Craftsmanship/dp/0132350882/ref=sr_1_2?keywords=clean+code&qid=1563404400&s=gateway&sr=8-2 Believe this is the one. I've never read it page by page but we had one college professor who basically taught the concepts from it.

Ability to actually talk about what it is you've done and know. The best way to do this is to have actually tackled a complex problem or project. Even if you need to make one up, you'll learn a lot. Things like properly structuring objects. Data flow. Singletons. Data storage. Security (if you're doing something web based). I personally built an entire website from the ground up. It included a content management system for the homepage. Custom permissions and a forum's section. I learned more from that personal project than I have from work honestly. It's now trashed in Github somewhere, but that wasn't the point.

Abstraction abstraction abstraction. This kind of goes with the clean code point.

Knowing the importance of testing. Difference between unit and e2e (if you're doing web). Some companies don't even write test so your mileage may vary on this one. Usually they still pretend like they do in the application and interview. But once you get in, they'll have zero test. And this isn't the worst if the application isn't very large or complex. There's a lot more to test but unless you're applying for that kind of position, it may not be as important. But being able to talk to some of the basics is good. (Like knowing some terminology. Black box testing, smoke testing, uhh, drawing blank on the others...you can tell what jobs I've had sigh...)

I would say the tl;dr is...actually make something. And not something simple. And do it right. This will give you a lot of things to learn and think about and discuss in an interview. It'll make you more engaged and willing to learn. And most importantly, it'll demonstrate you can actually do what you say you can.

These are good, but I would say they're actually better for learning C++ rather than branching to higher level concepts. C++ is one of the easiest languages to implement best practices with and it's intuitive if you're a good programmer. The language and standard itself promotes cleverness and conciseness.

Some books I would suggest for branching to higher level C++ would be Effective C++ and More Effective C++.

Both are wonderfully written and relevant across standards. It focuses on bigger picture C++ rather than exactly current standards.

This is very much like saying, "I've learned how to write letters, and copied lots of sentences, paragraphs, and poems, and understand what they mean. How do I start writing my own text?" Programming as a creative art is a different thing from understanding the lexical structure of a language, or how to understand data organization, etc. It's as different as reading is from writing.

What you need is not directly connected to C# -- you need to develop a mindset and problem solving skills that let you turn a problem into a solution (which happens to involve programming). Relatively few courses or tutorials teach this, and I'd even say that many people who work in industry don't really have it either, unfortunately.

There are some resources out there along these lines. One interesting one is Think Like a Programmer, a book about analyzing problems and ways to come up with ideas to solve them.

Another great way is to learn from people who know how to do it. It's difficult if you don't know anyone. But one of the best things I've run across are conference presentations from people who've written amazing programs. A neat example (though maybe lower-level and geekier than you're looking for right now) is a talk by Eric Chahi, where he describes the genesis, design, and labor that went into creating the famous video game Another World.

One of the best things I learned in college was in an AI class. My professor taught a certain thought process that became an outline for many of my projects. Start with your data, determine how to represent it effectively, write code that does things with your data as you learn to manipulate it, and start putting the pieces together to do bigger and bigger things until it starts to look like a solution to your problem.

Good luck!

At the last place I worked clean code was just how we opperated. I got scolded if I added an unessisary comment. Asking myself "is this comment need? If so, how do I make my code more readable".

I completely agree there are times and places for additional information but ideally good code is easy to follow.

a basic low level example would be holding a users hand through any decision making process.

if(true)
//that means the value was true

else
//it wasn't true

but maybe I have been brainwashed, anyways I had this book on my desk for a few years now, its a good read and great and even though I can disagree with a few things he says its nice to have that engagement with the author.
www.amazon.com/Clean-Code-Handbook-Software-Craftsmanship/dp/0132350882