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.

> It’s hard to consolidate databases theory without writing a good amount of code. CS 186 students add features to Spark, which is a reasonable project, but we suggest just writing a simple relational database management system from scratch. It will not be feature rich, of course, but even writing the most rudimentary version of every aspect of a typical RDBMS will be illuminating.
>
> Finally, data modeling is a neglected and poorly taught aspect of working with databases. Our suggested book on the topic is Data and Reality: A Timeless Perspective on Perceiving and Managing Information in Our Imprecise World.
>
>
>
>
>
> ### Languages and Compilers
>
> Most programmers learn languages, whereas most computer scientists learn about languages. This gives the computer scientist a distinct advantage over the programmer, even in the domain of programming! Their knowledge generalizes; they are able to understand the operation of a new language more deeply and quickly than those who have merely learnt specific languages.
>
> The canonical introductory text is Compilers: Principles, Techniques & Tools, commonly called “the Dragon Book”. Unfortunately, it’s not designed for self-study, but rather for instructors to pick out 1-2 semesters worth of topics for their courses. It’s almost essential then, that you cherrypick the topics, ideally with the help of a mentor.
>
> If you choose to use the Dragon Book for self-study, we recommend following a video lecture series for structure, then dipping into the Dragon Book as needed for more depth. Our recommended online course is Alex Aiken’s, available from Stanford’s MOOC platform Lagunita.
>
> As a potential alternative to the Dragon Book we suggest Language Implementation Patterns by Terence Parr. It is written more directly for the practicing software engineer who intends to work on small language projects like DSLs, which may make it more practical for your purposes. Of course, it sacrifices some valuable theory to do so.
>
> For project work, we suggest writing a compiler either for a simple teaching language like COOL, or for a subset of a language that interests you. Those who find such a project daunting could start with Make a Lisp, which steps you through the project.
>
>
>
> [Compilers: Principles, Techniques & Tools](https://teachyourselfcs.com//dragon.jpg) [Language Implementation Patterns](https://teachyourselfcs.com//parr.jpg)> Don’t be a boilerplate programmer. Instead, build tools for users and other programmers. Take historical note of textile and steel industries: do you want to build machines and tools, or do you want to operate those machines?
>
> — Ras Bodik at the start of his compilers course
>
>
>
>
>
> ### Distributed Systems
>
> As computers have increased in number, they have also spread. Whereas businesses would previously purchase larger and larger mainframes, it’s typical now for even very small applications to run across multiple machines. Distributed systems is the study of how to reason about the tradeoffs involved in doing so, an increasingly important skill.
>
> Our suggested textbook for self-study is Maarten van Steen and Andrew Tanenbaum’s Distributed Systems, 3rd Edition. It’s a great improvement over the previous edition, and is available for free online thanks to the generosity of its authors. Given that the distributed systems is a rapidly changing field, no textbook will serve as a trail guide, but Maarten van Steen’s is the best overview we’ve seen of well-established foundations.
>
> A good course for which some videos are online is MIT’s 6.824 (a graduate course), but unfortunately the audio quality in the recordings is poor, and it’s not clear if the recordings were authorized.
>
> No matter the choice of textbook or other secondary resources, study of distributed systems absolutely mandates reading papers. A good list is here, and we would highly encourage attending your local Papers We Love chapter.
>
>
>
> [Distributed Systems 3rd edition](https://teachyourselfcs.com//distsys.png)
>
>
>
> ## Frequently asked questions
>
> #### What about AI/graphics/pet-topic-X?
>
> We’ve tried to limit our list to computer science topics that we feel every practicing software engineer should know, irrespective of specialty or industry. With this foundation, you’ll be in a much better position to pick up textbooks or papers and learn the core concepts without much guidance. Here are our suggested starting points for a couple of common “electives”:
>
> - For artificial intelligence: do Berkeley’s intro to AI course by watching the videos and completing the excellent Pacman projects. As a textbook, use Russell and Norvig’s Artificial Intelligence: A Modern Approach.
> - For machine learning: do Andrew Ng’s Coursera course. Be patient, and make sure you understand the fundamentals before racing off to shiny new topics like deep learning.
> - For computer graphics: work through Berkeley’s CS 184 material, and use Computer Graphics: Principles and Practice as a textbook.
>
> #### How strict is the suggested sequencing?
>
> Realistically, all of these subjects have a significant amount of overlap, and refer to one another cyclically. Take for instance the relationship between discrete math and algorithms: learning math first would help you analyze and understand your algorithms in greater depth, but learning algorithms first would provide greater motivation and context for discrete math. Ideally, you’d revisit both of these topics many times throughout your career.
>
> As such, our suggested sequencing is mostly there to help you just get started… if you have a compelling reason to prefer a different sequence, then go for it. The most significant “pre-requisites” in our opinion are: computer architecture before operating systems or databases, and networking and operating systems before distributed systems.
>
> #### Who is the target audience for this guide?
>
> We have in mind that you are a self-taught software engineer, bootcamp grad or precocious high school student, or a college student looking to supplement your formal education with some self-study. The question of when to embark upon this journey is an entirely personal one, but most people tend to benefit from having some professional experience before diving too deep into CS theory. For instance, we notice that students love learning about database systems if they have already worked with databases professionally, or about computer networking if they’ve worked on a web project or two.
>
> #### How does this compare to Open Source Society or freeCodeCamp curricula?
>
> The OSS guide has too many subjects, suggests inferior resources for many of them, and provides no rationale or guidance around why or what aspects of particular courses are valuable. We strove to limit our list of courses to those which you really should know as a software engineer, irrespective of your specialty, and to help you understand why each course is included.
>
> freeCodeCamp is focused mostly on programming, not computer science. For why you might want to learn computer science, see above.
>
> #### What about language X?
>
> Learning a particular programming language is on a totally different plane to learning about an area of computer science — learning a language is much easier and much less valuable. If you already know a couple of languages, we strongly suggest simply following our guide and fitting language acquisition in the gaps, or leaving it for afterwards. If you’ve learned programming well (such as through Structure and Interpretation of Computer Programs), and especially if you have learned compilers, it should take you little more than a weekend to learn the essentials of a new language.
>
> #### What about trendy technology X?
>

> (continues in next comment)

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.

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!
  

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.

Lots of great suggestions here. My grad program used SPSS but it annoyed me that someone had to pay for it, so I learned R. Like others mention, if you learn R it can be easier to go back to SPSS. Also, others who use SPSS might think you have some kind of superpower.

Like u/bobbyfiend says, the best is to do use it on some projects. This forces you to learn something that is important and you have interest in solving. The internet is amazing, and most answers in some form or another can be found on Stack Overflow (make sure to ask the questions in the proper format and search first), /r/rstats (a bit more friendly than stack overflow), or on some of the email lists.

In general, I would say there are a couple of resources that most people could benefit from as they start to learn:

-Andy Field's Discovering Statistics with R - It does have some irreverent humor, but is a good read

-Hadley Wickham's R for Data Science - this resource is free online but can also be bought through Amazon. Hadley is a R celebrity responsible for creating the 'tidyverse' series of packages - packages which make R more beginner friendly imo.

You will definitely want to look at your subspecialty and see if there are any people working in R there. They may have some other resources. Again, you can read books and watch courses all you want, but it is critical to practice (and practice using something you are interested in can help exceptionally). Ultimately, I used my dissertation as an excuse to dive into R - there was pain, and I probably could have done it quicker if I stayed in SPSS - but I learned a lot and now use R and Rmarkdown - and really do not think I plan on going back. Another user mentions looking at others' code, and this has also helped me to make my code more efficient and reproducible - a big strength of R (love that you can use Git).

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.

Heh, sure.

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

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

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

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

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

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

Good luck!

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

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

Ok rant over.

Some tips/advice:

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

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

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

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

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

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

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

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

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

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

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

assert pollinate(some_bee, flower);
}

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

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!

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/

>How valuable is an Oracle cert?

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

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

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

Sorry - mostly UK (amazon) links :)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Coding

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

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

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

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

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

Work Methodologys

Kanban

Succeeding with Agile


p.s

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

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

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

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

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

from flask import Flask

app = Flask(name)

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

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

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

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

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

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

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

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.

> 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'm from a social science background and, like you, I often find myself hopelessly lost when it comes to what feels like very basic concepts in statistics. I think that's partly due to how statistics is taught in all non-mathematics disciplines - in theory we're taught how to use and evaluate quite complex statistical procedures, but with only 1-2 hours per week teaching, it's impossible for our lecturers to cover the fundamental building blocks that help us to understand what's actually going on.

Because of this, I've recently started a few MOOCs on Coursera, and I've found these massively helpful for covering research methods and statistics in far more depth than my undergraduate and postgraduate lecturers ever had time to delve into. In particular, a couple of courses I'd recommend are:

• Methods and Statistics in Social Sciences - This is particularly focused on quantitative methods in the social sciences (including quite a bit on behavioural and self-report research) so I'm not sure if it will be directly relevant with respect to neuroimaging and cognitive neuroscience, but this gives a great introduction to research methods in general. I've actually only done the first course in this series (Quantitative Research Methods), but they're very comprehensive and well made, so I'm confident that the whole series will be useful for any researcher.
  
• Probability and statistics: To p or not to p? - This one is a little bit more maths-heavy so might be a bit intimidating if you don't find that sort of material easy, but it's a good introduction to some of the core concepts in quantitative research, including some you mentioned (e.g. probability distributions). You don't really have to fully engage with or grasp the maths for it to be useful either.
  
  In terms of textbooks, I personally use Andy Field's Discovering Statistics Using R, and find that very helpful. Field is a psychologist who is very open about his difficulties with learning statistics, and I've found it quite useful and re-assuring to learn from someone with that mindset. He's also tried writing a statistics textbook in the form of a graphic novel, An Adventure in Statistics: The Reality Enigma, so if that sounds like something that might help you, check it out.
  
  I think a few people from a 'purer' statistics background are a bit more critical about Field's books because they're not as comprehensive as a book written by, for example, a statistics professor - and there might be some advice in there that's a little bit out-of-date or not quite correct. He also has a very hit-and-miss cheesy sense of humour, which you'll either love or find very annoying. But I think he takes the right sort of approach for helping people who aren't necessarily mathematically-inclined to dip their toes into the world of statistics.

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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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.

