I can definitely relate, this sounds just like me last year! I've done things the hard way and it took me 5x longer. I also prefer screencasts to books. I always need to create a project to solidify those fresh skills, otherwise they'll be gone in a month. Also tutorials for things like Backbone assume you know how to use jQuery, Underscore, and things like REST, and JSON responses... this can quickly get confusing if your not familiar with all of these. My largest regret is not building enough practice apps in the last year. I really should have applied more by doing, instead of staying in the theoretical world.

Here are some insights that i've made and the courses/tuts/projects that helped me the most:

Learn the language first:

• https://tutsplus.com/course/javascript-fundamentals/
  
• https://tutsplus.com/course/object-oriented-javascript/
  
• https://tutsplus.com/course/advanced-javascript-fundamentals/
  
• http://eloquentjavascript.net/ If you feel you need more coverage of the same topics (interactive html like CodeCademy).
  
• Build something interesting, things like games seem to also challenge your programming skills at the same time. Something like Whack-a-Mole, Connect 4, etc... Don't worry too much about the looks, unless you want to practice that too. At this point you should be able to do basic dom manipulation, events, and basic logic.
  
• The tut-plus courses cost a little for a few months but they're really high quality... most of them also give you projects too.
  
  

  Set up a comfy environment
  

  
  Take some time to start optimizing your development environment, the Paul Irish explains it very well below, but some of the topics are a bit too advanced for now (modules, build tools, etc...).
  
  

• Javascript Development Workflow of 2013
  
• Setup a jshint plugin (~4min above), read the website/docs for all the options. http://www.jshint.com/
  
  
• A more entry level talk on setting up your environment Front-end Tools for the Young Developer
  
  
  

  Learn the native DOM and it's API
  

  
  

• http://domenlightenment.com/
  
• Create your own DOM manipulation library
  
• While this one is a book, it's small and has js-fiddle examples for every code block to try it out... i'm currently going through this and it's great! They have a free HTML version (not final edit) and a cheap softcover on amazon. This will make using jQuery much easier and less 'mysterious'.
  
  

  Learn jQuery
  

• https://tutsplus.com/course/30-days-to-learn-jquery/
  
• https://tutsplus.com/tutorial/jquery-anti-patterns-and-best-practices/
  
• http://fixingthesejquery.com/#slide1
  
• https://tutsplus.com/course/jquery-plugin-development-best-practices/
  
• Re-write one of your previous apps to use jQuery instead of vanilla.
  
• While I love vanilla, jQuery just saves time. Learn when you can easily not use jQuery to gain some easy performance.
  
  

  Read "The Good Parts"
  

  
  Though very cliche at this point, read through this classic. If you don't really understand it all 100%, make sure you hang on to it though as it gets better with age. Try and follow it as close as possible, then later feel free to break the rules. By then you'll know why you can break them.
  
  

• JavaScript the Good Parts
  
  

  Learn Underscore
  

  This is a great library that gives you a lot of cross browser ES5 features and features that should be in JS. Not a lot of tuts on this one, reading the docs and source helps a ton here.
  
  

• http://net.tutsplus.com/tutorials/javascript-ajax/getting-cozy-with-underscore-js/
  
• http://vimeo.com/60216668
  
• http://underscorejs.org/
  
• https://github.com/bestiejs/lodash
  
  

  Learn Backbone
  

  There are lots of these libraries but Backbone is the most popular and easiest to learn. Keep in mind this is a library, not an entire framework like ember. This means in a larger app you will essentially use Backbone to help build you own SPA framework for your app.
  
  

• https://tutsplus.com/course/connected-to-the-backbone/
  
• https://tutsplus.com/course/advanced-backbone-patterns-and-techniques/
  
• http://addyosmani.github.io/backbone-fundamentals/ Great book!
  
• Build a Todo app with backbone
  
• Build a backbone powered Reddit mobile web app, read the following posts for inspiration.
  http://cheeaun.com/blog/2012/03/how-i-built-hacker-news-mobile-web-app
  http://cheeaun.com/blog/2012/03/how-i-built-hacker-news-mobile-web-app_26
  
  

  Learn Node
  

  
  

• https://tutsplus.com/course/introduction-to-node-js/
  
• Build a command line app ( I built a scaffolding app to spit out my boilerplates, and a really janky language transpiler)
  
  

  General Front-End, Programming
  

• Baseline for front end developers
  
• So you want to be a front end engineer
  
• http://pineapple.io/wiki
  
• https://www.edx.org/courses/HarvardX/CS50x/2012/about
  
• I can't stress how helpful the CS50 course has been to me, even on the front end.
  
  

  Read a comprehensive JS book
  

  I really like Nicholas Zakas's book over the definitive guide. I find that he is able to tell more of a story and makes it easier for me to absorb.
  
  

• Professional JavaScript Development
  
• JS the Definitive Guide
  
• Re-read "The Good Parts", this should make much more sense than the first time you read it.
  
  

  Testing
  

  
  Make sure you're comfortable with everything before moving onto testing... this includes frameworks etc.. Learning testing will only slow down the learning process if you're not comfortable with the rest. Mocha is the newer test runner and is better with async. However, Jasmine is very popular and time tested. The "Lets code javascript" below is an awesome course. Don't let the first sections turn you off, they may seem tedious at first (integration server, etc...) so feel to skip to dom/browser testing and then loop back when testing is more normal.
  
  

• http://www.youtube.com/watch?v=eVpXkyN0zOE - Short intro to Jasmine and TDD
  
• https://tutsplus.com/course/javascript-testing-with-jasmine-2/ - Nice n Easy course to Jasmine & TDD
  
• http://www.letscodejavascript.com/ - epic comprehensive JS TDD course from server to browser
  
• 
  
• http://visionmedia.github.io/mocha/ - My favorite runner (with Chai)
  
• http://karma-runner.github.io/ - Test in mult. browsers from the command line (advanced)
  
• https://github.com/rmurphey/js-assessment - test your skills (no pun intended)
  
  

  --
  

  I just started sketching out a website to try and solve this problem. It has different paths to follow to fill in gaps of JS knowledge quickly (much like hackdesign.org)... unfortunately it's not finished yet! Watch LevelUpJS on Github in the future. I also have some more links on app architecture and things like modules but this list is getting a bit large!
  
  Cheers and good luck!
  

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.

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

Here's a good list I keep posting because people often ask the same question - not like it's a bad thing.

In any case follow the below, but I really suggest for total newbies to first go through the course Codecademy offers. It won't teach you much in how to do things but the syntax education is good. Follow their HTML and CSS courses and when you're done, create a site using just HTML and CSS. Once done, try to emulate a few of your favorite sites using just these two languages.

Once done you should check out the free 30 day Tutsplus courses on HTML/CSS and jQuery. At some point you will want to go back to Codecademy and take their JS course. Syntax and method of doing or starting certain things is important. It's incredibly easy to pickup the actual methods of doing things once your head understands the syntax used.

Any form of education that follows a hierarchical format makes for easy learning.
__


Codecademy isn't bad. It won't teach you much in the way of doing things but it does teach you the way to type out code, the general process and stuff. I can't speak for myself because I work as a professional developer and have been tinkering with code for 10 years now, but I did give the first lesson to one of my brothers. He's not great with computers or the Internet, but he was able to follow the first two sections of the basic HTML/CSS course and able to make his own site albeit very basic in nature nearly a month later (3 week gap following him doing the lessons). He was able to do a rough basic site of his Facebook profile, and he nailed it. It should open doors for you in terms of having the basic knowledge of how to do things. It'll allow you to read more advanced stuff and pick it up much faster than if you hadn't.

Below is a list I sent to someone on here a while back.

>
>http://www.reddit.com/r/webdev/comments/1eqaqo/best_books_or_online_resources_for_comprehensive/ca2w2dn?context=3



>PHP and MySQL Web Development (4th Edition)
>
>Beginning PHP and MySQL: From Novice to Professional
>
>Read the second book, do all the examples, then go back to the first book. Pay a lot of attention toward array manipulation. When you're comfortable with that, get into OOP. Once you do and OOP clicks for you, you'll be able to go to town on anything. I've heard a lot of good about Jefferey Way's video lesson courses over at TutsPlus. I've never used them nor do I need to, but I've never heard a single bad thing about their video courses. Their Javascript and Jquery is a great starting point. This is great stuff too if you're willing to put in the time.
>
>Professional JavaScript for Web Developers
>
>JavaScript: The Definitive Guide: Activate Your Web Pages
>
>Responsive Web Design with HTML5 and CSS3
>
>The Node Beginner Book
> Professional Node.js: Building Javascript Based Scalable Software
>
>Paid online "schooling":
>
>http://teamtreehouse.com/
>
>http://www.codeschool.com/
>
>Bonus:
>
>http://hackdesign.org/
>
>
>I've got a shit ton (Excuse my French) of books in print and E-Format that I could recommend, but it would span a couple pages. Anything is easy to learn so as long is it's served in a hierarchical format that makes it easy to absorb the information. A year ago I started to learn Ruby and using ROR as a framework. I can say it's been quite fun and I feel confident that I could write a fully complete web app using it. I started node.JS a few months ago, but it's been on break due to being sick and some unexpected events.
>
>My knowledge is extensive only because I wanted it to be. I'm not gifted by any means nor am I special. Not by a longshot. Some people are gifted when it comes to dev and design, most are not. Most only know one or the other. I forced myself to learn and be good at both. I'm 23, I started when I was about 12. I'm only breathing more comfortably now. I know a load of people on here and other sites who make me look like complete shit.
>
>
>Also for what it's worth, sign up to StackOverflow. It's the bible and holy grail rolled up into one site. It's amazing.
>
>Also;
>
>Hattip to /u/ndobie
>
>> CodeAcademy
> Team Treehouse
> CodeSchool. This is more programming but still very useful & has free stuff.
> Tuts+
> Google. Probably the best way to find out how to do something specific.
> This subreddit. If you have any questions about how to do something, like parallax scrolling, try searching for it, then ask, make sure to include an example of what you want if you don't know what it is called.

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!

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 took a deeper look at FCC. Before I was a bit against it due to how dry/textbook-like it is, but after taking a second glance I think it can definitely do the job.

