> Anyone have advice for "theory people" who can't code all that well starting out in industry?
Casually read one of these (which is how to perform technically):
All you really need is the above info on how to code well and write robust modular code that is tested, the rest is just doing whatever code style you see in your codebase. It also will serve you over any language at any job company... for the most part.
Then consider reading this after for how you should be as a person doing programming (which is non technical important information):
You will pick up frameworks and knowledge of the language as you go, no need to stress over it.
Spend the first year doing front and backend, then after 6-12 months (starting from day 0 of work) specialize in the area you find interesting, such as a framework, or databases, or backend, or microservices, or whatever you find interesting.
BUT you need to change your mindset (Read: Mindset , SoftSkills , and The Clean Coder )
I agree with all the top comments, but I want to add something else. Two things really.
First, it is ALWAYS harder to read code than to write code. Dont let that get you down. Like any skill, you get better at it. You learn what classes and methods dont matter, and where to focus your attention.
Second, you need to be aware that the code youre reading, might be garbage. What I mean is, the code might be so terrible, that no one could reasonably understand it. Ive seen production systems at big name companies that are utter garbage. I would strongly recommend reading the book The Clean Coder to help your understanding with whether or not the code is terrible or not.
Based on your technical focus, you're clearly (in my opinion) way above the "average" developer in technical ambition and appreciation for computer science.
A bit of unsolicited advice: If you organize your preparations around the concept of providing value to a prospective employer, rather than merely getting hired to write code, then I bet your outlook will change. One book (and definitely not the only one) that can help with that is Bob Martin's The Clean Coder: A Code of Conduct for Professional Programmers:
Uncle Bob in particular (the author of Clean Code, The Clean Coder, and the Clean Coders videos) is a lot like Wozniak.
TDD helps you break down tasks and, when you lose focus, you can regain it by re-running your test suite and seeing which test fails.
Pair programming help you because:
- They'll tend to have closer to a 10-6 schedule rather than encouraging you to stay up late.
- When talking through the problem with a colleague, you break the task down more easily and get through whatever mental block you have.
- You can't get distracted when someone else is right there.
It may be harder to find a company that does this because many folks think that they can move faster if they build something the "quick and dirty" way. "Quick and dirty" doesn't exist for you. "Quick and dirty" means that the project either fails outright or is one that you start procrastinating on until you get fired.
Take a look at the book The Clean Coder (http://www.amazon.com/The-Clean-Coder-Professional-Programme...). It talks about procrastination and how to overcome it.For a practical introduction to TDD, I'm a fan of Test-Driven Web Development with Python. It is Free. http://chimera.labs.oreilly.com/books/1234000000754
For a practical introduction to TDD, I'm a fan of Test-Driven Web Development with Python. It is Free. http://chimera.labs.oreilly.com/books/1234000000754