For some definitions:

REST

For a beginner like yourself, you can think of REST as meaning "pretty urls". It means much more than this, in the sense that RESTful urls encodes application state and interactions into the URL, but for your purposes, it is helpful to simplify REST down to "pretty urls". Reddit uses RESTful urls:

• https://www.reddit.com/r/learnprogramming/comments/4l0qch/super_confused_on_how_to_start_learning_web/
  
  The non-RESTful (RESTless?) url would look something like:
  
  
• https://www.reddit.com/comments.html?subreddit=learnprogramming&threadId=4l0qch&title=super+confused+on+how+to+start+learning+web
  
  MVC
  
  MVC means "model-view-controller", which refers to a specific way in which your application is organized in order to separate your domain layer (model), presentation layer (view), and business logic layer (controller). For a concrete example:
  
  Model: represents the data elements that you want to show to the user. A model is most often just a vanilla class with get/set properties. Let's imagine I'm building a blog from scratch and I want to show the user a page containing my post: my model logically includes my post (content, date, authors), comments (content, date, authors), etc. My model might look something like this:
  
  public class BlogPostModel
  {
  public Author[] Authors { get; set; }
  public DateTime CreatedOn { get; set; }
  public string Title { get; set; }
  public string Body { get; set; }
  public string[] Tags { get; set; }
  public Comment[] Comments { get; set; }
  }
  
  View: a view transforms the model into something your users can see and understand. In web development, a "view" is nearly always the HTML:
  
  <html>
  <head><title>@(Model.Title)</title></head>
  <body>
  <h1>@(Model.Title)</title>
  <div>By @(Model.Authors) on @(Model.CreatedOn.ToString("YYYY-mm-dd"))
  <div>
  @foreach(var tag in Model.Tags)
  {
  <a href="blog/tags/@(tag)">@(tag)</a>
  }
  </div>
  <div>@Model.Content</title>
  <h2>Comments</h2>
  @foreach(var comment in Model.Comments)
  {
  <div>. . .</div>
  }
  </body>
  </html>
  
  Controller: a controller contains your business logic. Typically, this includes logging users in, reading/writing to the database, validating user input on the server side. In ASP.NET MVC, your controller is a class which inherits from System.Web.Mvc.Controller. The controller class can exposes "actions", which are simply methods that return a type of ActionResult. ASP.NET will expose each "action" through a RESTful url called a "route". A simple controller looks like this:
  
  public class BlogController : Controller
  {
  // url: ~/blog/Article/{articleId}
  public ActionResult Article(int articleId)
  {
  // ...
  }
  
  // url: ~/blog/AddComment/{articleId}
  public ActionResult AddComment(int articleId, CommentModel model)
  {
  // ...
  }
  }
  
  ASP.NET
  
  ASP.NET is a set of classes and libraries built on top of the .NET Framework which helps you build web application. ASP.NET comes in two flavors:
  
  
• ASP.NET WebForms. You can simply ignore this. No one uses WebForms anymore.
  
• ASP.NET MVC. Learn this. This is a framework which makes it easy to write RESTful applications in the traditional model-view-controller fashion.
  
  WebAPI
  
  WebAPI allows you build RESTful web services that do not have a front-end (that is, calling methods on your API does not return any HTML). This can be occasionally useful.
  
  .NET
  
  The .NET framework is a set of libraries developed by Microsoft which helps developers build applications that execute in the Microsoft Common Language Runtime. If use C# on Windows, you already use .NET.
  
  Mono is alternative, open-source implementation of the .NET framework which runs on Linux.
  
  jQuery
  
  jQuery is a Javascript framework which is tailored to selecting and manipulating the DOM on the client side. (The "DOM" refers to the browsers representation of HTML elements on screen; changing an element on the DOM usually has a visible effect to the user in the browser.) It also has some useful utility methods for sending AJAX requests, animating elements on screen, etc.
  
  Although jQuery is omnipresent in web development, it's not a prerequisite for a beginner to learn. You can pick it up over time as you develop your skills.
  
  > I understand HTML, CSS, JavaScript, SQL, C# basics. What is the next step?
  
  Pick up a copy of Pro ASP.NET MVC 5 and start learning.

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.

For more foundational stuff, I'd look at:

• GitFlow - a successful Git branching model - This is pretty much the prototypical Git usage model. I have seen it used pretty much everywhere I've worked that used Git, and a lot of software supports the model by default (Atlassian Stash, SmartGit, Git Tower, and more).
  
  
  • Also take note of alternative Git usage models like GitLab Flow and GitHub Flow. They fit rather different use cases, and GitFlow is typically used for software that follows a more old-school release model where releases happen periodically, or you need to support multiple production releases at any given time. GitLab and GitHub flow are geared more toward software that only sees a single version in production at any given time, and very common release cycles (e.g. daily or even shorter).
    
    Getting familiar with these branching models will also expose you to many commonly-used Git features like branching, squash merging, rebasing, tagging, and history rewriting.
    
    
• How to write a commit message
  
  No one's really gonna ask you about this, but you should develop a habit of writing great, clear, and concise commit messages.
  
  
• Continuous Delivery and Continuous Integration
  
  All the rage right now - having real/near-real time building/unit-testing/packaging/deployment of your software once you've made a code commit. Read the articles I linked, play with services like CircleCI or Travis-CI or CodeShip and integrate them with your projects in GitLab.
  
  
• Test-Driven Development and Behavior-Driven Development
  
  Probably the two most commonly used overarching test-based software development processes. I'm a strong proponent of TDD (when done right), and many teams you work on will probably employ TDD or BDD.
  
  
• Stemming from the last point, know how to write good unit tests and how they differ from integration tests or acceptance tests.
  
  
• Code organization - a lot of this will likely be influenced by the language/toolset you're working in, but you'll be interested in learning about Layered Architecture and software packaging metrics.
  
  
• Generic software design - all sorts of acronyms to read about and absorb, like YAGNI, KISS, DRY, and SOLID. Also, the Unix philosophy, which guided a lot of development of software for Unix and Linux these days. There will also be patterns that apply to specific languages or types of software, but the stuff above is rather generically applicable.
  
  Beyond those links, some books that cover a lot of general material are:
  
  
• Clean Code
  
• Pragmatic Programmer
  
• Mythical Man-Month
  
• Software Estimation - Okay, software estimation is really gonna be complex and difficult until you get a lot of experience, and even experienced developers get it wrong. I don't think it's particularly necessary to read this book when you're starting out.
  
• Domain Driven Design - I love this book - it's about breaking down complex software designs.
  
• Release It! - Nygard is a pretty battle-tested developer, so this book is about approaching software design practically rather than in a vacuum separated from real-world application.

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
   
   
   
   
   
   

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.

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.

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?
  

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.

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.

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.

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.

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.

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

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.

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.

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

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

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!

I've really enjoyed Discovering Statistics using R by Andy Field. The book is written more like prose than a textbook, and is rarely dry. It requires you to learn how to use the R programming language as well, but I think it is very worth it. Everything he teaches, he teaches it at the conceptual level first and then shows you how to perform the tests using R. A great bonus is that R is great for data visualization, and being able to visualize large data sets quickly really helps get a better understanding of the data you are working with, which helps learn the theory.

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.

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.

Now this is an interesting and difficult question, which depends on many things. For starters, if you find this process frustrating that is unfortunate, because learning how to code is usually a trail and error + revise your work process. In other words, its supposed to be both frustrating and rewarding, like a hard (text-based) video game. For me its half of the fun.

What you want to learn really depends on the context. If you are really diving into econ, Stata is still very common. More stats-heavy, new, or interdisciplinary fields tend to use R. If you work with big, live datasets, or work with computer scientists, learning Python is always a plus. But obviously start with one.

I am proficient in stata simply because I had classes in it, it is difficult for me to advice how to self study. I learned most of the basics through An Introduction to Modern Econometrics Using Stata, and later on most of my R through R for Stata Users (Statistics and Computing) . I also learned some R through Discovering Statistics Using R, but I find Field obnoxiously failing to be funny, so I wouldn't reccomend it.

I'm now in the process of learning more Python, to do some more programming work on the side. As a start I used Learn Python 3 the Hard Way recommended to me by a very proficient friend of mine. This however does not give you much of an intro to stats in python, only the very very simple basics you can use as a vantage point for further work.

If you have learned the basics, tbe hest way to learn more is just to fool around. What is your field of interest? I like a lot of macro, so I used to just go to Quandl, pick some free databases, import them, and run some fun stuff. This is the best way to learn, especially if you for example try to merge free World bank databases with a different database from Quandl, as it will give you a lot of errors whilst merging and conversion problems later on.

If you are a bit more proficient you can start using websites like upwork to get some assignments. Usually it doesn't earn you much at the start, but the experience of actual assignments is the best way to self-teach. A different manner I like to do (if you are still studying) is offering your services (for free) to a professor. Ask him/her if there are still projects they are working on for which they need some to look at. Usually you will be treated solely as someone for the code, but it generally gives you a lot of experience and the right contacts.

These are just some of my thoughts. If you could provide some more context of where exactly you want to go, I could go into more detail.

Edit: What I forgot to say is that if it is not possible to study a course, I would recommend doing at least one MOOC to get you at a basic level.

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

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
   

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.

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.

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.

First, make sure that you've built some complex apps in vanilla JS, and have faced some sort of issue of scale (ie. problems that came up because your app has a lot of code). Maybe your code is really long and difficult to organize. Maybe you end up repeating the same code in a lot of places. Etc.

That way when you try a framework, you'll have some idea why it does what it does, and what problem it's trying to solve.

As far as specific libraries, I'd try these in this order:

