The picture posted on livestream reminds me of Joel's discussion of the co-pilot issue where someone would connect to themselves and get an infinite screen tunnel
They (did?) have a specific error message or exception type that they throw when that happens. I can't remember specifics but it was pretty funny how the application handled it.
These statistics are ridiculous when you consider that some teams could have a programmer that is 100x the skill level of the average developer on another team. The fact that developer productivity is so highly variable makes any kind of measurement impossible.
Because you can't define a "bug". What if the code works, but it does the wrong thing? Bug? Crashes, but it doesn't matter? Bug? Test finds it, but user would never use it?
That pretty much rings true with most projects I've worked on - apps with more code are generally worse. That especially applies for writing your own everything rather than using existing libraries (without very good reason).
@MichaelMrozek Best teacher I had came from [a company long ago swallowed up by SAP] who brought in a huge binder full of their code and another with their coding standards, and... just talked about it.
Software engineering has already advanced further than modern structural engineering even though it has been around a much shorter time. Consider how many bridges and buildings have been built in the world vs how much software? Way more software.
I came across a function very recently in our codebase at work that seemed insane, and I decided to just rewrite it, and kept running into problems, and after about 15 minutes I'd rewritten it into the exact form it was already in. I felt like finding the original author and apologizing to him for doubting his competence
@JonGalloway Well, probably. But for me it was like finding out the crazy guy down the road watched all of his comrades killed back in 'Nam. He's still crazy, but now you kinda understand why
@JohnSonmez Nonsense; you can't cram all relevant information about a function in its signature. The whole "comments are redundant" thing died out like 20 minutes after it started
@Hogan Sure, and you probably don't need to extensively document the String.makeLowercase() function, but you can't say "every time you write a comment you are failing" or "api doc systems are fail"
Comments are misleading. When I see comments in code, I assume they are old and didn't get updated with the code. If I read them at all, I use them as a story of what someone else thought the code did some time ago.
A wrong comment is worse than horribly complex non-commented code. A wrong comment can lead someone completely in the wrong direction. For that reason, a good developer always assumes comments are wrong.
Comments don’t show up in stack traces. I have looked through many stack traces in my career, and I can tell you for a fact, that when you are looking at a stack trace, you would much prefer self-documenting method names, than good comments.
@JohnSonmez I agreed with you until that last part; you don't need to assume that everyone else on your team sucks, or you're going to have trouble functioning
This went from "comments suck", to "wrong comments suck", to "comments suck because they're not in stack traces". Yes, wrong comments are bad, and comments don't help you in stack traces, but they're not somehow 100% useless
This was one of our definition questions, but also one that interests me personally: How can I find a guide that will take me safely through the Amazon jungle? I'd love to explore the Amazon but would not attempt it without a guide, at least not the first time. And I'd prefer a guide that wasn't ...
