When you start looking for jobs, only join a company that does TDD and pair programming. Ask about this in interviews.
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.
The Pragmatic Bookshelf published a neat related book that's a light ~100-page read called Remote Pairing: Collaborative Tools for Distributed Development [0]. It also mentions a few companies that do pair programming exclusively. Pivotal Labs is one that comes to mind.
Well the things I listed in my OP are my concrete ideas for how to approach these working on these things. If you have other concrete suggestions, I would love to hear them.
As an example: The reason why I focus on studying rails is that all of the debugging techniques I know about involve getting a better idea of the system at some layer of abstraction. I suspect that my best shot at getting better at debugging is to know the framework the code is written in very well and thereby be able to understand the codebase more easily.
For a problem like "I can't get clarity around what we are trying to do here.", it seems like there aren't any books on the topic. Thats why I figured that finding a mentor would be good.
The problems you describe sound like communication issues, not technical issues. Specifically, it sounds like you have a real problem with asking for help when you need it. Your time might be better spent reading a book on effective communication or perhaps taking a course at a local community college.
Here is something I don't understand: How does one effectively deliver on a project while writing crappy code? Doesn't trying to do that result in the codebase becoming so confusing that you don't know how to add things to it without breaking other things?
You write crappy code to meet unrealistic deadlines, you get promoted, hand off shitty code to someone else who is viewed as a low performer because they were too busy writing good code.
It's not actually that clear cut (it's more like an average performers who write shitty code quickly will be rewarded over an average performer writing solid code less quickly), but code quality isn't legible to management and HR, who control resource allocation. Even a line manager knowledgeable about the code base has incentives to lead a team that produces shitty code now instead of good code later.
When writing crappy code you are either not thinking long term at all, or you are just "kicking the can down the road", in that you'll pay for it later when there isn't a time crunch.
Bah. That's later on. Right now, we're delivering at a speedy pace. The time we save now can be used later. Hell, I might not even be here later, so I won't have to care.
> failure teaches you which mistakes to avoid next time
As a recent grad who has been fired from two jobs, I would be afraid to join a poorly written project because I would worry that I would fail and then be fired.
Learning how to be successful is pretty important and teaches you things you cannot learn from lurching from failure to failure.
Sure, but at a certain point, you need to learn a method to writing a maintainable codebase. Otherwise you never become capable of building a successful project.
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