Is Uncle Bob serious?

> What I am arguing against is saying a typesafe language obviates the need for ecc memory.

Which isn't what anyone said: I claimed you can do ECC in software and that type systems assist with that by making a clean interface and verifying the full implementation. (Since ECC is really just a lift of normal functions.)

There's little difference between using 9 bits in hardware and 9 bits in software, except that you need to cleanly load your ECC code onto CPU cache and you're using CPU instructions per byte loaded. The reason we do ECC in hardware is efficiency on an operation we're doing on literally every byte.

Lots of systems, eg harddrives, use ECC in their actual formats too, because you can do more complex ECC at the software level and not merely the extra bit. Sometimes, this software ECC is more efficient than hardware based ECC would be, because we're okay with less than 12.5% redundancy as long as we can still correct the errors we expect to find.

I'm reminded of an article I read a while back about the rather sizable effectiveness of checklists in the health sector, and how they're still not 'standard practice'. I think it's this article, but I'm not sure:

http://www.nytimes.com/2010/01/24/books/review/Jauhar-t.html

I haven't had any problems jumping around large codebases in smalltalk, clojure, or JavaScript.

I've had a lot more trouble understanding large Java codebases.

I thought they might be talking about difficulty refactoring.

Such big words. In other words: non-sense.

I worked in 6 different companies in 4 different countries across 3 different continents during my 10 years in IT. And no-one gives a shit about delivering bug-free code or good practices.

There is such a thing called peer-pressure, probably you have never heard about it, it works like this: while you are fiddling with your scientific method to test everything properly, the guy sitting right next to you will get the same feature done when by going home and putting in a lot of overtime to make it look like he was working extremely fast and he pulled it off in matter of days and much faster than you.

He will also give a shiny presentation and show off his working demo application while you are still writing tests in your scientific method.

So after a few days your manager comes over to your desk and asks the guy sitting next to you if he could do the same thing, but now in a much more important project, where the deadline is super important. "Of course" - he replies, and he gets into a very interesting project and gets appraisals both verbally and also on his linked-in profile. He also gets a salary raise, since he is such a reliable guy who outperforms everyone. While you are still writing tests and wondering why nobody cares about your scientific method.

I hope it's clearer now.

6 companies, 4 countries over 10 years? Are you a consultant? Otherwise, that's a LOT of job-hopping.

So, I was a consultant for a "systems integrator" for 14 years. I did enterprise Java, web apps, and backend legacy integration work. If you are anything like me, then you know of course no one in your organization (or the client's organization) cares about quality! You guys are hired guns, the "tiger team". You fake it till you make it. You move around, you're like a bedouin trader, you're a nomad.

Your comments about the coworker putting in OT to showoff and get ahead are just you wallowing in a bit of loathing. Never ever compare yourself with anyone else - we're all on our own tracks with our own tragedies and triumphs. If the guy wanted to bust his ass to make himself feel good, what do you care? God bless that dummy.

Anyhow, I think I can help with the loathing by getting a little philosophical with you. Two questions:

1. Are there bits of code or projects you can recall you've written over the last decade that you're really proud of? (Like, you can tell war stories about working on that code and you love those stories?)

2. Is ANY of the code you wrote going to be around in 5 or 3 or even 2 years from now?

The first question is to remind you of your craft, that it's really cool to make stuff work. The second question is to remind you that almost nothing you've done is built to last and is ultimately not going to leave any mark.

Now, don't despair. You can always take joy from your craft: let fly your creations to work in the world and do their little jobs and then move on to the next thing.

Reading your words, I can see that you're not taking much joy from the work right now. You don't have quality to hold up and you don't have good team dynamics where other people have your back.

In consulting, code quality will never be a priority nor of interest to anyone, especially in smaller firms. And, it'll be tough to build strong teams because you move around so much. You should really settle down in a city and get a regular salary job. You won't take much of a pay cut once you factor in all the benefits.

And there are plenty of big, established companies that practice TDD and have real Agile practices. Just search around and look at Fortune 1000 companies - the software teams working for those companies will signal quality to you through their blogs and open source offerings on Github.

As I said before, your #1 goal should be to sleep well at night and not work overtime. That means not being afraid of PagerDuty, not being afraid of deploying code at the last minute on a Friday before leaving for the weekend, not being afraid to relentlessly refactor the code to improve it, not feeling dirty about your code because you're not hacking anymore. When you're not afraid, you can have a team where members have each others' backs instead of backstabbing too. That goal of sleeping good at night is totally possible, I'm living it right now.

You need a new mindset. You need to improve your practices and start to claim your power as the developer. Read some code quality books, write some open source and teach yourself how to do TDD (I prefer "London" style TDD.) Listen to some of Uncle Bob's videos on YouTube or Safari Books online if you want to get into the groove. He's a goofball and a codger, but he's on the right track more than he is on the wrong track.

And, buck up dude ... I hope it's clearer now. :)