• Lodash (or equivalently, Underscore). This is a really useful utility library, and can be used regardless of what fremework you're using.
  
• Backbone is the most barebones and vesatile of the popular frameworks, and is meant to be used in conjunction with jQuery (which you already know) and Lodash (which you will have learned). Backbone will give you a good sense for what MVC is.
  
• React is a level of abstraction above Backbone, and offers 2-way binding and component-level separation in addition to MVC (more acurately, MVVM). I'd encourage you to use it with Browserify, which lets you use NodeJS's syntax for injecting code, but in the browser.
  
• Angular is more opinionated than React, and introduces high level concepts like dependency injection.
  
• Optionally, also try out Meteor (which introduces full stack, 4-way binding), Ember (a super opinionated framework, most similar to Angular), and Polymer (a very future-facing framework, most similar to React).
  
  For general education, here are a few books I recommended in another thread:
  
  Design patterns:
  
  
• http://addyosmani.com/resources/essentialjsdesignpatterns/book/#designpatternsjavascript
  
• https://leanpub.com/javascript-allonge/read
  
• https://leanpub.com/javascript-spessore/read
  
  The JavaScript language:
  
  
• http://www.amazon.com/Effective-JavaScript-Specific-Software-Development/dp/0321812182
  
• http://www.amazon.com/JavaScript-Good-Parts-Douglas-Crockford/dp/0596517742
  
  Hope that helps, and good luck!

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.

I think posting material like this with no context is silly, but I upvoted this anyway because I recommend these books often. The Introduction is very short and explains better than I could here why the books were written. The quality of the chapters vary, but they are mostly all worth reading. I'm excited for the upcoming The Performance of Open Source Applications, although I haven't heard any news about its progress in a long while.

One of the editors, Greg Wilson, did some research into how we can be effective programmers. Basically, continuing the research that books like Code Complete were based on. He wrote an excellent book Making Software: What Really Works, and Why We Believe It. He is also involved with the community blog It Will Never Work in Theory, which is tag-lined as software development research that is relevant in practice.

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.
   

> Also, is there a name for a "non-local" function? I didn't know the difference between a local and "non-local" function since this is basically my first time hearing the term.

Uhhh... class... member... method? lol, I'm not sure. Up until C# 7.0 that introduced local functions, they were always just... well, "methods."

Maybe "instance method" and "static method" might be viable.

That MSDN link I included has examples of both regular and local functions.

Regarding code efficiency, don't worry about that. Try to make the code easy to understand, easy to change, and easy to debug first. I'm not sure of any resources off the top of my head that would be good for people learning. There are some books, Clean Code comes to mind. Some of the topics might go over your head a bit depending on how far along you are learning, but with any luck it'll help you perceive coding as a craft rather than just getting the correct output.

Maybe the next important leap you can take is to think about organizing your code into classes. That might help you better manage your code into smaller, single-responsibility parts that are easier to reason about and work with.

I'll chime in since I'm writing a large-scale bot myself.


First of all, nice job so far. You are making good progress. I've checked on your repo occasionally within the last day, and see that you are continually making improvements. Keep it up!

My suggestion pertains to code style/readability.