However, I still stand by this roadmap, especially because I tested so many different free courses online (and subsequently wasted a bunch of time). Hopefully someone will find this useful.

Rithm (https://www.rithmschool.com/courses)

• Awesome for going from 0 to beginner/intermediate; possibly the best fundamentals I've found
  
  
• Doesn't hand hold so it teaches you how to think
  
  
• Writing is friendly and understandable
  
  Eloquent JS (http://eloquentjavascript.net/)
  
  
• Great for solidifying intermediate
  
  
• This is when you begin to learn "real" coding
  
  
• Can be difficult to grasp, but with a solid understanding of the fundamentals, you should be good
  
  Secrets of a JS Ninja (https://www.amazon.com/Secrets-JavaScript-Ninja-John-Resig/dp/193398869X)
  
  
• Great for going from intermediate to advanced
  
  
• If you've methodically mastered the previous two, you will be good. Really deepens your understanding and sharpens skillset
  
  Finally, if you supplement all this with Codewars (https://www.codewars.com/ , allows you a bunch of puzzles/katas to check your level as you progress; great because you can go back and see how your skills have actually improved, you'll definitely cringe at some of your old code, ha), it's a pretty fucking awesome roadmap to get you from 0 to advanced, though it'll take a LOT of work. There are no shortcuts!
  
  Hit me up if you have questions, always down to help others get started.

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

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!

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.

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!

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

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

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

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

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

x86 Assembly:


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


A few good books would be:

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

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

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?

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

Jumping into C++: Alex Allain

Write Great Code: Volume1 Understanding the Machine

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

Reversing: Secrets of Reverse Engineering

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

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

.

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

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

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
  
  

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.

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

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.

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.

Hey, I'm flattered you care what I think!

I learned basic Objective-C on my own in high school (read this one during boring classes), and then went on to do a Bachelor in Computer Science at uni. Learning some basic programming really helps, because at least at my school it was very much fundamentals for the full first year, and if you understand them well enough it'll be a breeze.

That being said (and take this with a major grain of salt, as it's just me) I wasn't that big a fan of school. I got into and taught myself iOS development as my school, like most, was mostly based around Computer Science theory rather than practical applications and programming. I did learn some valuable things about algorithms and whatnot, but it's nothing that I couldn't have taught myself and everything that I've found to be "marketable" (things that have helped me get jobs) have been self-taught.

But university's awesome for a whole wealth of reasons (met awesome people), and you may adore it, I'd just be very careful not to learn a wealth of knowledge but have little experience applying it to anything concrete. Employers appreciate the latter far more (my GPA was rather meh, and I got some really cool jobs).

I do most of my work alone, but a lot of smart people have helped me along the way. :) It's just how I personally like to work at the moment. If you have any more questions I'm happy to answer. r/cscareerquestions as mentioned is a great resource too!

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

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 found Lynda.com to be extremely dry and slow. To me it was the equivalent of those old school mandated educational movies you would watch in classrooms back in the 90s on your faux-wood tv. Take this opinion with a grain of salt though as it has been almost two years since I have looked at anything on Lynda, I hear it may be better today.

If you are looking for web development in particular I would suggest the following:

• Codeademy - Free and very good at introducing basic web development skills.
  
• Team Treehouse - Paid subscription but well worth it in my opinion as they will walk you through everything from the most basic HTML to building advanced JavaScript applications.
  
• CodeSchool - CodeSchool tends to be more advanced and I would wait until you have a strong grasp on your HTML, CSS and JavaScript before investing in their coursework.
  
  In addition, StackOverflow; A general programming Q&A website, has an answer to just about any programming issue you may be running into. If the answer is not already there, then chances are you will have one within 24hours.
  
  I began my pursuit into web development about 2 years ago. In that time I have gone through the resources listed above as well as the following books which have helped immensely:
  
  
• HTML and CSS: Design and Build Websites - Ducketts whole series is extremely friendly to the new web developer and will help you build a solid foundation quite quickly.
  
• JavaScript and JQuery: Interactive Front-End Web Development - Another Duckett book which was just released focusing primarily on JavaScript.
  
• JavaScript: The Definitive Guide - A massive JavaScript reference. It has answers to just about everything.
  
  Some personal career history if you're interested:
  
  In the last two years I have gone from making 18k a year as a Technical Support Representative to 80k a year as a Front-End Engineer building JavaScript applications at a large FDIC Bank. It was only in the last two years that I really dug into Web Development (and programming for that matter) and I really can't see myself ever doing anything else for a living. The job requires an immense amount of learning (which I love) and will keep your mind sharp. I really do get a kick out of problem solving all day. Programming will require a major adjustment to the way you think. I can say that the way I work through problems now is completely different to the way I did before. I feel as if critical thinking has eluded me until the last two years and it has been a major life changing event. By far the biggest contributing factor to my growth has been the team I work with. You have to do your best to find a team that is willing to work with you as a junior so you can siphon that knowledge. Even if that means taking a low paying job, however; know your worth so that you can ask for the right amount of money once you have gained the necessary skills. As a personal rule of thumb, I will not stay at a company where I am the most knowledgable member of the team. This inhibits growth as a developer and will prevent me from realizing my true potential.
  
  Feel free to hit me up if you have any questions.
  
  
  

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.
  

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

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

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

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

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

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.

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.

The best way I know how is by solving problems yourself and looking at good solutions of others.

You could consider going back to "fundamentals".

Most programming courses, IMO, don't have nearly as many exercises I think they should have. Some books are particularly good on their exercises list, for example K&R2, SICP, and TC++PL. Deitel's has long exercises lists, but I don't think they're particularly challenging.

There are some algorithms/DS books which focus on the sort of problem solving which is about finding solutions to problems in context (not always a "realistic" one). Like the "Programming Challenges" book. In a book like that, a problem won't be presented in a simple abstract form, like "write an algorithm to sort numbers". It'll be inside some context, like a word problem. And to solve that "word problem", you'll have to find out which traditional CS problems you could solve/combine to get the solution. Sometimes, you'll just have to roll something on your own. Like a new algorithm for the problem at hand. In general, this helps you work out your reduction skills, for once. It also helps you spotting applications to those classical CS problems, like graph traversal, finding shortest plath, and so forth.

Most algorithms/DS books though will present problems in a pretty abstract context. Like Cormen's.

I think, however, people don't give enough credit to the potential of doing the exercises on the books I've mentioned in the beginning.

Some books I think are worth reading which also have good exercises:

• http://www.amazon.com/The-Programming-Language-2nd-Edition/dp/0131103628 - K&R2
  
• http://www.amazon.com/Elements-Programming-ML97-Edition-2nd/dp/0137903871
  
• http://www.amazon.com/Database-Systems-Complete-Book-Edition/dp/0131873253
  
• http://www.amazon.com/Structure-Interpretation-Computer-Programs-Engineering/dp/0262510871 - SICP
  
• http://www.amazon.com/The-Programming-Language-4th-Edition/dp/0321563840 - TC++PL
  
  I imagine the other Stroustrupp programming book also has good exercises, but I've never read it. Brian Kernighan is not only the author of K&R2, but of many other books. You could look at his stuff.
  
  Depending on what you mean by good code, though, you could look at other books.
  
  There are also the math books. I'd not discard those. And also, there are other programming books as well. Some I've never read, but want to, like Programming Pearls:
  
  
• http://www.amazon.com/Programming-Pearls-2nd-Edition-Bentley/dp/0201657880
  
• http://www.amazon.com/More-Programming-Pearls-Confessions-Coder/dp/0201118890
  
  Not only those, but, anyway... The point is that you can look at those books to find examples of good code, good exercises, challenges and so forth.
  
  Here are some books I've mentioned previously:
  
  
• http://www.amazon.com/Programming-Challenges-Contest-Training-Computer/dp/0387001638 - Programming Challenges book;
  
• http://www.amazon.com/Introduction-Algorithms-Edition-Thomas-Cormen/dp/0262033844 - Cormen's (and other 3 authors) book.
  
  By the way, there are websites with programming challenges for you to look at too. Like https://projecteuler.net/ and others. Just start looking this up and you'll find plenty. They all tend to start dumb easy and move up the difficulty to pretty damn difficult stuff from what I've heard.
  
  Edit: SICP is available for free (http://mitpress.mit.edu/sicp/) together with videos from the course taught at MIT in 85 (http://ocw.mit.edu/courses/electrical-engineering-and-computer-science/6-001-structure-and-interpretation-of-computer-programs-spring-2005/video-lectures/).

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

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

Not tutorials, but I highly recommend the following JavaScript books:

JavaScript The Definitive Guide (6th Edition, Flanagan)

http://www.amazon.com/JavaScript-Definitive-Guide-Activate-Guides/dp/0596805527/ref=sr_1_1?s=books&ie=UTF8&qid=1310948024&sr=1-1

Pro JavaScript Design Patterns (Harmes/Diaz)

http://www.amazon.com/JavaScript-Design-Patterns-Recipes-Problem-Solution/dp/159059908X/ref=sr_1_1?ie=UTF8&s=books&qid=1310948075&sr=1-1

JavaScript Patterns (Stefanov)

http://www.amazon.com/JavaScript-Patterns-Stoyan-Stefanov/dp/0596806752/ref=sr_1_1?s=books&ie=UTF8&qid=1310948115&sr=1-1

Object-Oriented JavaScript (Stefanov)

http://www.amazon.com/Object-Oriented-JavaScript-high-quality-applications-libraries/dp/1847194141/ref=sr_1_1?s=books&ie=UTF8&qid=1310948145&sr=1-1

Most people swing from Douglas Crockford's nuts and recommend JavaScript: The Good Parts (http://www.amazon.com/JavaScript-Good-Parts-Douglas-Crockford/dp/0596517742/ref=sr_1_1?s=books&ie=UTF8&qid=1310948183&sr=1-1).

I received a free copy while at Yahoo in 2008 and honestly, I didn't find this book that good of a read. I felt it was definitely geared more towards those with formal CS backgrounds. Keep in mind, I definitely need to re-read it (to see if I feel the same way), but I read it a couple times back in '08 and tossed it on the shelf. The books I mentioned above I've read several times as well and can only say buy them. I'm on my 2nd read of Flanagan's book now.

jQuery in Action is a decent book, but the copy I have is for 1.3, I think. I think I have the first edition and it looks like there is a second.

http://www.amazon.com/jQuery-Action-Second-Bear-Bibeault/dp/1935182323/ref=sr_1_1?s=books&ie=UTF8&qid=1310948303&sr=1-1

jQuery Reference Guide 1.4 is also good, but it's for 1.4 and jQuery is at 1.6 now so it's tough for the books to keep up! I think it's pretty much the online/official reference guide as well

http://www.amazon.com/jQuery-Reference-Guide-Jonathan-Chaffer/dp/1849510040/ref=sr_1_2?s=books&ie=UTF8&qid=1310948347&sr=1-2

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

As /u/mr_stark said you have the interest and love for it which is a big plus. Don't get discouraged, programming is not just about the language or the language. It is about problem solving, collaboration and design.

I always recommend stepping back from the code when you first approach a problem. How would you solve the problem if someone asked you to do it using regular English sentences.

For example "tell me the length of a string"
*Go through each character and add 1 while I have not reached the end

• return the end result
  
  Learn your data structures. Arrays,Lists, Hash Tables, Dictionaries they all typed of problems they are good for and types of problem they are horrible for. Learn the difference, and when to use which.
  
  Once you have these two down, you are now ready for the different algorithms. This is where the design comes in. This book is very good at helping with this. It's old but a very good book.
  
  Note that as you are learning this you should choose a language and code up the different data structures and do small programs to learn the ideas. This will also teach you the language as you go along. www.coursera.com is great for free courses and resources.
  
  Once you have the basic ideas you can start getting more in depth courses for the languages you want to learn. For C# I recommend CLR via C# for example for C#.
  
  Lastly as with most things the only way you will get better is practice practice practice. Start creating apps to help yourself out and automate daily things you do. Start exploring and creating different applications.
  
  Hope this helps!
  Good luck!

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

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.

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();).

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!

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

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.

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.

Check out this online book, it covers a wide array of PHP topics, but there are some solid chapters on objects including the building of a basic OOP website.

The book, PHP Objects, Patterns, and Practice is an incredible resource of PHP OOP concepts and application design. It starts off with a few chapters on the basics of OO PHP coding, giving you the rundown of syntax and inner-workings. From there it covers popular OOP design patterns (MVC, Adapter, Component, etc) and then lives up to its name by showing the patterns in practice.

After you've picked up the basics of OOP, check out a PHP web framework. I would recommend CodeIgniter for its amazing documentation, not to mention this wonderful set of video tutorials CodeIgniter from Scractch featured on Nettuts.

Once you get a working knowledge of a framework and have built some basic applications and websites, take the time to study the code behind the framework. Find out where the entry point is and trace its execution, checking out the source for each and ever object that is instantiated. Not only will you pick up on some sweet OOP concepts, but you'll gain a great understanding of how a typical OO PHP application is structured.

Good luck and have fun!

Keep your programs DRY! (Don't repeat yourself) In procedural, you would take those large blocks of code and faction them up into functions. With OOP, look even more abstractly and take several large blocks of related code and put them into classes, which are, at a very basic level, a collection of related functions and properties.

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.

You mentioned some issues that sound like code cleanliness and structural issues. Getting better at algorithms really comes down to practice and exposure, there's no shortcut to this. But there's no reason to suffer from bad coding practices if there's room to improve.

A few books come to mind, which may seem like they're coming from left field, and may not seem immediately useful to the task of solving algorithm puzzles, but might be useful in the long term for you to learn how to write correct, clean code and reduce uncertainty:

• Code Complete 2. Some good tips in here regarding code cohesion, and how to write functions and classes cleanly.
  
• Clean Code. More on writing functions cleanly, along with design & testing.
  
• How to Prove It. This is a great book that delves deeply into logic. Even just the first chapter or two could be incredibly useful to you. It discusses things like DeMorgan's Laws, which show up a lot in programming and electronics. It deconstructs common logical concepts and phrases into boolean algebra and set builder notation (which inspire Python's list comprehensions). The world of math and logic and proof is not completely isolated from the world of programming.
  
  EDIT: One other thing is to make sure you understand the limitations of how computers represent numbers. The need for this understanding will become clear very quickly on, say, Project Euler problems. Look into bits, values, integers, signed vs unsigned, IEEE754 floating point.
  
  And one other thing is that it's easy to compare your solutions against some of the best solutions that exist for those problems and think you're doing a bad job when in fact you're doing an alright job if you manage to solve the problems with decent runtimes. Mind your 80/20 rule here. The extra time it probably took those people to craft those solutions is not 0, which includes whatever time they spent over the years becoming an expert at that language, etc.

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

I will agree that it isn't cheap but if you're serious about your professional development, it is well worth it. If you want to just try it out, they have a 10 day free trial.

To be honest, though, I'm not sure what you mean by "advanced topics and concepts." There are plenty of courses on PluralSight that I would consider advanced but it sounds like there is only one on there that interests you.

Regardless, if you are looking for something more intermediate, PluralSight has you covered. If you're looking for something more advanced than PluralSight can offer, maybe you should look into https://www.amazon.com/CLR-via-4th-Developer-Reference/dp/0735667454

Edit: I'd like to add that http://bafflednerd.com/learn-csharp-online/ was on this subreddit the other day and seems like a pretty thorough list. Free courses and never as good as paid ones, though (in my experience).

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

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.

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.

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!

Interesting comment on compiling it with VS, i tried it in VS 2012 with /W3 and only recieved

warning C4551: function call missing argument list

compiling with /W4

warning C4189: 'asnwer' : local variable is initialized but not referenced

This lack of warnings from the compiler is a bit disturbing heh. Compiling with /Wall spits out a bunch of other unrelated stuff. Perhaps try changing to /W4 in the project properties C/C++ tab.

I'm not surprised that Ask and Say where called a few times, stepping through your code Say i think would be called twice and Ask would be called 4 times. Rough guess heh. The reasons for this are how your code is written

On line 33 you call Operator(), which calls Say() on 22, Ask() on 23 and Ask() again on 24. This call returns and next Operator is called again on line 34, calling Say() again and Ask() two more times.

The issues with the program i believe arise from a lack of understanding of C++, learncpp is an ok site, but really all online C++ tutorials are crummy/mediocre at best. You should pick up a real book, a commonly recommended one for beginners to programming and C++ is C++ Primer Note: NOT Primer Plus, just Primer.

The only reason is that the return type signifies sort of signifies your intentions with what to do with what's being returned. If you return bool, you clearly wish to check if something occurred or didn't. However returning int or char could be used in many more things. What I'm trying to say is that char/int will work, but bool is far superior in this situation.

You could really do with a good book to learn from. If you'd like me to pick over each issue with this program and help you work out a working version I can, although I'll be heading to bed in about an hour and it'd probably be more helpful to get a good book than focus on this one program.

Most important: to truly learn C++ you'll need a good book.

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.

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.

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

What about some classics like Uncle Bob talks?

A lot of good design focuses on decoupling and creating components which work together but separately also.

Id first look into language agnostic design principles such as SOLID

https://youtu.be/TMuno5RZNeE
https://youtu.be/zzAdEt3xZ1M (golang)

A good book will help.

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

I still keep a copy of the Gang of Four book at arms reach even tho the popularity is dwindling as OOP is not topic of most convos today. However when dealing with DI and sharable components in Golang, i find myself still falling back to abstract factories patterns. Its a good breathe of knowledge to at least glimpse at the patterns here:
Design Patterns: Elements of Reusable Object-Oriented Software https://www.amazon.com/dp/0201633612/ref=cm_sw_r_cp_api_i_7BzvDbXJC5WS4

Once you get thru these topics, you can start picking up what I consider the "hot" architectures of today:
Microservices, event based systems, domain driven design, event sourcing, and architectures aiding themselves to functional programming.

I really enjoy reading Martin Fowler blog posts: https://martinfowler.com/tags/application%20architecture.html

He covers a lot of these topics.

PS: maybe a niche and a personal favorite of mine but ive learned ALOT by researching the different types of kernel architectures. Nothing really geeks me out like those topic, but not for everyone.

A fabulous free course exists on these topics:
https://www.udacity.com/course/advanced-operating-systems--ud189

For the purposes here I will basically define my terms I am using.

...

Alone will mean that there could be other methods, variables, etc that I am not accounting for. Basically it is saying "Below or above this is a snapshot of an interesting area.. there would be other code too!".

While

myMethod(...);

or

public void myMethod(...) {...}

Is saying "I don't know what you'd put there. It depends on what you decide" In the case of:

(...)

We are talking about unknown parameters passed to a method.

In the case of:

{...}

I am talking about an "unknown method body". Meaning I don't know what the logic would be (or am too lazy to type it out).

==
==
So a problem will certainly occur in GameView. Perhaps I was misleading you with what to do though. You have this line of code (198) in GameView.java

myGameView = new GameView(getContext());

That is will cause an infinite loop. Which means I may have not been clear earlier on how to use GameView correctly (because this is clearly a line of code I suggested).

Each time the "new" keyword is used its going to create a new instance of GameView. It does that by calling this method

public GameView(...) {...}

But inside that method is this statement:

myGameView = new GameView(getContext());

Which is going to call this method

public GameView(...) {...}

You can see the loop now and where the problem is happening.

This is probably the cause of your stack overflow. It will keep creating GameViews until the end of the universe.

Lets talk about how to fix it and where you should be using the new keyword.

==
==

About fixing your program to run.

If we look inside your GameThread.java class we see this line of code in the run() method.

GameView.myGameView.onUpdate();

You're trying to reference GameView as static still. This wasn't what I was trying to initially get at. Instead you should create a variable in the GameThread that stores the GameView as a new object and access that directly.

public class GameThread<MainGamePanel> extends Thread {
...
private GameView myGameView;

public GameThread(...) {
...
Context context = someMethodToGetContext();
this.myGameView = new GameView();
...
}

then in your run method you can call that object directly without static references etc.

public void run() {
...
// somewhere in the appropriate spot
myGameView.onUpdate();
...
}

This means you could remove all the static from all your fields and methods in GameView and instead use it as an object.

==
==

This part is simply about writing slightly better code :)

Also one more thing that would make your code easier to read and understand. I try to abide by uncle Bob's standards.

You should place your constructor as the first method in the class:

public class GameView extends... {
// class fields here

public GameView(..) {...}

// All other methods here.

You shouldn't include unnecessary comments like:

// Global Variables
// -------------------

Because we already know what they are. It is convention to put them at the top of a class.

Furthermore anytime you feel the need to do that inside of a method like:

// Draw Stars
// ---------------

This shouldn't be done. Instead you should create another "Helper" method that does that, named exactly what the comment would be named. This will help with readability and it will become easier to maintain since each function will do one specific thing.

protected void onDraw(Canvas canvas) {
drawStars();
drawAnyBullets();
}

is alot more clear and easy to read. Generally There is a rule. That is if you have more than 1 or 2 levels of indentation inside a method you are probably having it do more than one thing and should break it up into smaller methods (that will be easier to read, and more abstract thus easier to write).

Then we want our methods in our class to go from "most abstract" to "least abstract" in our class structure:

public class GameView extends... {
// class fields here

public GameView(..) {...}

public void onDraw(Canvas canvas) {
drawStars(...);
drawAnyBullets(...);
}

public void drawAnyBullets(...) {
drawPlayerBullets(...);
drawEnemyBullets(...);
}

public void onUpdate() {
if(touched) {
update();
}
}

public void update() {
renderBullets();
renderStars();
renderEnemies();
keepShipInBoundaries();
}

...

// Other methods past here include some logic, but still not full logic

public void drawPlayerBullets(...) {
ArrayList projectiles = PlayerShip.getProjectiles();
for (int i = 0; i < projectiles.size(); i++) {

LaserShot p = (LaserShot) projectiles.get(i);
Color color = Color.CYAN;
drawProjectile(p, color);

}
}

....

// Other methods past here include all logic, no other method calls for this class.


public void drawProjectile(LaserShot projectile, Color color) {
paint.setColor(color);

int coordStartX = projectile.getX();
int coordStartY = projectile.getY();
int coordEndX = coordStartY + laserlength;
int coordEndY = coordStartX + laserwidth;

canvas.drawRect(coordStartX, coordStartY, coordEndX, coordEndY);
}

...
}

From here in one fell swoop we eliminated a lot of redundancy. Now whenever you want to place a projectile you simply call the abstracted "drawProjectile" method. Never again worrying about the minute detail.

Want to change how a projectile draws? Don't have to change every line of code. Simply change drawProjectile.

The more you break up your code into logical chunks the more often you'll find yourself able to replace certain lines of code with previously written logic. The easier your life will become.

You'll have to decide where to place the methods. What the best break up of functionality is. What parameters to pass into the methods themselves, etc. But that is all part of learning to code.


This might have looked complicated but I think you have it in you.

In fact your comments show me is that you know how to break your methods apart in logical chunks. This is good and is probably better than most beginning programmers. Now take it to the next level and break out those logical chunks into their own methods!

Reversing: Secrets of Reverse Engineering - Is probably the most common book recommendation. Its an older book (2005) but its about as gentle as it gets in terms of the core concepts but its missing a bit due to its age (32bit RE only). I'd liken it to something like Hacking: The Art of Exploitation for exploit developers. Its a solid book, it covers the fundamentals but it'll take a bit more work to get up to speed.

Practical Reverse Engineering - This one is a newer book (2014) while it doesn't cover as many topics as the above book, its less dated in what it does cover, and it does cast a wider net covering things you'll see today like ARM and x64 instead of just x86. I tend to recommend starting with this book, using Reversing and the next book as a reference if there is a chapter of interest.

Practical Malware Analysis - While this one has more traditional RE introduction, where it excels is in dynamic analysis and dealing with software that doesn't want to be analyzed. Now, its from 2012 and malware has changed since then, so its age certainly shows, but again fundamentals remain even if technical details change or are expanded upon.

Practical Binary Analysis - This is the newest book of the list (December 2018). It wouldn't use it alone, but after you've gone through any of the above books, consider this an add-on. Its focus is on dynamic analysis and its modern. I'll admit I haven't read the entire thing yet, but I've been pleased with what I have read.

Edit: s/.ca/.com/g

> Maybe now is a good time to step back and consider what kind of programming job you might want to target.

This is definitely something you should keep in mind. Try to become really awesome at one thing. That's not to say you shouldn't have a well rounded education in programming, just that someone who is simply ok at everything isn't getting a job anywhere.

Here are a few texts which I consider to be great for a novice programmer:

The C Programming Language : ANSI C

It's an older book, but it's still the best book to learn the language.

C++ Primer : C++

I used this book to get started with C++, and found it to be easy to follow and informative. Some say it's not a beginner book per-se, they may be right. I was already very familiar with C when I started.

Objective-C Programming: The Big Nerd Ranch Guide : Objective-C

If you're planning to write apps for Apple's iOS and OS X platforms, you're definitely going to need to learn this. Otherwise, don't bother.

Algorithms : Algorithms / Data Structures

This is not the be and end all authority on algorithms, but it's a great book. It's less theoretical and more concrete in my opinion.

I don't feel qualified to give recommendations for other topics like Java or web development, as those aren't really my strong suits. Happy hunting!

Ah, the context of the Uncle Bob rant from a few weeks ago. I don't see how any of the author's particular complaints have anything to do with TDD:

> You therefore are more reluctant to make large-scale changes
> that will lead to the failure of lots of tests. Psychologically, you
> become conservative to avoid breaking lots of tests.

This is a bad thing? If you think a whole lot of tests might break if you make large changes, clearly there are massive side-effects to the change you propose, and then wouldn't a conservative approach to making the changes be the right thing to do?

Personally, I like fixing broken tests when I make large changes. It gives me greater confidence that I won't introduce regressions and allows me to understand the impact of what I am doing and gives me insights to the design of the system, particularly when it comes to the level of coupling.

But, this is the consequence of having a test suite, and doesn't say anything about whether that test suite was created through TDD.

> Sometimes, the best design is one that’s hard to test so you are
> more reluctant to take this approach because you know that
> you’ll spend a lot more time designing and writing tests

The author didn't give an example of this, but I am assuming he probably means GUIs. Well, not everything needs to be tested, and especially with TDD. The key is to separate code that needs to be tested from code that doesn't (or tested in a different way).

When it comes to GUIs, I usually write a "shell" without tests (because really, besides interaction, what are you testing?) and delegate functionality to interior objects which I definitely implement test first.

Another example I can think of is heavily algorithmic code. Like, back in the day, I worked on seismic processing software. Well of course, you don't develop those kinds of algorithms test first (or, maybe in a very different way - the geoscientists involved wrote papers which discussed the math involved before writing any code). But again, like GUI programming, the seismic processing algorithms were isolated from the rest of the system, which was written test first.

TDD works well for some types of code and not others. The requirement of using judgement to decide the development processes for specific cases has nothing to do with the effectiveness of TDD as a general practice.

> The most serious problem for me is that it encourages a focus
> on sorting out detail to pass tests rather than looking at the
> program as a whole.

No it doesn't. Test-first just means you write tests before you write the code. That doesn't mean you can't look at the program as a whole first before that. The first half of Uncle Bob's book Agile Patterns, Principles and Practices is devoted to UML. Yes, you heard that right.

Check out this chapter from that book, Heuristics and Coffee. Before diving into the code, Uncle Bob spends a good chunk of time going through the use cases and coming up with a first pass at a high level structure for the system, in UML.

TDD is one part of "Agile" software development, where the rubber hits the road. But before you start driving, you should have a basic idea of where you are going, which is design. The "epicycles" of TDD then serve to validate that you are on the right course, from minor turn-by-turn directions to occasionally stepping back and making sure you are still on course.

The idea is to come up with as much UML as necessary to get a basic idea of the overall design, and then use TDD to execute and validate that design, incrementally.

The author is taking TDD out of context and missing the bigger picture.

> But the reality is that it’s often hard to specify what ‘correct
> data’ means and sometimes you have to simply process the data
> you’ve got rather than the data that you’d like to have.

What does this have to do with TDD? Again, TDD is a part of a larger process, which involves the business. Software that does "real work" doesn't work in a vacuum. Programmers have to deal with the business to understand the data to the best of their ability, and even still, you'll still make mistakes.

At least the tests document an executable understanding of the data, and test failures can actually give valuable insights on changing assumptions of the data.

Well, if I were evaluating this in an interview these would be my thoughts:


I don't like one letter parameters like String s. It's pretty obvious here since there's only one parameter and the method name tells me what's going on, but this can lead to unreadable code for larger methods with more parameters.

The 0 length string guard at the start is nice, although necessary here. Unnecessary code makes things cluttered and less readable.

The if(!p.equals(" ") ... statement is unnecessary. When you split the string it should essentially remove any white space. When reading code a lot of time is often spent on interpreting complicate predicates, so it's good to remove unnecessary ones or abstract it out into a method. Unnecessary code makes things cluttered and less readable.

if (!p.equals(" ") && !p.equals("")) could easily be a method isValidWord(p), which lets me read the flow of the statement without necessarily reading the innards of what a valid word is. I can do that later, but right now I just want to understand the logical flow of what's happening. Again here, it's fairly obvious, but when things are more complicated and validation criteria are more convoluted these are good abstractions to make.

stack.push(p.trim()); again seems redundant. There won't be any padding whitespace when you split the string to an array. Removing unnecessary code leads us to

for (String p: parts) {
stack.push(p);
}

Also, while we're here, why p and not part? If you're trying to go full on readability, one letter variables are basically outlawed except as indexes.

for (String part: parts) {
stack.push(part);
}

While we're still here, why parts and not words? Words is more descriptive of what the variable represents. You always want descriptive variables. The goal of clean code is generally readable code. Although part could be argued as appropriate here. Word just conveys more meaning to me.

I don't know if you were told not to use existing APIs, but taking advantage of existing abstractions makes code more readable in general. For instance

public static String reverseWords(String s) {

List<String> words = Arrays.asList(s.split(" "));
Collections.reverse(words);
String reversedString = "".join(" ", words);

return reversedString;
}

Just looking at the above you can pretty much tell what's happening. We have a List of words, we reverse it, then join that list into a string. you can even abstract out more things, but this is probably overboard. But if we go down that route you essentially have 3 lines of code to read to understand what your logic is. Build a list of words from a string, reverse it, then join that list together into a string.


public static String reverseWords(String s) {

List<String> words = buildListOfWordsFromString(s);
Collections.reverse(words);
String reversedWords = joinListOfWordsToString(words);
return reversedWords;
}

private static String joinListOfWordsToString(List<String> words) {
return "".join(" ", words);
}

private static List<String> buildListOfWordsFromString(String s) {
return Arrays.asList(s.split(" "));
}


Anyway, these are just my thoughts and people will disagree. This is still one of the best books to read if you're interested in writing more readable code.

Agreed. There are plenty of resources out there that will help you understand design patterns. If you're new to the concept, I would recommend Head First: Design Patterns, it might be based on Java, but the examples are simple to understand and can mostly apply to PHP as well. When you feel like you've grasped the basic concepts of design patterns, you can move on to more advanced texts, like Martin Fowler's Patterns of Enterprise Design - this is a great reference for a lot of the more common patterns. There is also Refactoring: Improving the Design of Existing Code. These are great investments that will help you with any project you work on, and will help you if you decide to use a framework like Zend which uses design patterns very heavily.

It does the job, good stuff! I think you've got loads of suggestions about the actual code / arrays.

For me an important programming skill is called "clean code", there is a book.

It may be a little over the top given you are learning arrays, but I'll rabble on a little bit about it as I think its quite a simple premise and also I think a real good thing to start doing as soon as possible as it can keep clean and code simple.

Essentially how to make your code easier to read and understand. It applies to any coding, not just java. Short can curlies relating to your code post, meaningful naming and small methods that do basically 1 thing.

So for example take line 25:

if (userChoice > 12 || userChoice < 1) {

I dont know right away what that is doing or it means. Given we are talking about months, this looks like a range check and looking at the code within the if statement I can figure out it looks like this is the "good / valid" part of the check and we another have a bad / error check as well.

But the problem is I have to figure that by looking at what the code is doing. In another example where its not months / something new to me and the if's are doing something a little more clever, it'd be alot more difficult to figure what the code is doing.

So one / the traditional solution is to write a comment something like:

// bounds check the user input to make sure its a valid month
if (userChoice > 12 || userChoice < 1) {

But comments are likely to get old + out of date if someone makes changes and ignores the comment (happens all the time). They also muddy up the code with extra lines / make it harder to read + understand.

So an alternative way is extract the if logic to another method and give it a nice friendly name, for example:

if(isValidMonth(userChoice)) {
... rest of method...
}

private boolean isValidMonth(int input) {
return input > 0 && input< 13;
}


Now when you read you read that if statement its telling you exactly what its doing so you dont have to figure anything out yourself. Its quick, easy and clean. If this logic is difficult / doing something odd, then rather a comment, you can right some javadoc for the method.

See my example below of one way the main loop in your application could look:

while (continueInput) {
printUserMenuToConsole();
userChoice = userInput.nextInt();

if (isValidMonth(userChoice)) {
printSelectedMonthToConsole(userChoice);
String askQuit = getIt.nextLine();
continueInput = isContinueInputQuit(askQuit)
}
else {
printErrorMessage(userChoice);
}
}

You can see how that loop now is much more readable, its telling the reader what its doing. Essentially what is happening is taking a method that does a lot and break it down into smaller more manageable chunks and separating process and logic.

It still is a little clunky, we could take that one step further:

private void doUserInputLoop () {
boolean continueInput = true;
while (continueInput) {
printMonthMenuToConsole();
takeUserMonthAndPrintToConsole();
continueInput = doesUserWantToContinue();
}
}

You can see here the logic / complexity of all the months is now stripped out each into there own methods and this method is not much smaller and is all about the process of the loop. Within 2 seconds you can understand what you app does by reading those 3 lines, print menu console, get user input and print to console and ask use if they want to loop again. Its a little clunky with the while loop / boolean but its not too bad.

Its handy as well becuase if the code tells you what its doing, you never (or very rarely) need to write a comment.

Word of warning, balance is everything, this can be taken too far. The key is to name variables / method names fully to describe what they do (your variables are good). If you cant / struggling to come up with a name or they are getting too long, then its warning bells that a bit too much is going on / there is probably a simpler way to achieve what you are trying to do.

It's perfectly fine in an isolated assignment like this, but it's also easy to start using exceptions as a part of code flow in larger software when you are writing programs for a living. And that's when bad stuff might happen, plus it is harder for your co-workers to decipher what your methods are supposed to do.

Effective Java by Joshua Bloch is probably the best book you can read if you want to improve your code. It's not that thick, and it's divided into "items" that are easily read in any order you like. For instance, there is an item about exceptions, just like your case, but probably way better explained than I did :)

Things like this might seem nitpicking, but in my opinion the easier it is to read your code, and the more robust your methods and classes are, the better. Otherwise you produce spaghetti that people have to maintain 10-15 years from now and they will curse their miserable lives every day. I've been there, it really opened my eyes :D

I just resently started a carreer as a Java Developer myself (m/22), so I can remember the things I had a hard time with like it was yesterday.

What I had the most trouble with, carreer wise, is the configuration of a lot of frameworks. Java in itself is relatively easy (especially since you already are an experienced developer), it's the frameworks that require the most time to learn. A lot of them require a certain amount of configuration, mostly in XML. Learning how to set them up was mostly trial and error in my case. Like someone else said in the comments, pet projects are the best way to learn this. So, to answer your question about what I hate about Java: this configuring is it. Stuff like that is easier in, say, C#. However, if you join an already existing project, the configuration is already done most of the time (although not always very good).

Now for the resources. I really did a bad job with Java in my first year of college, but this guy really helped me with his tutorials (I got 100% percent when I took the exam again): [The New Boston] (https://www.youtube.com/playlist?list=PLFE2CE09D83EE3E28). I linked you the beginner tutorials, but he also has intermediate. [Effective Java] (http://www.amazon.com/Effective-Java-Edition-Joshua-Bloch/dp/0321356683) is also a good resource, like mentioned in the comments. Another one I like is [The Well-Grounded Java Developer] (http://www.manning.com/evans/). It is a really balanced book, talking about important things like Threading, the JVM, Dependency Injection, Continuous integration etc.

I would suggest you first do some little projects to get a feeling with Java as a language, and then stepping over to frameworks like Spring and hibernate. Check the differences between Spring and Java EE, read about dependency injection (Martin Fowler has a great article about this), etc.

This turned out longer than I expected, so I'll leave it at this. If you still have questions, feel free to PM me or leave a comment.

Objects are for grouping related data and methods together. It really is as simple as that.

Start off by writing applications where you're just creating and consuming objects, not writing your own classes. Java and .NET both have tons of libraries that contain a wide assortment of objects. You mentioned C#, so write a few .NET apps. Try to start identifying and understanding the way properties and methods are grouped into objects, and how the different objects relate to each other.

Once you're comfortable using objects, then you can start writing your own classes. A lot of universities try to teach this by having you write common data structures. This approach is worth considering, as it's important to be familiar with data structures, but this isn't the only way to learn object-oriented programming (nor the best, in my opinion). Another commenter recommended writing a video game, which sounds like it's worth a try. Ultimately, the right approach is the one that interests you the most.

Getting good at OOP will take some practice, but it is possible. Objects are like functions: they should do one thing well. Enforce separation of concerns. Learn the design patterns. Practice makes perfect(-ish).

Recommended Reading:

• Refactoring: Improving the Design of Existing Code
  
• Head First Design Patterns
  
• Design Patterns: Elements of Reusable Object-Oriented Software
  

> I am a relatively new to development

If you're new to development, it's hard enough just to learn Rails by itself. In addition to the Rails concepts (e.g. ActiveRecord, view rendering, etc.) there's Ruby, databases/SQL, servers, HTML, CSS and JavaScript. Even if you're already comfortable with all those things, it's pretty hard to throw testing into the mix. When I first got started my question was, "What do I even test?" Do I write unit tests? Integration tests? View tests? Controller tests?

My advice would be to forget about Rails for a little bit and just practice testing Ruby by itself for a while. Then, once you're comfortable with testing Ruby, it will be easier for you to go back and try to write some tests in Rails.

> What is your recommendation on if I should focus on rspec vs minitest?

A person could make technical arguments for either. Deciding which testing framework to use depends on your objectives. If you're teaching yourself testing to become a more marketable developer, then I would definitely recommend RSpec. Almost every Rails project I've worked on (20+ production projects) has used RSpec. Having said that, it's less important which tool you choose and more important that you have a solid understanding of testing principles. I personally chose RSpec and I'm glad I did.

Here are some testing resources I often come across:

Growing Object-Oriented Software, Guided by Tests (awesome book, highly recommended)

Rails 4 Test Prescriptions (just started it, seems good so far)

Working Effectively with Legacy Code (super good book and more relevant to testing than it might seem like)

Everyday Rails Testing with RSpec (haven't bought it yet but seen it recommended a lot)

Destroy All Software (just bought it today, seems good so far)

Lastly, I myself created what I call a Ruby Testing Micro-Course designed to make it easy for people like you to get started with testing. Feel free to check that out and let me know what you think.

For HTML/CSS/JavaScript/jQuery, Jon Duckett's books are pretty good. I linked the set because individually they're about $23, and together it's $28. His is the only JavaScript book in my library. I found his books to be well-ordered, and he describes things in really simple ways, though the book layout feels like reading House of Leaves until you get used to it. Both books have made for great references, though free HTML/CSS tutorials are quite abundant, and I leaned on Google more than the book for learning those.

I can't recommend the Django book that I started with, "Mastering Django: Core" by Nigel George, as much of the advanced topics were no better explained than the official documentation. If you're using Django 2.0, forget it. This, and other Django books I've looked at, don't go into any front-end details, seemingly from a belief that "writing Python code and designing HTML are two different disciplines" (quoted straight from the book I linked). The official docs and web tutorials have served me better for bringing Django to the browser.

Aside from d3.js, I'm only using basic JS and jQuery. d3.js was a very specific use-case for the data I'm working with, as it excels at making graphs and charts using SVG. If that sounds like something you're doing, Interactive Data Visualization for the Web was pretty clear for d3.js. Note that d3.js only uses a minimal amount of traditional JavaScript, so do consider your project needs before dropping $40 on it.

The basics of JS and jQuery will go a long way, even without react/angular/vue.js. Just like my first statement about HTML/CSS, I'd say learn the other frameworks when you can no longer do what you want with JS/jQuery, or when a framework is going to save you time.

Sorry for the wall of text - hope that helps!

woah! brave young man right here!

how to be developer 101

oke

1. listen to your gut and trust it (it knows what it is saying and why)
   1.5 find a goal, set schedule and stick to it.
   
2. stay healthy. eat regularly, sleep from 10-6, exercise 30min/day (walking is good), drink water
   
3. this could be the best thing that happened to you. there is a reason for everything
   
4. https://www.freecodecamp.com/
   if you devote a year to this. you will be ready for a job and since you know stuff already it is going to take even less!!
   
5. discipline!!!!!!!!!!!!!!!!!!! do it everyday think about how you can improve, find out about something new, implement new ideas, your calling is to be PROFESSIONAL webdeveloper ACT LIKE ONE.
   
   
6. mindset - http://norvig.com/21-days.html
   
7. fit more easily in a team - https://www.amazon.com/Clean-Code-Handbook-Software-Craftsmanship/dp/0132350882
   
8. BUILD BUILD BUILD BUILD BUILD BUILD. you learn by doing not by thinking or reading. put everything on github YOU ARE PROUD OF
   
   after you complete FCC
   http://www.firsttimersonly.com/
   
   or if you are hungry look here
   https://skillcrush.com/2015/07/14/job-sites-to-find-your-first-developer-job/
   
   write me in a year
   

Sure!

​

I think two classic books to start with is

1. Design of Everyday Things (https://www.amazon.com/Design-Everyday-Things-Revised-Expanded-ebook/dp/B00E257T6C/) and
   
2. Don't Make Me Think (https://www.amazon.com/Dont-Make-Think-Revisited-Usability-ebook/dp/B00HJUBRPG).
   
   ​
   
   Then I would move onto IDEO's Creative Confidence (https://www.amazon.com/Creative-Confidence-Unleashing-Potential-Within-ebook/dp/B00CGI3DWQ), which documents tons of different UX methods. Also, I haven't read it, but I've heard that Lean UX is a great book (https://www.amazon.com/Lean-UX-Designing-Great-Products-ebook/dp/B01LYGQ6CH).
   
   ​
   
   Oh and to learn HTML, CSS, and JS (if you don't know them already), these are AMAZING reads: https://www.amazon.com/Web-Design-HTML-JavaScript-jQuery/dp/1118907442/ref=sr_1_3?crid=1QXNLBZ2V6GL8&keywords=learn+html+css+javascript&qid=1558328362&s=gateway&sprefix=learn+html+css+ja%2Caps%2C-1&sr=8-3
   
   ​
   
   With that said, I know books are a big commitment so here's a random assortment of UX articles I've bookmarked over the years to get you started (some may be a little old but should still hold up from a process standpoint):
   
   
3. https://uxplanet.org/user-experience-design-process-d91df1a45916
   
4. https://uxplanet.org/ux-is-process-actionable-user-insight-9c17107887bd
   
5. https://uxplanet.org/ux-is-process-designing-from-a-creative-brief-62f8588cb6f2
   
6. https://www.interaction-design.org/literature/article/task-analysis-a-ux-designer-s-best-friend
   
7. https://uxmastery.com/how-to-write-screeners-for-better-ux-research-results/
   
8. https://library.gv.com/get-better-data-from-user-studies-16-interviewing-tips-328d305c3e37?gi=82762a521a6
   
9. https://www.nngroup.com/articles/diary-studies/
   
10. https://uxdesign.cc/6-storytelling-principles-to-improve-your-ux-737f0fc34261
    
11. https://www.usertesting.com/blog/storytelling-in-ux/
    
12. https://www.nngroup.com/articles/interviewing-users/
    
13. https://medium.com/user-research/never-ask-what-they-want-3-better-questions-to-ask-in-user-interviews-aeddd2a2101e
    
14. https://www.smashingmagazine.com/2010/01/better-user-experience-using-storytelling-part-one/
    
15. https://www.bitovi.com/blog/10-best-practices-usability-testing-within-agile-teams
    
16. https://www.nngroup.com/articles/microsoft-desirability-toolkit/
    
17. https://www.nngroup.com/articles/desirability-reaction-words/
    
18. https://lean-product-design.18f.gov/3-identify-assumptions/
    
19. https://lean-product-design.18f.gov/index.html
    
20. https://www.justinmind.com/blog/interaction-design-frameworks-do-you-need-one/
    
21. https://medium.com/ruxers/building-block-design-a-modular-design-strategy-for-uxers-927f63eec90c
    
    ​
    
    There's a lot more where that came from, so let me know if you get through that and are craving more material.
    
    ​
    
    Here are a couple videos as well:
    
    
22. https://vimeo.com/7099570?utm_source=gdev-yt&utm_medium=video&utm_term=&utm_content=conductingresearch&utm_campaign=firstthingsfirst
    
23. This is a youtuber I follow who can teach you everything you need to know to get started in the design space (though she heavily focuses on digital design): https://www.youtube.com/user/charlimarieTV
    
    ​
    
    Finally, here's a very very short article I wrote myself that provides a quick intro into human centered design: http://www.jdktech.com/human-centered-design/
    
    ​
    
    As you dive into this, note that user interface design and user experience design are different things--although they overlap and rely on each other in various ways. You can be a user interface designer (in which case I would recommend different reads), a user experience designer, or both. I'm a full stack designer, which means I specialize in all sides of the product life cycle, including research, validation, design, product management and development.
    
    ​
    
    Hope this helps! Let me know if you have any other questions!

If you're mainly interested in Java, I would recommend Effective Java by Joshua Bloch. It's a great guide with recommendations for best practices in the language.

For C, the best book is The C Programming Language by Kernighan and Ritchie. I would recommend that you read that before ever looking at C++ because C++ is based on C. In fact, it's such a great book that I would recommend reading it before you read anything else on any language. You can skip the file system and Unix stuff though.

For C++, I have never found a good beginner book, so my suggestion would be that after you read the above C book, read the stuff in this tutorial and then read Effective C++ by Scott Meyers. It's another best practices book.

For Python, I've heard good things about Learning Python but I don't really know. I actually found it more useful to just go through the Python tutorial and then start making fun little scripts.

Hope that helps!

The practice of TDD works best for compiled langauges. But even for compiled languages, the experts on the topic disagree on whether test-first is necessary, or if test-later is ok. I've found that test-later works best for me, just make sure you're writing unit tests before you're testing your code through the UI. Generally I build small classes (150 - 250 lines each), then write all the unit tests for the class after I wrote all the code for the class.

You shouldn't write tests for every function. Your tests should exercise every line of code, and every business rule, but the interface that your tests use against your classes should be the same interface that the rest of your code uses against your classes. Writing tests for every function means that you would need to re-write the tests whenever you refactor, which will cause you to move slower.

I would suggest reading this blog post

It shouldn't be difficult to write unit tests against your code. If you are finding it really confusing and difficult, it may be because your function size is too large, or your design is too complicated. Breaking your design into smaller classes, and smaller functions will make it easier to test your code, but ultimately simplifying the design is where most time and effort is saved. You know the design is good when it's very clear how to easily test it. I've found this book to be a good resource in general.

If you're trying to add tests to existing code which has 0 tests, and wasn't designed for tests, I would expect that to take a long time. There's no way around that. Often I find it better to refactor that code, because it's not usually designed well either.

You save time writing unit tests, because it means that you can spend less time testing through the UI. You can test all your business rules using unit tests. When you test through the UI, you're only checking that everything is connected together properly.

The company I work for is similar to the one you described. When I started here, I went against the grain and built things slowly and carefully. My boss recognized the quality of the work I build and now chooses to put me on critical projects, with the expectation that I will spend 2-3x as long as other developers, but also with the expectation that what I build will work well. I've found that this has caused an improvement in quality of life for me, because I'm not in a rush all the time. The reason it takes me longer than other developers is not because of the unit tests though, it's because I refactor code all the time.

Hopefully you can find some helpful answers, guidance, or a starting point in these responses.


From OP:

>The exact four books I read are:

>Learning Obj-C

>Learning Java

>iOS Programming: The Big Nerd Ranch Guide

>Android Programming: The Big Nerd Ranch Guide

>However, I would now recommend learning Swift instead of Obj-C. At the time when I was looking into iOS books, good books on Swift were few and far between.

From u/AlCapwn351 in regards to other sources to learn from:

>www.codeacademy.com is a great site for beginners (and it's free). It's very interactive. W3schools is good for learning stuff like JavaScript and HTML among other things.

>When you get stuck www.stackoverflow.com will be a lifesaver. Other than that, YouTube videos help and so do books. Oh and don't be afraid to google the shit out of anything and everything. I feel like an early programmers job is 90% google 10% coding.

>Edit:

>It's also good to look at other peoples code on GitHub so you can see how things work.

If you associate test-driven development (TDD) with learning better code design, it might help fill in any gaps you feel you have. Best to have an understanding of SOLID principles, DRY, and KISS.

Red Green refactor is a good starting point.
http://www.jamesshore.com/Blog/Red-Green-Refactor.html

Though its not JS specific, anything by Sandi Metz is awesome, highly recommend her 99 Bottles book.
https://www.sandimetz.com/99bottles

Uncle Bob's Clean code is a great resource as well.
https://www.amazon.com/Clean-Code-Handbook-Software-Craftsmanship/dp/0132350882

This is really cool! Thank you.

>A common question is whether the book is still relevant. After all it's over ten years old

I find that some old(ish) books can really hold some great significance, for example: Effective C++ and Clean code have both given me some brilliant tips on making better code. I'm also readingWrite Great Code. If you have any more books i'd love to see them :) Thank you, again.

I'll start by saying if you haven't read Clean Code, then it's a great place to see questions like your answered with examples. It gets a little too in the weeds for some people at the end, but the first several chapters are great for explaining how, why, and when to break things up.

What a lot of it comes down to for me (and there are different opinions on what "clean" code looks like or should look like, it's somewhat stylistic) is readability.

No matter what app you're writing, with a little bit of business/domain knowledge I should be able to look at your code without having seen it before and be able to understand what parts of the code are responsible for what logical operations so that if the requirements have changed or a bug was found I should know right where to go.

I made a small example while nomming some lunch (forgive me for typos or obvious errors lol). The example is a Cash Register app that is responsible for totaling the sale amount given a list of items.

___

Here is the orignal code | Here's the refactored Specifically looking at the CalculateTotalSale methods....

So in a small trivial program it's not as easy to see the benefits, but in the refactored version the total sale logic has been broken up into methods. This way, lets say there's a bug in how we're calculating taxes (in a small app like this they're probably wouldn't be, but in an enterprise POS app that's in an international market tax calculation can be a pain) we've made several ways to track down where taxes are being done. We can look at the usages of _taxes to see where it's being modified, and we can look at CalculateTaxes() method since that's where all the tax logic should be. If we find that tax logic is not there, we should either move there, or consider a small change in design to make it flow easier.

Also we've left the CalculateTotalSale method open for extension as well. Noted by the comments, if the business wanted us to write coupon logic we could put it in it's own method and go from there. We've left a pattern for the next person to follow, they'd be able to get into this code and get to work pretty quickly. Patterns do change though, but since we've followed some fairly fundamental designs of class structure it'd be easy for someone to change the pattern if they needed to. They won't have to look all over the code for pieces of logic if we've grouped it well.

All that being said, the first example still works fine and gets the job done, the discussion above is more of engineering vs programming. Just my two cents though! Sorry if I've made any obvious errors or didn't explain this well!

Hi I think writing small projects will help only to a point. In the end your project may work but will it be readable, easily maintainable, extensible and so on (to anyone but you)....

If you are looking to improve your programming skills and not just php I highly recommend Clean Code http://www.amazon.com/Clean-Code-Handbook-Software-Craftsmanship/dp/0132350882, there is another book as well called the Clean Coder which is also excellent.

Reading other peoples code is also very helpful. Check out the code base for http://laravel.com/, http://kohanaframework.org/ and https://github.com/sebastianbergmann/phpunit/, they are very high quality php code.

I don't really like the term "design your system using interfaces" because it doesn't tell you why. It's a generic idea without any context.

It is better to start with a principle, like Dependency Inversion. Dependency Inversion says you should separate your code from its external dependencies. This is good, because it keeps your code isolated and not dependent on the particular details of things like storage.

Does your application use MySql? Does it use MongoDB? It doesn't matter. In your interface, you can specify query methods for objects from a data store, and a method to save objects to your data store. Then implement the interface specifically for the data store. Your interface could be called FooRepository and the implementation MySqlFooRepository or MongoFooRepository. I dislike interfaces called FooRepositoryImpl. This strongly suggests an interface isn't necessary.

Interfaces are contracts that help you preserve your design and to explain what you need out of external dependencies.

Interfaces are good, but so are classes. Don't overuse interfaces, because indirection isn't always necessary or good. It can make your code impossible to follow and understand.

Start by learning principles like SOLID, which will help you understand where usage of interfaces makes sense. Agile Patterns, Principles and Practices is the best book I've read about this. Another book which does a great job of explaining how to properly use interfaces is Growing Object Oriented Software Guided By Tests.

That sounds pretty normal especially for a small-ish company. A lot of learning comes from reading on your own. Like blog posts, StackOverflow etc. I really recommend Clean Code in terms of the stuff you're talking about. This book is basically a software engineering best practices bible.

Unit testing is something your team should help you with though. If a system is not there, you can also try to do some research and propose a system for your company to use or implement!

> For me, I wish I had more mentoring so I can pick up new skills.

It sounds like you're learning a lot though. You built something that works using a new tech you learned from scratch. That's pretty impressive. It's a pretty unique opportunity to try new things and get paid.

I'm still a young C# developper, around 3 years of C# for websites and APis for small and big companies, but it's not because your predecessors built an in-house framework that this is the right way to build a system. C# is a great language but it shine thanks to the core orientation of productivity delivered by the .NET framework and ASP.MVC.


Of course if your needs are so specifics that you want a custom framework, don't forget that it will become a HR problem. Talented people rarely want to jail themselves to a company and build a specific set of skills that can't be transferred.


But as I said, I'm young. I do think that we are living on the shoulders of giants and that not everything need to be rebuilt. Some of the coolest techs we've seen these past years around containers and micro-services were actually already implemented in the 70's.

That said, I didn't read this book, so I will read it and predictably learn a lot of things. If you didn't already, I would recommend the following books. They aren't C# specific but will help you in the environment you are describing:

• [Working Effectively with Legacy Code] (https://www.amazon.com/gp/product/0131177052/ref=oh_aui_detailpage_o05_s00?ie=UTF8&psc=1)
  A mountain of pattern for common uses cases to improve stability and efficiency of legacy apps.
  
• [The Phoenix Project]
  (https://www.amazon.com/Phoenix-Project-DevOps-Helping-Business/dp/0988262509/ref=sr_1_1?ie=UTF8&qid=1498813798&sr=8-1&keywords=the+phoenix+project)
  An inspiring guide on how to work and migrate from waterfall project toward a more predictable project management methodology.

You need to build up a foundational set of programming skills. Frameworks and libraries are important to know, but not as important as knowing how to program. The difference between a program/website/webapp that works, and a program/website/webapp that works AND has sensible code, is significant to a company. I've seen the simplest of features take weeks to implement in very poorly written code bases. This is valuable and expensive time that could have been spent building other features.

Companies are sensitive to this because very few companies are immune to the effects of poorly written and maintained code bases, so they are going to ask you code design questions and even have you do live programming challenges to see how think about the problem, and whether the design of a solution is important to you, or whether you're content to just shit out any old solution that works and move on.

To start, with, I would familiarize yourself with the basic mechanics of the language by reading the You Don't Know JS series: https://github.com/getify/You-Dont-Know-JS/tree/1st-ed

Next, I would read Clean Code by Robert Martin. It's based in Java, but the general principles are the same.

Next, I would read Refractoring: Improving the Design of Existing Code (2nd edition - which is JavaScript based). You can read the Java-based 1st edition for free.

Finally, I would read A Mostly Adequate Guide to Functional Programming.

Yes, it's a lot of reading, but these books will help you think about your code design choices, and in combination with practice, will help you write better code. But of course there is no substitute for practice. The more you write code, the better you'll be at it. The resources I linked to are just guides, not magic bullets.

In terms of other things that are necessary to learn, you'll need to learn how to use git (not to be confused with GitHub). Git is basically the industry standard version control system. You don't have to be an expert at it, but you do need to know the basics of it.

You're also going to want to get familiar with the basics of node and npm, because even doing front-end work, you'll be relying on 3rd party packages, and running builds, all of which are managed through node and npm (or yarn).

No problem.



1.) Is there any option to avoid Windows cause I didn't really grew on it and Linux is much more familiar to me, I can install powershell as a snap I think but I want avoid Windows as much as possible

​

I'm the opposite: grew up on Windows and I avoid Linux haha.

​

That said, there certainly is the option to simply ignore Windows (there are a lot of Linux only shops out there), however, I would not recommend avoiding it completely.

​

Most IT environments that you will end up in have a mix of Windows and Linux. You will be much more attractive to some employers if you can say that you know Windows basics and are comfortable navigating the platform, rather than saying that you are Linux only.

​

To add, a lot of enterprises run Windows only tools (ActiveDirectory, Team Foundation Server, etc.).

In order to interface with these tools, you'll need to know some Windows basics.

​

At the end of the day, keep in mind that when looking at an enterprise sized network, the operating systems are just one piece of the puzzle. You'll want to be able to step back, visualize the entire network, and not really care what OS is running on the nodes. You'll want to know about the protocols the servers use to communicate (http(s), smb, ftp, etc), how to automate processes regardless of platform, and some basic security concepts.

​

2.) What cloud experience should I pick first, I have small budget of 13 euros for Udemy courses so I can pick only one and I want to do it wisely

​

Go with AWS 100%. They are the most popular at the moment and a lot (if not most) of what you learn will transfer to the other providers.

​

Try to study for the AWS Solutions Architect certification.

​

The practice exams here ( https://www.whizlabs.com/cloud-certification-training-courses/ ) are invaluable since they will explain why certain answers are correct/incorrect.

​

3.) Would learning Apache, PostgreDB/mySQL be worth ?

​

At the end of the day, Apache is basically a web server and the other are databases.

​

For a DevOps role, perhaps look into automating the database component of an application deployment.

​

4.) Which should I pick first to learn about concept

​

Look into CI\CD pipelines. CI = Continuous Integration and CD = Continuous Deployment.

Basically, these pipelines deploy an application to web servers when developers check in their code.

One has to build them using different tools. Have a read here ( https://semaphoreci.com/blog/cicd-pipeline ).

If that interests you, this is basically the Bible on CI\CD ( https://www.amazon.com/Continuous-Delivery-Deployment-Automation-Addison-Wesley/dp/0321601912 ).

​

Any more questions feel free to ask.

Sure, though I've also read people in your position are better at building apps with JS if they're new to it because things like PHP are completely different in how you start growing an app (classical vs prototypal inheritance) not to mention that if you also do PHP instead of just straight JS you're getting used to and learning 2 languages that are completely different in how you code. In either case you're right you have to learn JS anyway, here are the best resources after codeacademy basics stuff:

JavaScript: The Definitive Guide: Activate Your Web Pages (Definitive Guides):

http://www.amazon.com/JavaScript-Definitive-Guide-Activate-Guides/dp/0596805527/

JavaScript: The Good Parts:

http://www.amazon.com/JavaScript-Good-Parts-Douglas-Crockford/dp/0596517742/

Programming JavaScript Applications: Robust Web Architecture with Node, HTML5, and Modern JS Libraries:

http://www.amazon.com/Programming-JavaScript-Applications-Architecture-Libraries/dp/1491950293/

A cool talk from last year of the Fluent conference (and the author of that last book) explaining how different something like PHP and JavaScript are and why JS doesn't deserve the bad rap it used to get (He's a pretty cool guy from Adobe and I got to talk to him last week about all of these things we're talking about right now and where web development is heading, and why JS as a single language for the web can work even better):

http://www.youtube.com/watch?v=lKCCZTUx0sI

This was a really cool overview on JS today, and you get to see Unreal Tournament and the Unreal 4 engine run in a web browser:

http://www.youtube.com/watch?v=aZqhRICne_M

Hello and welcome to the club! To answer some of your questions:

Books. The aforementioned The Phoenix Project and The DevOps Handbook are both great resources that will help you understand what devops aims to do. The handbook has a lot of great "what am i doing (and why am i doing it)" explanations and practical implementation advice. I would add Continuous Delivery to the list as well. Because it lacks the Goldratt-inspired language of The DevOps Handbook it's a little more to-the-point regarding "what am i doing (and why am i doing it)" imo and easier to read and understand in one pass if you're looking to dive in quickly.

We don't know what what your company produces or the exact scope of resources you manage, but AWS is a big, robust ecosystem, and it's a great place to get started with devops. Don't be too worried about limiting yourself. After all, AWS is the biggest cloud platform provider in the world right now; it's a really big pigeonhole to land in. Any patterns you apply to AWS can very likely be translated to other cloud providers.

> Lastly, what are your thoughts on devops vs software engineering?

Software engineering is the "dev" in "devops". Unfortunately a lot of companies hire "devops engineers", but really they expect very little "dev" and a lot of "ops". Developing apps and infrastructure together is great way to optimize your stack and deployments. It's the quintessential devops move. Take advantage!

I cannot recommend Clean Code by Uncle Bob nearly enough. I learned about him from his (rather idiosyncratic) videos on the subject, and it literally changed my outlook on writing software, top to bottom.

This might seem hyperbolic, but I can't stress the value of his ideas enough - my old company had access to his videos on our internal network, and the first 5-7 videos became required watching for the entire team I worked on. It was a lot of time to devote to something that wasn't coding, but I really believe it helped even new graduates understand the ideas behind "good code" and how to make clean systems in practice.

Let me know if you have any questions about the what or why of the suggestion.

Edit: In the spirit of PM_ME_UR_PIN_NO, I would also emphasize that there is no royal road to writing perfect code, because there isn't even consensus on what perfect code is. This kind of thing is the part of what we do that is more art than science, but I have yet to see a more effective collection of useful tactics than Uncle Bob's work.

You need to understand there are a couple of ways to do Java web development.

• Servlets & JSPs. - Check out Core Servlets and JavaServer Pages or the Java EE Tutorial. Note that I link to an older EE tutorial because the newer versions try to switch to JSF and not much changed in Servlets and JSPs between Java EE 5 and 6. I recommend learning Servlets and JSPs before anything else.
  
• JSF - A frameworks that is layered on top of Servlets and JSPs. Works well for some tasks like making highly form centric business web apps. Most of the JSF 2 books are okay. JSF is covered in the Java EE 6 Tutorial
  
• Spring - Spring is actually a bunch of things. You'd want to learn Spring MVC. If you learn any server-side Java web tech besides Servlets and JSPs you'd probably want to learn Spring MVC. I wouldn't bother with GWT or any other server-side Java web tech.
  
• JAX-RS - After you get Servlets and JSPs down, this is the most essential thing for you to learn. More and more you don't use server-side Java (Servlets & JSPs) to generate your clients HTML and instead you use client-side JavaScript to make AJAX calls to a Java backend via HTTP/JSON. You'll probably spend more time with JavaScript:The Good Parts and JavaScript: The Definitive Guide than anything else. Also the JAX-RS api isn't that hard but designing a good RESTful api can be so be on the lookout for language agnostic REST books.
  
  Definitely learn Hibernate. You can start with the JPA material in the Java EE tutorial.
  
  As for design patterns, Design Patterns: Elements of Reusable Object-Oriented Software is a classic. I also like Patterns of Enterprise Application Architecture for more of an enterprise system pattern view of things. Probably avoid most J2EE pattern books. Most of the Java EE patterns come about because of deficiencies of the J2EE/JavaEE platform. As each new version of Java EE comes out you see that the patterns that have arisen become part for the platform. For example you don't create a lot of database DAOs because JPA/Hibernate handles your database integration layer. You also don't write a lot of service locators now because of CDI. So books like CoreJ2EE Patterns can interesting but if you are learning a modern Java web stack you'll be amazed at how archaic things used to be if you look at old J2EE pattern books.
  
  p.s. Don't buy anything that says J2EE, it'll be seven years out of date.
  

If I could make a recommendation based on time-tested experience, I'd recommend following the advice of 2 books, Refactoring: Improving The Design Of Existing Code and Growing Object-Oriented Software, Guided By Tests.

Basically, if you are committed to this codebase, you can rewrite bits and pieces of it (while covering them with tests to make sure you didn't break any functionality) and slowly migrate/transform the code to a point where it's more maintainable.

Of course, if you have a manager who you can't convince this is worth spending time on, you might point them to a resource like this about technical debt or perhaps this one to bring it down to dollars and cents (which every manager understands).

I'd also recommend reading this great piece by John Carmack (of id's DOOM fame, and now VR... He's a highly respected OO C programmer, I'm sure you've probably heard of him) about his excursion into 1 month of programming using a "functional style" (it's applicable to any language, actually, including PHP). It has great quotes like this one: "No matter what language you work in, programming in a functional style provides benefits. You should do it whenever it is convenient, and you should think hard about the decision when it isn't convenient."

I promise you that if you can follow some or all of the knowledge I've linked you to, your job will become both less frustrating and more enjoyable (down the line).

Feature tests! If you use artisan make:test without the --unit option, it creates a "feature" test instead of a unit test. The docs call these HTTP tests.

Using feature tests you can go "outside in", meaning you can test the outer layers first (acceptance/functional/integration tests), and use those to drive your code and eventually your unit tests. This is also sometimes known as "top down" because the test pyramid has the slower (integration, acceptance, functional) tests at the top, and the faster (unit tests) at the bottom.

Adam does a good job explaining the concept in his Test Driven Laravel course (not linking it because /u/ftiersch already did and they deserve credit!). If you'd like a book rather than a video course, I recommend Growing Object Oriented Software Guided by Tests.

Adam's course is worth far more than he's charging, though, and not only do you learn about testing, but he also refactors in the course and shows a ton of Laravel tools you likely didn't know about.

If for whatever reason you don't want that book or the course, there are some people (myself included) willing to do paid coaching sessions, but really, if you're a pretty seasoned dev, you should be able to read the HTTP test docs I linked earlier and good a pretty good start. Laravel makes testing so easy.

Personally I wouldn't mind if == never did implicit casting and acted like === (in fact I wish it did), but the rules don't seem that bad to me.

The example I gave was very contrived, and solution was naive, the best way to compare two arrays to each other would be to loop through them, like this. What I was doing was showing you how you'd take advantage of the implicit casting.

I think it was in John Resigs book where I read the best advice I have seen for JavaScript and it went something like "Treat everything as if it was an object and use === unless you need to use ==".

Also never use the wrapper objects if you can help it. Let the interpreter use them in auto-boxing and leave them alone. Because you are 100% right, things can get a bit weird then.

13 year old? I've started programming around the same age. Wow, I'm only 27 and I suddenly felt old :)

Anyway, I don't know if you want some tips, but here are a few I wish someone told me when I was starting:

1. Start small - even a simple game, like Tetris or something, 100% complete (with UI, menu, sounds, gfx etc.), will take a lot more time than anticipated.
   
2. Finish things - it's not always fun and games, there is a lot of boring work involved, you have to stick it out. After all is said and done, a one finished game will feel better than 10 started projects, no matter how interesting they are.
   
3. Learn about code design. Code readability is really important. I would say it's only second to making working code. After the initial stage of any project, you won't be writing new stuff, you will be expanding already existing codebase. How fast you write/modify/debug/etc., will depend on how readable and manageable is your codebase. The worse codebase, the more you will be inclined to leave it and start something new, fresh (with a "better code"...). Leaving code behind or rewriting it because it's "bad" is a huge timewaster. Read Clean Code and Code Complete for starters.
   
4. I lost a lot code too in my time. Use something like bitbucket or github for your code. Remember to keep your directory tree nice and tidy. As with point 3. - It's a lot easier to come back to nice and tidy project than to some kind of tangled monstrosity.
   
5. Have fun. Creating software/games is a hell of a ride.