Understandable. My comment was already getting to long, and I didn't have space to explain every detail.
BTW, if you feel members on your development team aren't capable of self-managing, this book is really good to help you develop those skills: http://www.amazon.com/Clean-Coder-Conduct-Professional-Progr...
Self-management is something every programmer should have in their skill-set.
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
There's a good book about how to prevent managers from walking all over you: http://www.amazon.com/The-Clean-Coder-Professional-Programme...
The opening chapters describe programmers in crunch time, and compare them with the lawyers at the same company who leave promptly on time. The rest of the book discusses how to achieve that for yourself.
http://www.amazon.com/The-Clean-Coder-Professional-Programme...
Uncle Bob in particular (the author of Clean Code[0], The Clean Coder[1], and the Clean Coders videos[2]) is a lot like Wozniak.
[0] http://www.amazon.com/Clean-Code-Handbook-Software-Craftsman...
[1] http://www.amazon.com/Clean-Coder-Conduct-Professional-Progr...
Yep. Uncle Bob is one person, too. tl;dr Think for yourself and don't listen to somebody just because they hurt your feelings.
> To pick a topical example: Is TDD hard in Rails apps because TDD is dead or because Rails makes TDD hard?
This is a misrepresentation of what DHH has said [1], which is that strict adherence to TDD can make your designs worse:
> Over the years, the test-first rhetoric got louder and angrier, though. More mean-spirited. And at times I got sucked into that fundamentalist vortex, feeling bad about not following the true gospel. Then I'd try test-first for a few weeks, only to drop it again when it started hurting my designs.
> Used as a hammer to beat down the nonbelievers, declare them unprofessional and unfit for writing software. A litmus test.
If you watch the conversations between DHH, Martin Fowler, and Kent Beck, it seems to me that they all agree: testing is good, test-driven design can be bad, and mocking everything is bad [2][3].
I took some time last week to re-read Uncle Bob's book, Agile Software Development, Principles, Patterns, and Practices [4], and Kent Beck's book on TDD [5]. There was a huge difference: Uncle Bob focuses on test-driven design, while Kent Beck focuses on test-driven development. Uncle Bob claims that test-driven development (especially through mocks) universally improves your design, because it reduces coupling and enables refactoring. Kent Beck talks about productivity, certainty, refactoring, and documentation. Uncle Bob says most of those things are just a side-benefit: the real point of TDD is decoupled design.
Uncle Bob's other book, The Clean Coder [6], berates people who do not strictly adhere to test-driven design: if you don't do it, you are unprofessional (he mentions this repeatedly). He says that TDD being universally good is a fact, and anybody who says otherwise is just ranting.
> Nowadays, however, they are just rants. The bottom line is that TDD works, and everybody needs to get over it.
> TDD is the professional option.
> It could be considered unprofessional not to use it.
The bottom line is that developers should listen to each opinion and use their head. Don't be hurt when somebody calls you unprofessional for not following the One True Gospel™ and mindlessly adopt practices. Don't be hurt when somebody says that mindlessly following those practices is counterproductive. Using your head is about the most professional thing you can do.
[1] TDD is dead. Long live testing. http://david.heinemeierhansson.com/2014/tdd-is-dead-long-liv... [2] Mockists Are Dead. Long Live Classicists. http://www.thoughtworks.com/insights/blog/mockists-are-dead-... [3] Is TDD Dead? https://www.youtube.com/watch?v=z9quxZsLcfo [4] Agile Software Development: Principles, Patterns, and Practices. http://www.amazon.com/Software-Development-Principles-Patter... [5] Test Driven Development By Example. http://www.amazon.com/Test-Driven-Development-By-Example/dp/... [6] The Clean Coder. http://www.amazon.com/Clean-Coder-Conduct-Professional-Progr...
[1] - http://www.amazon.com/Clean-Code-Handbook-Software-Craftsman...
[2] - http://www.amazon.com/Clean-Coder-Conduct-Professional-Progr...
[1] http://robertheaton.com/2013/04/01/check-youre-wearing-trous... [2] http://www.amazon.com/Clean-Coder-Conduct-Professional-Progr...
There's a social factor to being a professional too; it's not just raw programming skill or experience.
Fowler's "Passionate Programmer"[1] and Uncle Bob Martin's "Clean Coder"[2] are both excellent books on making a career out of writing software. Not specific to a particular tech, but both quick interesting reads that contain lots of nuggets of great advice.
Good luck on your journey. I'm sending this link to my 13yr old son. He's been exploring Ruby and Processing.
[1] http://pragprog.com/titles/cfcar2/the-passionate-programmer [2] http://www.amazon.com/Clean-Coder-Conduct-Professional-Progr...
- behind any given reason, there is a complex network of real reasons. You don't need to second-guess any decision/order/suggestion, but it helps understanding.
- most user stories / user requests are raw diamonds waiting to be polished. ("What do they really want me to solve")
Essential reading list:
- Clean Coder and Clean Code https://www.amazon.com/Clean-Code-Handbook-Software-Craftsma... https://www.amazon.com/Clean-Coder-Conduct-Professional-Prog...
- Test Driven Development by Kent Beck https://www.amazon.com/Test-Driven-Development-Kent-Beck/dp/...