• Don't abbreviate your variable names if you can avoid it. For example, in your `random.js` file, you have this line:
  
  

  
  r = Math.random();<br />
  ```<br />
  <br />
  On other lines, it would be ambiguous as to what `r` represents. I'd recommend to always use descriptive identifiers, because it makes your code more readable and maintainable.<br />
  <br />
  An easy fix for this would be to rename the variable to `randomNumber`. It only takes a second to type, but greatly reduces the amount of time it takes to understand your code.<br />
  <br />
  Another example is in `move.js` where you have these two lines:<br />
  <br />
  ```js<br />
  h = false; // no text setting<br />
  g = false; // no move<br />
  ```<br />
  <br />
  In theory, code should be &quot;self-documenting&quot;, meaning you shouldn't *need* a comment to describe what a variable is. In this case, you added comments to basically describe the variable.<br />
  <br />
  To resolve this, just change the variable to be the description of the variable, essentially, like:<br />
  <br />
  ```js<br />
  hasTextSetting = false<br />
  hasMove = false<br />
  ```<br />
  <br />
  With a descriptive variable name (identifiers in general), there is no need to add a comment to describe what the variable does, because the identifier should tell you what it does or holds.<br />
  <br />
  <br />
  If you want to gain a lot of good coding habits, I would highly recommend reading [Clean Code](https://www.amazon.com/Clean-Code-Handbook-Software-Craftsmanship/dp/0132350882)<br />
  <br />
  <br />
  Otherwise, it looks good so far. If you have any questions about making a bot or need help, feel free to ask me. Contact me on Discord, Joker#3650<br />

I feel for you OP. I recently inherited a fully functional system already in production that was horribly coded. It is now in very good shape, and with a 92% test coverage. It is possible OP! ;)

Yes definitely create the UML diagrams. When you understand it well enough to create a high-level diagram, you will be much better armed, both for making changes, and for showing outsiders why A and B are important to do, since you have something concrete to go from. I would recommend this UML editor for it.

Next, is the code sufficiently under test?
If not, buy and use the book Working Effectively With Legacy Code by Bob Martin. It helps a lot. First step is getting at least some of it it under test. The book is a big one, but you don't need to read it all to get cracking. It is like a recipe book:

"Let me see, okay, I have eggs, chicken, and a 1000+ lines class calling into an unknown legacy system. Then I should use the coding recipe on page 432, and plenty of garlic. Always use plenty of garlic."

Best of luck OP!

Here's my list of the classics:

General Computing

• But How Do It Know? - The Basic Principles of Computers for Everyone
  
  
• The Elements of Computing Systems: Building a Modern Computer from First Principles
  
  
• Code: The Hidden Language of Computer Hardware and Software
  
  
• Gödel, Escher, Bach: An Eternal Golden Braid
  
  Computer Science
  
  
• The New Turing Omnibus: Sixty-Six Excursions in Computer Science
  
  
• Compilers: Principles, Techniques, and Tools, 2nd Edition (aka The Dragon Book)
  
  
• The Art of Computer Programming
  
  
• Algorithms, 4th Edition
  
  
• Introduction to Algorithms, 3rd Edition (aka CLRS)
  
  
• Essential Algorithms: A Practical Approach to Computer Algorithms Using Python and C#, 2nd Edition
  
  
• Grokking Algorithms: An Illustrated Guide for Programmers and Other Curious People
  
  
• Structure and Interpretation of Computer Programs, 2nd Edition (aka SICP, available for free on the MIT website)
  
  
• Discrete Mathematics with Applications, 4th Edition
  
  Software Development
  
  
• Designing Data-Intensive Applications: The Big Ideas Behind Reliable, Scalable, and Maintainable Systems by Martin Kleppmann
  
  
• Design Patterns: Elements of Reusable Object-Oriented Software (aka The Gang of Four)
  
  
• Think Like a Programmer: An Introduction to Creative Problem Solving
  
  
• The Pragmatic Programmer: your journey to mastery, 20th Anniversary Edition, 2nd Edition
  
  
• The Mythical Man-Month: Essays on Software Engineering
  
  
• Code Complete: A Practical Handbook of Software Construction, 2nd Edition
  
  
• The Design of Everyday Things
  
  
• Clean Code: A Handbook of Agile Software Craftsmanship
  
  
• Programming Pearls, 2nd Edition
  
  
• Soft Skills: The Software Developer's Life Manual
  
  
• Hello, Startup: A Programmer's Guide to Building Products, Technologies, and Teams
  
  
• Hacker's Delight, 2nd Edition
  
  
• Peopleware: Productive Projects and Teams, 3rd Edition
  
  Case Studies
  
  
• The Soul of a New Machine
  
  
• Masters of Doom: How Two Guys Created an Empire and Transformed Pop Culture
  
  
• Hackers: Heroes of the Computer Revolution
  
  
• Where Wizards Stay Up Late: The Origins Of The Internet
  
  
• Fire in the Valley: The Birth and Death of the Personal Computer, 3rd Edition
  
  Employment
  
  
• Cracking the Coding Interview: 189 Programming Questions and Solutions, 6th Edition
  
  
• The Complete Software Developer's Career Guide: How to Learn Programming Languages Quickly, Ace Your Programming Interview, and Land Your Software Developer Dream Job
  
  
• The Self-Taught Programmer: The Definitive Guide to Programming Professionally
  
  
• The Passionate Programmer: Creating a Remarkable Career in Software Development
  
  Language-Specific
  
  C
  
  
• The C Programming Language, 2nd Edition
  
  Python
  
  
• Automate the Boring Stuff with Python: Practical Programming for Total Beginners, 2nd Edition
  
  
• Python Crash Course: A Hands-On, Project-Based Introduction to Programming
  
  
• Python Programming: An Introduction to Computer Science, 3rd Edition
  
  
• Effective Python: 59 Specific Ways to Write Better Python
  
  C#
  
  
• The C# Player's Guide, 3rd Edition
  
  C++
  
  
• The C++ Programming Language, 4th Edition
  
  
• Starting Out with C++: from Control Structures to Objects, 9th Edition
  
  Java
  
  
• Introduction to Java Programming and Data Structures: Comprehensive Version, 11th Edition
  
  
• [Java: A Beginner's Guide](https://www.amazon.com/Java-Beginners-Seventh-Herbert-Schildt/dp/1259589315/, 7th Edition)
  
  
• Java: The Complete Reference, 11th Edition
  
  
• Core Java Volume I - Fundamentals, 11th Edition
  
  
• Starting Out with Java: From Control Structures through Objects, 6th Edition
  
  
• Effective Java, 3rd Edition
  
  Linux Shell Scripts
  
  
• The Linux Command Line: A Complete Introduction, 2nd Edition
  
  
• Wicked Cool Shell Scripts: 101 Scripts for Linux, OS X, and UNIX Systems, 2nd Edition
  
  
• Linux Command Line and Shell Scripting Bible
  
  
• Mastering Linux Shell Scripting
  
  Web Development
  
  
• Learning Web Design: A Beginner's Guide to HTML, CSS, JavaScript, and Web Graphics, 5th Edition
  
  
• Eloquent JavaScript: A Modern Introduction to Programming, 3rd Edition (also available for free on the author's website)
  
  
• JavaScript and JQuery: Interactive Front-End Web Development
  
  
• HTML and CSS: Design and Build Websites
  
  
• You Don't Know JS: Up & Going
  
  Ruby and Rails
  
  
• Ruby on Rails Tutorial: Learn Web Development with Rails, 4th Edition (Note: this book is somewhat out of date compared to the live version on the author's website.)
  
  
• The Well Grounded Rubyist, 3rd Edition
  
  
• Practical Object-Oriented Design in Ruby: An Agile Primer
  
  
• Agile Web Development with Rails 5.1
  
  
• Programming Ruby 1.9 & 2.0: The Pragmatic Programmers' Guide, 4th Edition
  
  
• Eloquent Ruby
  
  Assembly
  
  
• Assembly Language for x86 Processors, 8th Edition

I have been doing a lot of self study in compilers and interpreters recently so please take my advice with that in mind, I can't say about modern but I personally found compiler construction by Kenneth C Louden to be an excellent book, I am going through the book as part of self study. It builds a compiler for a subset of C (in the C language) and from the several books I have on the subject, this is the one which walks the line between theory and code best.

I do have the feeling this one is more of an introduction though and once I am done with it I will need to go over to a more advanced book (dragon book perhaps or Muchnik?). It is very expensive though, I was lucky to get a second hand copy.

Also another interesting book though maybe not as useful directly is language implementation patterns which goes over the topics of DSLs etc. using Java.

This book is also available at pragprog.com without the DRM.

Frameworks like Spring and JPA/Hibernate are used in professional software development, and it is important to know them, but they won't teach you proper ways to architect your software. They are only tools, not substitutes for understanding and judgment.

I would suggest stepping back and learn patterns like Clean Architectures. This will help you understand the principles of software architecture, which is more important than Spring or JPA/Hibernate.

There are plenty of books on this subject. My favorites are Growing Object Oriented Software Guides by Tests, Agile Patterns, Practices and Principles in C# (the book has very little to do with Agile), Clean Code, Clean Architecture, Patterns of Enterprise Application Architecture.

Martin Fowler's website has a lot of good stuff about all architectural topics, from the stuff you're asking about, to microservices and big data.

Uncle Bob has a lot of videos on YouTube that are well worth a watch, like this one. Skip past the first five minutes or so unless you want a physics lesson, too.

First time see that site, but I would recommend reading:

• Clean Code: A Handbook of Agile Software Craftsmanship
  
• The Clean Coder: A Code of Conduct for Professional Programmers
  
• The Pragmatic Programmer: From Journeyman to Master
  
• Code Complete: A Practical Handbook of Software Construction
  
• Refactoring: Improving the Design of Existing Code
  
  This is a list of books I am intending to read as soon as I read through some other books.. A list I created from reading this and some other subreddits daily, so probably this should cover all your need on Clean Coding.
  
  If anyone know any more books well worth reading I would be really glad to hear about them!

I think most is kind of a rough statement. Granted there were some truly gifted people in the 70's that rocked our world.

I think we have a LOT of research papers that we sift through and the legacy papers tend to stay highlighted in time. I can imagine if you sifted through everything that existed back then, you may be saying something similar.

I've found a few great ones and if you are heavy into software engineering, you may share the enthusiasm towards a book that came out several years ago: Greg Wilson - Making Software: What Works and Why we Believe it

He also has a talk where he references some of those papers: Greg Wilson talk

He comes off strong, but he backs it with research which I appreciate. It's more about bringing data to the table if you have something you'd like to discuss. Somewhat heavy handed, but there are good papers that I've read referenced there.

The continual evaluation of Conways law and it's research still holding true today is something that I continually enjoy (Although originating from a 1967 study reinforcing your point of seminal papers from that era)

Generally speaking, "reverse engineering" implies getting an executable (like a .exe file on Windows) and trying to figure out what it does at the level of the source code. Reverse engineering is a long and tedious process that is not as simple as it sounds for several reasons.

The first thing that you have to understand is how a program goes from source code to EXE (since we're going in the opposite direction when we reverse an .exe file). When a program is written in a high level language like C or C++, it can't be run by a computer until it has been compiled, a special process performed by a compiler. Compilers take the source code, and translate it first into a middle language called an intermediate representation that represents the logical structure of the program, and then based on that middle language emit machine code. Machine code (which can be translated into a human readable form called assembly language) is the binary language that the CPU actually uses to do computation - it contains very simple instructions like "move this data to this location in memory" or "add these two numbers together". Most compilers will also make a lot of optimizations in before emitting the machine code - for example, if they see a certain piece of data being accessed and stored unnecessarily, they may move the code responsible for the redundancy to another place in the executable to avoid wasted operations. The compiler will finally output a file called an object file, which contains optimized machine code.

However, this file is generally not executable - it still has to be linked by the linker, (which sometimes automatically runs after the compiler). The linker performs several tasks, like fixing up absolute addressing to ensure that a program can be loaded anywhere in it's address space, as well as providing references to shared libraries. Usually when writing big programs, developers will use already-written code, like the C library or other vendor specific packages, by referencing it in the source code. For example, C source code can use statements like

include <stdio.h>

to indicate that the program includes references to the standard input/output library in the C library, which is used to allow user-provided data and to print data to the screen, among other things. So, it's the linker's job to ensure that these libraries are included in the final executable and that the other object files can reference them correctly. To make matters worse, the linker will build the executable program in whatever file format the operating system uses (PE on Windows, ELF on Linux, and Mach-O on OSX), and these file formats store the program data and code in separate locations. However, the linker handles this cleanly and produces a compiled, optimized, and linked program in the right format, which can then be executed. So that's how it happens normally.

So now, let's do it in reverse. Suppose you have suspicious.exe, a file that you think is malware and you want to find out what it does so that you know whether it's dangerous or not. Suspicious.exe is a compiled and linked executable, and since it was optimized, you don't necessarily have a 1-to-1 correspondence between each machine code instruction and each line of source code (and you don't have the source code anyway). Furthermore, the Intel x86 architecture that most commercial personal computers use in their CPUs uses variable length machine code instructions - some of the instructions will be longer than others, so it is very difficult to look at them in a binary and figure out what is doing what. This is where a disassembler is used - a program that takes a raw binary file and emits human readable assembly language. Because of variable length instructions, some disassemblers even emit the wrong assembly instructions sometimes! However, because the program has to be able to run consistently and reliably when given to the CPU, there is always a way to disassemble it into the correct machine code - it sometimes just takes a few hours (and a headache or two).

Now, you've disassembled the file using a tool like IDA Pro (which can cost hundreds or thousands of dollars, depending on the license), and you have human-readable assembly. So why is it still hard to figure out what the program does? Firstly, any descriptive variable names that a programmer used to make the source code more easy to read are gone because the compiler got rid of them once it generated the intermediate representation - so you don't even know what the various memory references are where data is stored. Secondly, while you can tell where functions begin and end, you can't necessarily tell what they do - they're just blobs of assembly, and sometimes not even that; if the functions were included in a shared library, they'll often be just references to the address in memory where the imported library is placed when the operating system loads the process into its address space (it depends on whether the executable is dynamically or statically linked, but that's a more in depth and tangential discussion). You also don't where important data structures - like strings or pointer tables - are because what the disassembler doesn't recognize as code, it'll just call "data" and leave it at that. Thirdly, most of the data in the program depends on the memory state while it's running, which you can't tell just by looking at the assembly. You need to actually run suspicious.exe.

So you take a look at this mess, ask yourself why you chose this job in the first place instead of being a web developer even though they get paid about the same as you, open another can of Rockstar, and you get to work. Generally, you'll start suspicious.exe in a sandbox environment like a virtual machine using a debugger, which is a special program that will allow you to halt it and examine its memory state, register states, and other activity. As the program executes, you will begin to notice behaviors that resemble C structures - how you actually do this is a huge discussion that people have written entire books about, but suffice it to say for now that it comes with experience. Furthermore, if you use IDA (or keep a notebook), you'll write down lots of notes about the program behavior, and use Microsoft's MSDN pages (or Apple's developer documents or the Linux man pages, depending on what environment your executable runs in). Eventually, whatever it is that you were aiming to find out becomes clear, or you quit out of sheer frustration (but usually and hopefully the former).

Bear in mind that most people don't aim to entirely reverse engineer every bit of machine code in an executable. A lot of it isn't related to what you're trying to discover, and so part of the game is first finding what pieces of code are actually relevant (which you do with a debugger by stopping the program's execution once it starts doing stuff relevant to your reversing purposes), then reversing those little parts of the code.

I think you're going to suffer too much with broad strokes. All of the things you've mentioned have their own usecases really. You should focus on one of them and learn it before deciding whether you want to try another.

Although, you can also just do 'X vs Y' for all of those things you've mentioned and see articles on the differences between them as well as what they actually do.

Before you start any of the learning on any of those things though, you should definitely take one or two JS courses. Code School, Code Academy, Udemy all have great courses on Javascript. A couple of books I'd definitely recommend are Clean Code and Javascript, the Good Parts, I'd say these are ubiquitious and essential reading for any developer looking to get better.

Less and Sass are for doing stylesheets better. They basically introduce programming concepts like functions and variables into CSS.

Gulp and Grunt are task runners. Tests, minifying, linting and live previews can all be done with them.

Angular and React are basically front end frameworks built with flavours of JS. They introduce OO concepts into javascript and the MVVM/MVC way of working for the front end. The are markedly different from how they do things.

With the other things, there's basically a wealth of information for them.

Needless to say, you have a lot of reading and practicing to do. Luckily these days there's lots of examples and documentation for every one of the things you've mentioned.

I've been in a somewhat similar situation. First off, tell your boss that the deadlines aren't happening. They're trying to get all three points of the project management triangle, and it's not going to work. They need to compromise on something. While they're figuring that out, let's get to work.

Step one, if you haven't done this already, is to check everything into version control. You can't do anything about the past, but you can fix the future.

Working Effectively with Legacy Code is a well-reviewed book. Maybe you'll find it more useful than I did - ask your boss to buy it for you. My summary of it is:

1. Write tests for as much as you can without changing anything.
   
2. Refactor a tad to open up more testing opportunities.
   
3. Repeat.
   
   You need a working test environment. The one the customer calls production is ideal (for you), but if that's not going to work, you need something as close to it as possible. It is management's job to solve this problem for you so you can do your job. Tell them that you're working with the 4-hr feedback window, and the more time they take to fix that, the longer this is going to take.
   
   You mention that there's no documentation, and that you've read thousands of lines of code but still don't understand how it's pieced together. As you read the code, write the documentation. Be as extensive as you can. This is also a good time to write tests that verify the behavior you think is supposed to happen. And don't just read a file at a time, top to bottom - approach it always with a purpose, eg "how does this page get generated?". This will help you understand the flow, because you'll be tracing it repeatedly, so you'll start to see patterns in how it's all put together.
   
   May the Force be with you.

Take a look at the book Effective Javascript. It's a really excellent book that deep dives into specific examples and what to look out for.

Secondly, check out some of the tutorials on nodeschool.io. They get into some really neat and important Javascript things.

Thirdly, write some backend Javascript code in nodejs so you can use the skills you already have but apply them to backend concepts. Heroku has some really nice tutorials that will get you writing server code in just a few minutes. https://devcenter.heroku.com/articles/getting-started-with-nodejs#introduction.

Fourthly, use one or more of the popular frontend frameworks to build a simple Todo app. In fact, if you have the time, build the same Todo app in a few different frameworks, so you get an idea of how they work.

Also, when interviewing, just be honest. Tell them you have a number of years of experience but that you've worked for organizations that preferred quick and dirty over perfect. You can parlay that into a positive by showing how learned to get stuff done quickly without spending too much time on small details.

I'd go read books about the A+ cert (you don't need to certify but it's great material).

For other technical things I recommend a lot of books that are amazing:

• Clean Code: A Handbook of Agile Software Craftsmanship
  
  
• Computer Networking: A Top-Down Approach (6th Edition)
  
  
• Introduction to Java Programming, Comprehensive Version (9th Edition)
  
  
• Scripting with Objects: A Comparative Presentation of Object-Oriented Scripting with Perl and Python
  
  
• Art of Computer Programming, Volume 1: Fundamental Algorithms (3rd Edition) WARNING: GOD TIER
  
  Use technology books to learn processes, not end results. To be a better IT person, you should know how computers work as a system, not how to do say "Map network Drive in Windows", learn how those drives are mapped, what are the underlying fundamentals?
  
  

Python Cookbook 3rd ed., by David Beazley and Brian K. Jones, has a dedicated chapter about metaprogramming. The book is so good the other stuff may also give some insight on metaprogramming or alternatives. I already read it and it gave me insight on my code about metaprogramming and other topics, so it is pretty useful. You can also find a lecture from Beazley about the topic with a quick google search with his name and the "metaprogramming" word.

There's also Fluent Python by Luciano Ramalho, which has three dedicated chapters about metaprogramming. Didn't read the chapters myself but I'm half way into the book and it is awesome, so I'm having great expectations about those chapters.

Don't mind the metaprogramming "chapter count", it is just a piece of information. Quality is what you should be looking for. And I believe those books have it. Even though I admit an entire book about metaprogramming would be neat.

Senior dev here who is on the other side of things. One way to approach these situations is to try and approach the problem more from the business case. I’m not sure of your work culture, but you should be bought in as to why a deliverable is time sensitive and what there is to gain by delivering this week vs a week or two later. If people don’t have reasons, they need to be held more accountable for the longer term delivery. Tech debt is a slow killer. You’d be surprised with how much you can push back:
How is this feature being measured?
What is success criteria?
What are the next steps if successful? If unsuccessful?
What are we not doing in order to do this task? Is this the most impactful thing we can spend our time on?

Also, understand that any system is due for a rewrite every 4 years or so. No matter how clean you write, you’ll eventually have to refactor anyway. You defiantly want to maintain something workable, but keep in mind there is no such thing as a permanent solution.

And finally, Great book ok how to make small iterative improvements as you go.
Working Effectively with Legacy Code https://www.amazon.ca/dp/0131177052/ref=cm_sw_r_cp_api_i_Td0QDbFQKYV3T

I'm a Masters of Statistics student with quite a bit of interest in programming. I'm currently working through Discovering modern C++ which I find to be a nice concise text about modern features of C++. Many other C++ texts don't tend to make good use of modern C++ functionailities and end up with codes and styles that look like C more than C++.

In general I find people with Math/Stats write terrible code. So I really would recommend The Pragmatic Programmer and Clean Code for good programming practices (I prefer the latter to the former but both are good). Us maths students are too used to having abstractions in our head that we don't make clear in our code. We quickly synthesise complicated solutions to problems and code it up without making the logic transparent. Coding is a lot more fun when you don't need to sit around for a hour working out why the code you wrote a month ago works.

I'd recommend learning algorithms (texts already suggests elsewhere) using high level languages like R and Python. It's significantly easier to code up simple structures and algorithms without having to simultaneously grapple with a complicated language and its features. You are unlikely to ever code up your own efficient data structure or algorithm, the point is to understand the benefits of each and use someone elses implementation when you need to.

Finally always code with some form of static code analysis. For me this means using Sublime Text along with a SublimeLinter plug-in, there's a different linter for most languages. This will keep your code conforming with good standards and force you out of bad habits.

As others had said, talk to another developer to see if it is even possible to make another Facebook app.

Other than that, if you have absolutely NO programming experience, learn the basics of Java first. I didn't have too much experience in Java, per se, but I was well versed in Python and Perl so picking up another language wasn't difficult.

Once you have Java down, you could do a few things. First and foremost, definitely go here and follow the steps to download everything you'll need, as well as the beginners guide to making your first app which will explain the basics of how android works. The videos from The New Boston didn't help me all that much, but if you want to take a look it wouldn't hurt. If you want a book, I would definitely get this one. It's written by Googles tech lead for android developer relations, and it will explain everything android to you.

Other than that, just think of basic applications, such as a calculator, photo viewer, stopwatch, etc, and just make them with the help of stack overflow and googles documentation on android.

Good luck!

Looks like most of your knowledge and experience so far is with imperative/object-oriented programming. You might want to have a look at functional programming, just to get some perspective. Scala, Erlang or Haskell could be some good choices here, or even Ruby (if you make use of blocks and don't use mutable data). Actually, Ruby is pretty cool and very versatile and practical, that could be a good language choice as well, and you would also be able to make use of your prior knowledge with OO programming.

One other thing that you could do with this time is to read some books! There are some wonderful "generic" titles that every programmer should read, in my opinion. Have a look at The Pragmatic Programmer, Clean Code and Code Complete, for starters. These might get you really inspired and pumped up for the undergrad college and computer science classes, as well as give you some good tips on new things to learn.

Have you read Working Effectively with Legacy Code?

I ask because mundane problems and new solutions do not always go hand in hand. Sometimes, working on the bleeding edge isn't possible; even when it is I've been there correcting Microsoft employees in C#, correcting Google on timezones in Chrome, tooling employees in their own stack, etc. and I don't think that's even what you're looking for. Its more of the same.

I've found grace in truly helping companies refactor, restructure, re-stack and modernize their applications for scale. Be it on mainframe applications or full-stack client-facing web applications, taking something old and completely ripping it out for something new is an art form. It's much easier to try and write your own code, find a problem - hit a wall, search for a solution and copy pasta. It's much harder to understand the problem you're facing, that stems from understanding someone else's code and derive a solution. In the same way it's easier to create something new then fix something old (holding constant creativity).

This is what has led me to the art of architecture, refactoring beyond SOLID and design patterns by the GoF - but in truly coming in to a new company and really understanding their business first then their solutions and the consequences of re-writing all of their applications in a new, automated way.

I'm not your "pixel-perfect" guy. While I see why you focus on the "front-end" being what bores you, I think instead you're bored by cookie-cutter solutions you can even begin to find on StackOverflow. I've traced problems on a mobile web client down to processor implementations. I refer to real problems as greenfield, most likely inaccurately. I find design both consequently and paradoxically crucial and irrelevant to success. You can have the prettiest looking face with no neck, working body and arms or everything working just fine but damn ugly to look at and you'll steer clear. It just might not be what interests you.

It's finding where you fit into the puzzle that matters most - this career is both scientific, relational and calculated as it is the most creative art form on the planet. They say development is one of the most free art-forms one can hope to master. Go figure.

--ramble, ramble, ramble

The book Learning PHP, MySQL, JavaScript, CSS & HTML5 was one of the most useful PHP books I read as a newcomer to PHP. It's very basic but it teaches how you can start using PHP to do useful and interesting things.

After making it though that book, I think PHP Objects, Patterns, and Practice is a really good next step. It will help you learn to design, organize, and write your code to a more professional standard. It will also help you better understand the workings of a PHP framework.

Ah, yes, but that depends on how you define 'quality', i suppose. I'm not sure that support for CSS 2.1 is important to them (i can only guess). What i do know, is that the procedure i have witnessed when doing my graduate project at MDCC was rather elaborate and thorough. There are actually books ( 1, 2. Both required reading for every MS developer) that describe their security assurance process quite well, if you should be interested. Well, almost. Their internally developed system for automated code review (which is applied as a supplement - not a replacement - to the manual review) is not discussed, but i can assure you that it is quite fabulous.

Even if you don't plan on writing your bots in C/C++, you should still understand how most commonly used compilers compile them to native code.
Most games* are written in C/C++, although .NET ones seem to be gaining popularity.
Once again, assuming Windows, it's usually enough to know how MSVC works.

It's hard to summarize what exactly is 'necessary', as a lot of this comes with experience and some trial & error, but I'll try it anyway:

• Understand C/C++
  
  
• Understand how C/C++ code is compiled to native code
  
  
• Understand x86 assembly
  
  
• Understand the portable executable file format (.exe, .dll, ..)
  
  
• Understand how Windows processes work
  
  
• Basic understanding of how OpenGL and DirectX work (interaction points game<->gfx-backend often provide good starting points)
  
  
• Windows API experience
  
  
• Know your tools (IDA Pro, OllyDbg, WinDbg, ..)
  
  
• Many many more..
  
  Some good starting points:
  
  
• Lena's Reversing for Newbies Best introduction to reversing imo
  
  
• R4ndom's Beginning Reverse Engineering Tutorial series
  
  
• ...
  
  Some references:
  
  
• Reverse engineering C++ code
  
  
• Intel 64 and IA-32 reference
  
  
• Windows API reference
  
  
• ...
  
  Some books:
  
  
• Reversing: Secrets of Reverse Engineering You have to read this!
  
  
• The IDA Pro Book: The Unofficial Guide to the World's Most Popular Disassembler Best guide to the best disassembler
  
  
• ...
  
  Hope this helps.

For the love of god find someone else that teaches Java at a high school level. Go over their lesson plans with them. Figure out what types of things they are teaching through each unit. While reading Head First is a good introduction to programming Java, it isn't necessarily what you need to be teaching these kids at this point.

Is this a first programming class for most? Or is this a follow-up to an introductory class? There are a lot of variables that will influence the content and concepts that should be taught.

Finally, and please don't take offense to to this, but I find it crazy that they are having someone with NO experience in the position of introducing people to a field that can be simultaneously fun, frustrating, rewarding, difficult, etc. Again, please don't take offense, but you will not do a good job grading as you have no experience. You need time to practice identifying good and bad code yourself. For every problem out there you can probably devise hundreds of ways to successfully solve it, but only some of them will be elegant and (hopefully in a teacher's eyes) acceptable.

For the love of god take a programming class! Have someone look at code you are writing because there is no better way to learn than to do it yourself. Head Start is a decent point to learn Java. Also check out Clean Code as it will help you learn some fundamentals of what makes good code. Finally, get together with another teacher that has experience teaching this subject matter and leech as much as you can off of them. Software programming can be a fun and very lucrative career. I understand you are lazy but please don't sour kids on it or start them off on the wrong foot.

I don't mean to be assuming too much about you, but good programmers with experience simply don't have those kinds of opinions. Those are the types of opinions you form when you're first starting out from your Programming 101 professor who is 5 to 10 years out of date. You end up with these strong feelings about pointless shit. Abstraction is your friend.

You're talking about "good code", but you've likely never even seen good code. After all, all I have to do is show you one example of good code in Java, and you'll be proven wrong, but you seem to be committed to your fallacious, likely trolling, argument.

I suggest you pick up Uncle Bob's Clean Code. I don't know that I agree with his idea of perfect code, but the ideas behind them will help you to understand what good code is.

Once you understand what the difference is between good code and bad code (hint: it's mostly about naming things), you'll be hard-pressed to explain why you think good code can't be written in just about any mainstream language.

It is normal :) I've read somewhere that 20% of our work time we develop new code and 80% new simply maintain the old code. And after a while it sound like true :)

I've been in a situation like you. I've been assigned to maintain a 0.5 million line c++ code base with no tests and no previous maintainers.

Considering that most of the time you're going to spend maintaining your/someones code base, code refactoring, modernizing practices are very valuable. And right now it seems like you have a chance to learn to do so.

Personally, what really saved me was this book: http://www.amazon.co.uk/Working-Effectively-Legacy-Robert-Martin/dp/0131177052/.
So I believe that working on your project is one of the paths you can become a better software developer :)

It can also help immensely to help future you, as well as others, if you create clear, concise variable names as well as stick to a strict set of naming conventions when you are crafting programs that may need to be tweaked months, or years down the line. I'm sure this seems obvious to a coder at your level, but so many people seem to overlook this important fact.

It bothers me greatly when I think back to some of the classes that I was taking in college (only a few years ago), where we were encouraged to use variable names like "x" or "string1".

Edit: If you haven't read it already, I would recommend checking out Clean code by Robert C. Martin; I found it to be a pretty fun read with some accurate, real life examples.

15 is really young. If you're relatively presentable, you might want to try Hyvee.

That said, it looks like from your profile that you have an interest in math and coding.

If this is something you're naturally skilled at, you shouldn't be working in fast food. You should be ignoring temporary financial gains to put yourself in the best place possible for college and technical internships.

The primary way to do that is to double down on your academics. At 15, you'll probably be going into your sophomore year? Don't accept any grade but an A from here on out. There's just no reason for it. You're obviously not retarded and school is easy.

Grab an ACT/SAT prep book. Take every practice test you can find until you get your scores into the absolute highest percentile you're able to.

If available, join a cyber academy, coding, math or robotics club at your school.

Go to things like this:

http://siliconprairienews.com/2014/08/meca-challenge-2014-preview/

Read books like these:

http://www.amazon.com/Code-Complete-Practical-Handbook-Construction/dp/0735619670
http://www.amazon.com/The-Pragmatic-Programmer-Journeyman-Master/dp/020161622X
http://www.amazon.com/Clean-Code-Handbook-Software-Craftsmanship/dp/0132350882


You'll lose a few thousand dollars over the next few years from working a shit job but you'll also be able to get a technical internship as soon as you turn 18 making double/triple minimum wage, while you gain proficiency in a relevant field.

You'll also go from $Texas in student loan debt to a free ride, saving you 30,000 to 100,000+ depending on what school you can get into on scholarship.

You may be 15 but I have to disagree with anyone else that you're only worth minimum wage. Everyone has skills they can work on and if you really want to help your family in the long term, work on what will make you successful.

If you have any questions regarding any of this, PM me.

Personally I'd say it's not about just fixing bugs, but learning to set your code up so that it is easily readable and bugs are easily identifiable. SOLID principles are principles to live by, all of my coworkers recommended the following book by Uncle Bob: https://www.amazon.com/Clean-Code-Handbook-Software-Craftsmanship/dp/0132350882

SOLID concepts aren't easy to grasp especially at first, I am still greatly in the dark on most of it to be honest. But just the few skills and practices like Dependency Inversion and SRP are already making my software easier to maintain and modify

I would never say never. They have their uses but there is definitely some best practices to adhere to if you choose to use them. Clean code by Robert Martin is a great book to read and details best practices.

Well, when talking about code maintainability it's not the same thing.

It's clear that both of you do not understand the concept of clean code. That's why you guys think that there is some language barrier that does not exist since you guys do not know what concept I'm talking about.

There is some stuff that's very valuable for every programmer to read and I recommend for you guys.

Clean Code

Working Effectively with Legacy Code

The SOLID principles

Those are very good books, give it a try and you might thank me later.

Have a nice day to you too Inukai!

You need this: http://en.wikipedia.org/wiki/Software_design_pattern

More specifically you need to develop good understanding not only of what design patterns are but also...

• how they describe a problem and a solution in abstract terms
  
• how you can identify when your problem can be described in more abstract terms that has a design pattern solution
  
• how you can modify design patterns to accommodate irregularities and inconsistencies in your problem, and when you should instead modify the problem to accommodate the design pattern
  
  These things can take a long time to get used to. Object Oriented is a very useful paradigm to work in but it is, in itself, a design pattern. It is also useful to know when you are better off not doing things in an object oriented way.
  
  But probably the most important bit of advice, and the thing that helped me to properly understand OOP is unit testing, and how to do it properly. If you haven't yet read it, then read this book and apply what it teaches you in your projects. Learn to use a good testing framework and a good mocking framework (in c#, for example, my preference is for Moq and NUnit) and learn to express yourself in test code. Learn also about dependency injection. These testing techniques, and the TDD story, will guide you not only in writing the units of your project, but also in architecting it and letting testability guide the design. Once you see how the design of your code is affected, you'll start to understand OOP a lot more, and also the finer points of the design patterns you want to implement.
  
  Good luck :)

I'm a programmer. This is my most favorite keyboard I've ever bought. It's mechanical, but the "clickity" is perfect, and low travel (it's 69.99... and 59.99 for the one without the number pad). They list a few options, but the one's that I find great have "Kailh Latest Low Profile Blue Switches". Also the back lighting is really nice.

https://www.amazon.com/dp/B074QM6F7X/

I don't know what language he's working with, but this book is excellent too. Many of the examples are centered around java/C#, but most concepts apply across many languages. It motivated me to explore further after reading, and to really polish up on my skill set.

https://www.amazon.com/gp/product/0132350882/

Depends what you want to learn. Some of my favorites are

• Code by Charles Petzold if you want to know how your computer works under the hood.
  
  
• Peopleware if you want to learn how to manage knowledge workers.
  
  
• Clean Code by Uncle Bob if you want to learn about good practices and program structure. Impressive content, covers much more than I expected.
  
  
• Don't Make Me Think if you want to learn about usability.
  
  
• Algorithms by Robert Sedgewick if you want to learn about DS & algorithms.
  
  
• The Art of UNIX Programming by Eric S. Raymond if you want to learn about the unix philosophy. Lots of hidden gems in there. Have you ever heard: write programs that do one thing and do it well; don't tune for speed until you've measured; imagine all this knowledge distilled to you in one book.
  
  This a good list to get you started :) most of my favorite books are not language specific.

I really enjoyed the C# Player's Guide. There's a newer version now but this is what I got.

Edit: I'm glad you guys liked this book as much as I did. To OP, I would offer two more suggestions.

1. Clean Code This book is NOT specific to C#. However, it gives you a holistic understanding of how to write code that is readable and effective. This is how I was able to transition from writing code that simply functioned (primarily for school) to code that my coworkers could pick up and run with. The book is the bible of software style where I work.
   
   
2. C# and the .NET Framework This is a very optional book in my opinion. It is also a little pricy, very long, more intermediate than beginner and you can gather much of its information from MSDN. However, I prefer looking things up and reading them in a book where possible. I also like having all this information in one location. When I have free time at work, I find myself more likely to flip to an unread section and skim over it than I would with the same information online.

I've found that I gained most of my best experience on the job, and that staying at a job where I wasn't learning anything was a huge mistake and detriment to my career.

That said... I don't think I'm a super genius either. I did well in college and my GPA helped with my first few jobs. But I have lots of hobbies outside of work, and rarely spend my time at home thinking about the office. A lot of times companies aren't looking for the super genius type either... if they were they'd have a hard time filling staffing requirements. I think the keys are learning how to interview well, focusing on letting the interviewer know that you're willing and good at learning and having the basics of OOO down to a T. Come off as confident, even if you don't feel it. It never hurts.

As far as books go, here are some of my favorites:


Programming Interviews Exposed


Programming Pearls


Refactoring



I'm mostly a java programmer, so here are three absolutely necessary java books:


Head First Design Patterns


Core Java 1


Core Java 2 - Advanced

It sounds like the first problem you have is that the code is not written in a way that is easily separated out. That is unfortunate, but unless you get a magic wand it is something you will have to deal with. It sounds like you have the .git sorted out, but really git is just both a parachute and a deployment tool - your problem is in the code.

Your basic setup sounds good with a development server. What I'd recommend is that you either run the developer server locally on your machine or run it in a virtual machine since you don't always seem to have access to a development server.

1. Stop making changes and make a list of the problems that you want to address, then figure out which you need to work on first.
   
2. Have a consistent development server setup
   
3. Refactor complicated code into simpler code - if you are spending too much time trying to figure it out it could be done better. Check Refactoring or Working Effectively with Legacy Code. Make little changes that work and test it. Don't try to fix the entire application at one.
   
4. Test what you are changing to be sure you don't break things (PHPUnit is perfect for this).
   
5. Define an overall structure that makes sense - it doesn't have to be a perfect MVC separation, but it have to make sense to You.
   
6. Use an HTML templating tool (if you are not already).
   

Cool :)

I would start with CD book https://www.amazon.com/Continuous-Delivery-Deployment-Automation-Addison-Wesley/dp/0321601912

Having read it you would understand how modern software development look like and you should understand why test automation is crucial these days.

I had once created a post about learning test automation - you can check it here
http://www.awesome-testing.com/2016/08/how-to-start-learning-test-automation.html

Here are two paths I proposed:

Path 1 - GUI Automation with Selenium

1. Learn basics of programming language first - preferably with Java for Testers book.
   
2. Learn basics of Selenium - preferably with Guru99 Selenium course.
   
3. Start writing real tests on existing website, for example http://the-internet.herokuapp.com/
   
4. Make sure you understand how Maven/Gradle, TestNG/Junit work.
   
   Path 2 - REST API Automation with Rest-Assured
   
   
5. Learn basics of programming language first - preferably with Java for Testers book
   
6. Learn HTTP protocol with HTTP: The definitive guide
   
7. Learn about REST API - Microsoft has recently published it's API Guide with useful links
   
8. Learn Rest-Assured with Baeldung, Test Detective or some different guide (there is plenty of them)
   
9. Write tests against real API. Check my post which you can use as a reference.
   
10. Make sure you understand how Maven/Gradle, TestNG/Junit work.
    
    There are a couple of testing books which are worth reading too. Perhaps this one is the best https://www.amazon.com/Agile-Testing-Practical-Guide-Testers/dp/0321534468
    
    Just start small with basic checks. You may even use my github project https://github.com/slawekradzyminski/AwesomeTesting
    
    Hope I hadn't overwhelmed you :D
    

Read this book.

Then, after reading the whole thing cover to cover, start working on your proposal.

From some of the questions you're asking about jQuery integrating with a framework, it's clear that some more basic concepts of how to isolate legacy code and migrate piece-by-piece would be very helpful.

Also, just a suggestion, but I'd highly recommend doing the new development in TypeScript. It'll compile to play nice with any other code you might need it to, but will offer you some awesome tooling that will help in maintaining your project moving forward.

Nice! It's a good start, although I can tell that you're a novice developer.

A handful of specific directions you could look into:

1. Double-down on ES6. It's not going anywhere. let instead of var, arrow functions wherever appropriate (NB, this is not everywhere). await and async are great if you have good reasons to use them.
   
   
2. Testing. Learn you some test-driven development! In Javascript-land, a couple of good tools for this are Karma and Jasmine. The key here is to write the test before the code. This forces you into creating testable code, which, as it turns out, is generally more maintainable code.
   
   
3. I highly recommend reading Clean Code which goes into TDD and many other aspects of professional coding etiquette. It will also give you an idea of how to organize your source code (hint: the business logic probably shouldn't be all under the routes directory).
   
   
4. Consider coding your server in a different language than your client. This is purely to help you expand your horizons a bit beyond Javascript. I recommend Python 3, potentially with Flask.
   
   
5. Find someone else to help with the project! This could essentially double your learning as you'll be forced to understand how someone else might approach a problem (which is often in a different way than you might choose).
   
   Finally, you might consider the CS degree route. I didn't finish my CS degree (although I did have a diploma in computer programming from a community college), and I think it probably pushed my career back a few years. It's certainly doable without the degree, but it's essentially concentrated learning that's well-recognized and can set you up with an initial network for your career. If you go this route, try to do it cheaply; consider community college first and transferring credits, or going to a cheaper state school (unless you can get into e.g. MIT, Stanford, or Waterloo, i.e. a place well recognized by name for CS).
   
   People here will (and so far a few have) say that the CS degree is absolutely necessary; this is because most of them are CS students. I don't think it's necessary, but it helps.

I'm going to start by assuming this may be maintained by another person at some point in the future. First off, naming. Although it is kinda targeted towards Java, the majority is directly applicable to C#. Clean Code. The underscores and you prefixing an abbreviation for the type should be changed. An example would be:

i_orderID

Changes to:

OrderId

because of the fact that it is a public property, and you've already told us it is an Int when you declared it. Doing this will allow others to maintain your code with less headache. https://msdn.microsoft.com/en-us/library/ms229045(v=vs.110).aspx is an MSDN article that goes over some of it.

Next, spaces in the folder names, you should avoid that for the same reason above, use PascalCase, no spaces, no hyphens, no underscores if possible.

You have no guard clauses in there. An example of adding one in would be (Line 31 'DataObjects.cs):

if (string.IsNullOrEmpty(displayLine1)) throw new ArgumentNullException("displayLine1");

Favor guard clauses over exception handling wherever possible. When you need to handle exceptions, handle them specifically. If the code you are calling can throw an InvalidOperationException, favor catching that over just Exception. Exceptions should be exceptional, not a common occurrence in your code, guard clauses help with that. Another example would be (Line 96 'Program.cs'):

if (File.Exists(s_directory + @"\Bricks.xml") { ...the rest of the code that uses that file here }

Use meaningful names. 'displayLine1' as a constructor parameter is ambiguous. Sometimes it makes sense to shorten some of the names as well; 'customerWhoPurchasedId' could just be 'customerId'.

In DataObjects.cs, you are returning '-1' as an error, I would use something more meaningful than a number. If you are going to use a number like that, use an enum so that you can read your code using friendly names, '-1' is ambiguous, but something like BrickSearchResult.Empty is not.

Style out of the way, now let's move on to data. You are a database guy. I would suggest using a database to store the data over an xml file.

Next. You are doing a ton of work in your application's main constructor. Move that code out of there, and let it initialize the app unimpeded. People debugging your code later will thank you. I would suggest using the Form_Loaded or whatever the Forms equivalent for Window_Loaded is.

On a general note, follow the principle of having each small piece of code do one thing, and one thing only. Your main class is also responsible for data access, it should not be. You should have separate classes for that, this is called 'separation of concerns'. Your CRUD operations should all be in the same class. Each class should have its own file whenever possible. So 'DataObjects.cs' would be split into 'Customer.cs' and 'Brick.cs'. Keep in mind that you can use folders in your solution as well to keep things a bit more organized.

You are welcome to PM me if you have other questions.

>How do you get clients?

80% of my clients I've met via reddit (/r/forhire, /r/torontojobs , most often from people responding to my posts, sometimes months after I post them). A few others were met through friends who worked at the company

> do you charge for the price of a domain an hosting or do you expect the client to take care of it

Depends on the client. Ask them if they want you to take care of it for them.

> I won't want to sound super shady to anyone who might be interested in getting a webpage built by me.

Have a list of prior work, social media presence helps (twitter, linkedin, github). Your portfolio doesn't have to be a website. I send a bulleted list

Having your own domain name for emails should also help. Google Apps is just $50/year.


>I have experience in HTML and CSS

Learn Javascript. At least a little bit. I'd recommend reading this book cover to cover : Effective Javascript by David Herman, a chapter a day, it'll take you 2 weeks, maybe 3.

There are a few books I recommend. I think a couple of things are very important to wrap your head around, but before all that comes the basics. For instance, knowing your primitive types, methods, loops, and even OOP which would include things like; classes, structs, inheritance, polymorphism, etc,.

Then move onto some very good readings;

1. Clean Code - This book is going to go through a lot of concepts and keeping your code maintainable and is a very short read.
   
2. The Pragmatic Programmer - This one will go through, what I believe, you're looking for. Helps you get into the mindset of a 'pragmatic programmer.'
   
3. Introduction to Algorithms - This I wouldn't start until you're fairly comfortable with programming in the language you are familiar with. By this point you should definitely have the basics down. In fact, I might argue do this one after you've read the other two.
   
4. Lastly, I'd recommend doing Project Euler which is really going to put your skills to the test. It is very mathematical but if you're up for the challenge this will push you far.

I don't think Laravel is the right direction to be going, honestly. Laravel is great for starting new projects, but it isn't so great if you want it to be just a small part of a larger site.

I suggest you check out the following two books:

Working Effectively with Legacy Code

Modernizing Legacy Applications In PHP

I've read the first one, and can definitely recommend it. The second I haven't read, but it sounds like it may actually be more appropriate to your actual situation, since the first book often assumed that your starting code base is better than what you seem to have.

With the assumption you already have a good portofilo and linkedin profile, you can also try contributing to open source projects and have your own projects on Github. This might get you noticed. Open source projects always have this beginner bugs that needs to be fixed because the core members usually work on more important stuff. You can also try fixing issues for money with bountysource. There's also Stackoverflow, you can answer some questions there. Try to have a project of your own and if you learn new stuff you can write them up in a blog or something. These stuff not only make you noticed but also make you a better programmer as you will learn new stuff and practice your skills.

Also try to make yourself better. Everyday try to learn something new. Find about new frameworks and libraries. Read books and blogs. Also read this book if you haven't already: Clean Code. If you want to work with others, it's very important to write readable code.

And trust me, web devs can make a lot of money, so don't lose yourself. If you have any passion for what you are doing, don't ever give up.

10000 limit again. Reserving this comment for the Programming section:

PROGRAMMING
Gray Hat Python: Python Programming for Hackers and Reverse Engineers
Beginning Python
The Python Standard Library by Example (Developer's Library)
Shell Scripting
Shell Scripting Recipes: A Problem-Solution Approach
Linux Command Line and Shell Scripting Bible, Second Edition
Wicked Cool Shell Scripts
sed & awk (2nd Edition)
The Ruby Programming Language
Beginning Ruby: From Novice to Professional
Ruby on Rails 3 Tutorial: Learn Rails by Example
Agile Web Development with Rails
Automating Microsoft Windows Server 2008 R2 with Windows PowerShell 2.0
Pragmatic Guide to Subversion
Programming Perl
C++ Primer Plus
The AWK Programming Language thanks sjhill
Modern Perl thanks three18ti
High-Order Perl thanks three18ti
The Art of Scalability thanks mr_chip
Scalability Rules thanks mr_chip
Continuous Delivery thanks mr_chip
The Varnish Book thanks mr_chip

Yeah, and that's largely the problem when software engineers run into "academic" code -- the conventions used are all mathematical or physics-type nomenclature, but it makes it almost impossible to read/follow for someone that's used to reading code, if that makes sense.

There's a fantastic book called Clean Code that talks about how to just write code better and in a more readable manner. It's pretty readable by people with any level of coding knowledge, and I'd highly recommend it should you ever want to cross into the realm of software as a profession, or as a more serious hobby ☺

Smalltalk Best Practice Patterns by Kent Beck. In my opinion, it's his best book. It's a great book on the nitty gritty of coding.. great for all programmers. It's easy to read even if you're not a Smalltalker; all you have to do is google for a Smalltalk cheatsheet.

I also like Working Effectively with Legacy Code. It's about the sort of code that most of us confront daily: how to deal with its problems, and get it under test so that you can refactor it or add to it without gumming it up.

Yeah, firstly, what the other guy said - you actually HAVE created yet another template engine/syntax, and what's more it's a pretty useless one. As he said, you're missing: "conditions, loops, filters, escaping, including other templates, inheriting other templates, and so on."

So that's a start. Also, you commented that this ensures:
>your templates are HTML valid, much cleaner and shorter.

But it actually does nothing to ensure your HTML is valid at all! The HTML is only valid if the HTML is valid. Has nothing to do with this templating engine, nor should it have anything to do with ANY templating engine (if a template engine took in valid HTML and spat out invalid HTML, it wouldn't be worth using and would clearly be broken anyway).

It's not cleaner. It's less clean. This is messy and complicated - it'd be really hard to keep track of your views this way. You'd have mess all over the place - instead of going into a nice clean HTML view with very little logic and just a few variables spat onto a page with perhaps a loop or two on there just to run through recordsets, you've now got to go hunting around trying to figure out what's going on.

It'd definitely not cleaner. It's unclean code - it's also adding complication for literally no benefit at all - infact it works against you because it can't handle the stuff the other guy mentioned above.

I had a look at some of your older comments and noticed one where you boasted about your HTML widget generator class - you were boasting about how you'd written one massive class that has methods that directly spit out HTML, and you even argued that this is somehow better design than having (paraphrasing) "loads of classes with just a couple of methods on them in your system"

The fact that you'd make this argument reveals that you don't actually know OOP, or at least, you didn't when you wrote that comment. Having one massive class that tries to do everything is simply not Object Oriented code. You are (or were then at least) writing procedural code that happens to be wrapped in an object - that's not object oriented code. In the example here, having many small classes with only a couple of methods on them is easily a superior design.

Anyway, rant over.

Edit: re-opening rant for a moment:

Your moan about frameworks speaks volumes too. It's really only in the PHP world that people argue against frameworks as if they're a bad thing. Probably no coincidence that virtually every PHP dev I've ever met who told me they were anti-framework also happened to write really awful code that was virtually impossible to maintain. Perhaps you should try using a few frameworks? You would learn a lot from them.

Edit 2:

This comment: http://www.reddit.com/r/PHP/comments/1a9003/good_guidance_for_shifting_to_oo_from_procedural/c8w0br4?context=3

>The alternative is dozens of classes (and files) scattered all over your project Aside from that there's nothing wrong with that..

>It's wasteful and shows poor craftsmanship. It introduces lots of places where things could go wrong, requires more effort to babysit and it's an obvious rookie mistake :-/ on another /r/php thread someone pointed to this great video Stop Writing Classes

Oh god.

>It's wasteful and shows poor craftsmanship.

Oh god. That's so bad. You're saying the exact opposite of what is true. What YOU did, with the one massive class that does far too much stuff is wasteful and shows poor craftsmanship. Separating the code into smaller, more manageable, more testable classes with clear purposes and simple interfaces is actually GOOD craftsmanship and is all part of good design. The person responding to you there and then noted that you were not writing OOP:

>What you've got there is mostly just procedural code tucked into a class for organization. This is not OOP, and you will not be able to reuse code as well as if it was. For example, name is common to all form elements, yet you would have to have a name argument on every method instead of just a base class. And if you perhaps decided to add some data-xxx property to your form elements you would have to do it to every method rather than in one place.

HE was right and you were wrong.

Check out this book if you genuinely care about good design. In this book, Robert Martin actually shows you ways to FIND hidden classes in your system - to actually increase the number of classes in the name of good craftsmanship, and to help you make your system EASIER to maintain.

You are not as good as you think you are I'm afraid - if I were you I'd take a step back and take some time out to read books like this and maybe find some good online courses about the solid principles. Here's a good one, but it's not free.

Also, sorry, but I laughed out loud at your comment here: " it's an obvious rookie mistake".

Hopefully you will take my advice productively and use it to become better at your craft. It's obvious that you care, but right now your implementations are all wrong.

Honestly? Mostly youtube and udemy tutorials. Here below is my copy pasta of C#/Unity stuff which I post pretty often on /r/learnprogramming and /r/learncsharp . I only need to find a moment one day and add some computer science theory links.

Free C# ebook

• http://www.csharpcourse.com/ <- The download link is under 'here' at the end of the first paragraph.

If you want youtube tutorials:

• https://www.youtube.com/playlist?list=PLGLfVvz_LVvRX6xK1oi0reKci6ignjdSa <- apart from C# this dude has also A LOT OF other tutorials on many other languages.

• https://www.youtube.com/watch?v=pSiIHe2uZ2w <- has also pretty good Unity tutorials.

• https://scottlilly.com/build-a-cwpf-rpg/ <- learn WPF (desktop application with GUI) by making simple RPG game.

• https://www.youtube.com/user/IAmTimCorey <- This guy is also good, but I dislike his coding style and that he uses a lot of nugets instead of writing stuff himself.

Book reference guide:

• https://www.amazon.com/C-7-0-Nutshell-Definitive-Reference/dp/1491987650/ref=sr_1_1?ie=UTF8&qid=1547990420&sr=8-1&keywords=C%23+in+a+nutshell <- But treat is as a language reference guide, not a programming learning guide.

Text-based tutorials

• https://www.tutorialspoint.com/csharp/index.htm <- C#

• https://www.tutorialspoint.com//wpf/index.htm <- WPF (GUI programming)

Udemy - wait for $10 sale which occurs at least once in a month:

• https://www.udemy.com/csharp-tutorial-for-beginners/ <- for C#, dude has also more advanced tutorials to choose from.

• https://www.udemy.com/user/bentristem/ <- for Unity

Do not move to Unity or WPF before you get good grasp on C# syntax and OOP concepts.

Coding style (read after getting good grasp of OOP concepts)

• https://www.amazon.com/Clean-Code-Handbook-Software-Craftsmanship-ebook/dp/B001GSTOAM/ref=sr_1_1?keywords=clean+code&qid=1562330510&s=gateway&sr=8-1 <- Clean Code, recommended for every newcomer at my work

• https://www.amazon.com/gp/product/B075LRM681?pf_rd_p=2d1ab404-3b11-4c97-b3db-48081e145e35&pf_rd_r=22NFZ5GCWM7YMK2A5A2G <- Clean Architecture

Code every day. Work on as many little interesting projects as you can. If you don't know any languages I'd suggest starting with Python, there are a million different tutorials and resources online, so getting started shouldn't be a problem.

Add to that, read some books to learn about how software development projects work, different techniques, best practices, pitfalls, etc. Here are my recommendations on books: The Pragmatic Programmer, Refactoring, Code Complete (a bit dated, but still solid), Rapid Development (slightly mis-titled, it's a good overview of different development practices), The Architecture of Open Source Applications, and Design Patterns. Code as much as you can, be ambitious, be analytical and introspective about the problems you run into, and read and understand those books too. There's a lot more you'll need to learn to become a good developer, but what I've described will give you a very strong base to build on.

Oh, and if you don't already know discrete mathematics you'll need to pick that up. I'd recommend this book.