In earlier days of the Internet, /. was often the first and/or best place to go for "news for nerds" and "stuff that matters". Breaking news, in-depth articles, and a user base that was, often, very knowledgeable and experienced. Some of the 5-star comments from those early years were amazing.

Those days are, sadly, long past. I go to other places now, and come here only infrequently. "This, too, shall pass" I suppose.

There's a world of difference between "this isn't worth discussing or responding to" and "you're being fired[1] because you expressed a viewpoint that we believe is incorrect".

[1] replace fired with imprisoned, shot, blacklisted, or any other punishment, depending on the situation/country/time.

So, from someone else who has been in the same trenches:

Most organizations/teams are absolutely terrified of losing information. "What if this is needed/important someday??" What they don't realize is that first, that information is usually never used again; second, it can usually be found again pretty easily; and third, that information quickly becomes outdated with respect to the working code and is consequently MISinformation, not actual information.Then there is the cost of dragging it around, meetings and the psychological weight of "oh my gersh 45,000 bugs uggghh" and wasting time looking to see if a newly reported issue is really just a dupe and....

I can almost guarantee that at least 90% of those 45,000 bugs can be closed and forgotten about forever. They'll never be fixed, they're incorrect/outdated (either your software has changed or the environment has changed -- do you have defects reported against IE7 and IE8? Do you still have users on those browsers?), and they're just not important enough to fix in relation to the value that could be obtained by working on something else.

In fact if your team was to throw away the entire bug database and only start fixing bugs that are newly reported, you'd still be ahead of the game. You'd get rid of some useless meetings -- which would give you more time for fixing the bugs actually being reported. That's *really* hard to do, as I mentioned most companies are terrified of throwing something away. (As a crutch, you can keep the existing bug database in read-only mode for a limited period, and then mothball it.)

Regarding a few of the other comments:

"It is a poor craftsman that blames his tools." Absolutely. However, the same good craftsman who can do amazing things with terrible tools will choose high quality tools because he can do so much better work with them.

"It's... the rush to produce easy code." That continues to be a problem -- and everyone who wants to throw more bodies at a late project needs to be fed a copy of The Mythical Man-Month one page at a time -- but it's a different problem.

"Formal verification is worthless IRL". They keep working on it and maybe someday it'll happen; but in the meantime we could use design by contract to improve our code.

"There ain't no such thing as free memory checking." No, there ain't, and yes, when you get into things like tiny embedded systems and operating system kernels memory management and checking still has to be done by hand, but for a really really large (and growing) amount of software, the costs are very low compared to the benefits. Modern runtimes (JVM, CLR, V8...) do a very good job of managing memory.

The most commonly used languages do absolutely nothing to prevent programmers from creating completely unmaintainable and broken code. Like creating a public arraylist and then accessing it from all over, or creating 8-layer-deep inheritance hierarchies with untested spaghetti code that's impossible to understand and modify, or copy-pasting all over.

There are efforts to fix some of the problems -- making it harder to use 'null', encouraging immutable objects, simplifying concurrency, more capable type systems, better formal verification and static analysis. Functional languages seem to encourage better practices, although it may be that the self-selection process has led better programmers to adopt these languages. (A good programmer can write solid code even when using shitty tools. It's just more effort.)

In the meantime, if you are a developer: please please please take the time to learn and use good programming practices. SOLID, GRASP, Don't Repeat Yourself, Single Level of Abstraction, intention-revealing names, separation of concerns, input validation. Use TDD and the "red-green-refactor" cycle to minimize technical debt. Use tools that will help you find code smells. Read books like Clean Code, Working Effectively with Legacy Code, Code Complete, The Pragmatic Programmer, Refactoring, and Test Driven Development.

6 digits? What are you, 22? You have no idea....

When I got my ID (before Y2K) you could still browse the web with a modem, and a dollar would just about buy you a gallon of gas. We were in the middle of Clinton's "I did not have sex..." scandal (which, ultimately, nobody cared about anyway). Every woman in America was watching Titanic, and every man in America was saying "of course I'd like to see Titanic with you again honey!" with as much sincerity as they could muster. The Dow Jones was skyrocketing through 10,000 thanks to the dot-com boom, which was aptly named because boy did it go 'boom'. And speaking of bombs, The Phantom Menace came out and became the highest grossing Star Wars film ever, which was also appropriate as that film was (is) a gross betrayal of everything good in Star Wars. You could still watch actual videos on MTV (apparently, 2016 is the new 1999). And you measured your computer in Mhz and megabytes.

Pshaw! Get out of here with your "6 digit user IDs" flim-flam tallywhack, and while you're at it, get off my lawn too! You kids these days.

Every new thing is a 'toy' because it's unproven in the real world. An academic paper, or lab experiment, or startup company doesn't mean much. And for every 'toy' that ends up being the next big thing there are thousands that are failures.

And that's why research, and experimentation, and startups are so important. It takes hundreds or thousands of failures to find one success story, but the benefits of that one success pay for the failures a thousand-fold.

You sound much like my dad, who lived to be 94 (and passed away last year). He had his moments of doubt, having seen WWII and growing up during the Great Depression, but he was always amazed and impressed at the things we (humanity) accomplished in his lifetime.

If you and I live another 30 years we'll see incredible accomplishments and changes. Here's to the future!

Check out 'Ditto', it's a multiple clipboard utility and one of its features is "paste-as-text", via Shift+Enter. I use this feature All. The. Time. Especially when pasting into Outlook.

Can you expand on what you mean by this? Also, what are your thoughts on the way we measure GDP?

I've sent an email to the address on your Skytopia site.

Nice -- I'd love to have a big UHD TV for development. I started with a Commodore 64 and a TV. 320 x 200 resolution.

Have a look at http://virtualmonitor.github.i... or http://superuser.com/questions... (search for "windows virtual display driver") if you decide to work on the multi-monitor feature.

Yeah that would be great... at the moment my main display says "soothing nighttime" while my laptop screen shouts "midday sun" :). Multiple monitors is becoming more common, and your app fits pretty well with the power user demographic that's likely to have 2+ displays.

If this feature doesn't scratch an itch for you, perhaps you could try funding it via something like GoFundMe for a little extra in your pocket. Just a thought. Regardless, thanks for the time you've put into it, I'm going to try it for a week or so and see how I like it.

This looks great, I have similar complaints about Flux. One question, which I didn't see answered in the documentation: Does your app handle multiple monitors?

In my experience nearly all of the people who self-rate as an expert are really intermediate or maybe advanced.

I think the main reason for the gap is most programmers don't get the opportunity to work closely with a real expert/master. They judge themselves based on the apparent skillset of their current and prior co-workers, and once you have a few years of experience it's easy to fall into the trap of thinking that since everyone else around you is about equal to you or less experienced, you must be an expert.

tl;dr, if you think you're an expert you probably need more exposure to better programmers.