Found 12 comments on HN
data_hope · 2016-12-13 · Original thread
- don't only worry about code or getting features shipped, but about the process, how to deliver quality.

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

ktRolster · 2016-05-20 · Original thread
That's fair. I think the vague approach of "they were clearly lacking skills" was what triggered my response.

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.

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.

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

ktRolster · 2016-04-06 · Original thread
You need to respect yourself to get that. If you're willing to work more than 8 hours, managers will take it from you.

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.

grimborg · 2015-01-05 · Original thread
The Clean Coder is a good read for starting programmers. It goes beyond code to what it takes to be a software professional.

http://www.amazon.com/The-Clean-Coder-Professional-Programme...

oblique63 · 2014-12-05 · Original thread
Check out the guys over at 8th light: http://blog.8thlight.com/

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

[2] http://cleancoders.com/

> Because DHH is just one person. And he only has DHH's experiences.

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

raju · 2014-04-22 · Original thread
Great post. If you want a even _further_ expanded version of this I highly recommend "Clean Code"[1] by Robert C. Martin, and I learned a few days ago that there is a follow up book, "The Clean Coder"[2] which I am yet to read

[1] - http://www.amazon.com/Clean-Code-Handbook-Software-Craftsman...

[2] - http://www.amazon.com/Clean-Coder-Conduct-Professional-Progr...

baumgartn3r · 2013-04-02 · Original thread
Super interesting post! I'd have mentioned Unit tests as another measure to tackle uncertainty. Simple, boring unit tests (reminds me of this post[1]). Maybe he just assumes those will exist when professional engineers write code. [2]

[1] http://robertheaton.com/2013/04/01/check-youre-wearing-trous... [2] http://www.amazon.com/Clean-Coder-Conduct-Professional-Progr...

robmcm · 2013-03-25 · Original thread
You shoudl read Robert C Martin's, "A clean coder". http://www.amazon.co.uk/Clean-Coder-Conduct-Professional-Pro...
koko775 · 2012-08-28 · Original thread
I suggest you read this book: http://www.amazon.com/The-Clean-Coder-Professional-Programme...

There's a social factor to being a professional too; it's not just raw programming skill or experience.

joelhooks · 2011-06-13 · Original thread
A couple of book suggestions:

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

Get dozens of book recommendations delivered straight to your inbox every Thursday.