engendered

It seems ridiculous, really -- developers commit to something because it saves them hours at the start, versus considering the months of work following -- but many technologies followed this curve. MySQL was a lot easier to start with than pgsql, so it won the early battle. PHP was a no-brainer to start with, etc.

The lesson is that your tool should default to essentially no configuration, no security, and simple beginnings, and it tends to pay off.

Many "older" entrepreneurs are simply building businesses and quietly earning success. Let's be real -- $20K is significantly lower than unsecured credit lines many established adults have. This is pitched to students for the same reason that a paper route is pitched to elementary school kids: because it's so meager of a benefit that, from a relative perspective, it only appeals to them.

If there isn't good sound suppression, I've found the best alternative is sound camouflaging -- the HVAC fans always distributing noise, or even something as ridiculous as an area fountain. Something to make a base level of white, ignorable noise that stops you from focusing on the small noises.

Many organizations pay headhunters tens of thousands of dollars for a hire. Each person costs $100K+ (often significantly more) fully loaded. Yet somehow the price of some tall cube walls is the issue? It's flawed math, people scrimping on the environment and then maximizing head count, getting less out of the latter by cheaping on the former.

What a strange claim.

As an aside, recently the Facebook app (at least on Android) embedded its own web browser, so instead of going to Chrome when you followed a web link, it would open in the Facebook app. You can reconfigure it to use the external browser, but the power of defaults mean many won't.

This seemingly small change has a big impact because if you open a link you want to share, the Facebook app restricts you to sharing it via your wall, versus the traditional Android app where you might share it over hangouts, Google+, email, etc.

Yet you spent your entire post claiming that the interface is objectively better. But people don't like it because it was change, it is "scientifically superior" (as if an interface is quantified only by the size of click targets), people just needed to learn it, people don't like their cheese being moved.

Coach your post in the disclaimer, but every other word you wrote was absolutely in conflict with that.

When people say that someone missed the point on HN, most of the time that means that they want you to read it the way they read it, and ignore those annoying bits that say something different.

Only this author not only undermines any disagreement with Windows 8 (just loss aversion), criticizes "old" interfaces (cars had 4 wheels in the 20s....give me my new style 3 wheel car), they specifically hold up its advantages on the desktop.

Not once do they mention the obvious solution -- that Microsoft should have gone separate directions on the desktop and the tablet -- but instead hold this as a cowardly backtrack.

See, we can both do that. Fun.

However in my case I'm supported by this very development, where Microsoft is essentially backtracking based upon enormous customer resistance and a backlash.

Windows 8 on the desktop was objectively terrible. The charm bar, the weird interactions, the gigantic click points that completely undermined the benefit of a highly precise mouse. It was a step backwards as Microsoft tried to force touch metaphors and designs on a mouse world. Now this user is complaining that they're forcing mouse metaphors on his tablet.

Which is an asinine, ignorant bit of comical sophistry. It's the sort of thing that people who are covering for some personal inadequacies project onto others (like the armchair critic who decries someone donating time at an animal shelter because...like...Africa or something. Anything to feel better about one's own inaction). It's especially humorous when we're talking about a site primarily used for sharing entertainment material.

On the other hand, it is well known that politicians pass unpopular legislation during major sport events — hoping that nobody will notice

Is this actually true? At all? Do you have any citation whatsoever to back this up? It sounds like manufactured nonsense.

Aside from all that, you lost all your moral high-ground in the last paragraph anyway.

Because I pointed out the reality about TPB? If you are offended by that, you need to land back on planet Earth, and engage in reality-based discussions.

As someone who enjoys football, I am offended by the comment. It presents a cheap, fictional dichotomy -- this notion that on one side are people who watch football (and apparently nothing else -- if you watch the Super Bowl, clearly that is the entirety of your being), and on the other are the freedom fighters and good people of the world.

My Facebook feed is full of similar people who, when they aren't posting pictures of drinking, building model airplanes, or doing other ultimately selfish acts of little consequence for the world, post trite motivational images that decry those who "care more" about a game than whatever pet cause they've decided is important...at least when berating people who might like something they don't. It's boorish and aggressive, and actually terribly offensive.

And the notion that the Pirate Bay is some sort of good cause is uproariously hilarious. Even putting aside the whole complex, nuanced discussion on piracy (no, people don't don't use the Pirate Bay to download Linux distros), The Pirate Bay is one of the most aggressively shitty sites on the internet. It is full of malware ads, diversions, pop-unders. The operators sell your security to make themselves money (and, apparently, a lot of it). Hurrah for their great benevolence.

There is absolutely nothing drawing anyone who doesn't want to use Go into using it. There are zero external forces or dependencies that are making you build solutions in Go.

So when you come telling a tall tale of your peril with Go, it just stinks. Do you understand? You can, from the outside looking in, have criticisms of the language, but when you try to add authority to your claims by manufacturing great experience, it sounds absurd.

The relevance of JavaScript -- and this really doesn't seem that difficult, though I think you're trying to be difficult -- is that, to reiterate, people have to bear it regardless of their feelings about it, so there are a lot of people who despise JavaScript but ply their trade in it daily. There is zero parallel with Go, where there is absolutely no reason for anyone to ever make use of it if it doesn't offer some significant advantage to their project.

You misunderstand my argument. If someone is begrudgingly complaining about JavaScript in the browser, well they have a legitimate gripe because they really have no option (beyond various compiles-to-javascript kludges). If those same people used nodejs, on the other hand, which many people do, they clearly found some compelling reason to do so. In the case of node it was that it made code very easily, and by default, asynchronous, instead of the classic .NET/PHP synchronous model. There was a benefit, and people gained from it.

Really?

Why are you using Go? Are you solving a real problem? Did you say "here is my itch, and I am using Go to scratch it?" I have never seen, in these discussions, people solving actual problems complaining about Go. Instead it's the code tourists who want to do some flippant, vaguely directed project and then add "Go Guru" on their resume to give credibility to their complaints.

If I want an answer now (if it's something that has an easy answer), and selfishly don't care about the flow of the other party, this may be true: You can prioritize a request by forcing it through synchronous voice mediums.

But even if we exclude that possible friction, it has been my experience that the belief that voice is more productive is often based upon superficial results (much as with meetings). People say some vague, uncertain things and both leave with a great feeling of accomplishment. Written communications, on the other hand, often requires more precision (if we wrote the way we spoke in such calls, the result would often be meaningless) -- you need to actually think about what you're asking, and give specifics. Not least because the medium demands it, but because this is a written, referenced, liable record, versus a call where each party can just vaguely claim miscommunication.

It's incredibly hard to study something like this, but my gut feeling (with the caveat that it's biased) is that the belief in the efficiency of voice communications is often based upon superficial results.

This is specious logic. People are not being told to use Go grudgingly because it is mandatory. It isn't a required component of some entrenched industry dictum. The only possible reason someone would choose Go is because, somehow, it is advantageous to their process. And we've seen an enormous number of success stories with Go recently -- all people choosing to use it for no external reason, but somehow it benefits their project. This is in contrast to, for instance, JavaScript (which debatably has its own merits) where if you want to script on the web client, that's your choice, love it or leave it. In the Go domain, there are countless alternatives.

I find it hard to even express clearly why Go feels so...natural and productive. But it does. And one of those reasons is that the language is so simple and, well, crude, that you don't stop and sit on questions of approach. Somehow it works.

If we need to stick with vehicle analogies, it's more like someone is using a dumptruck to move massive piles of Earth, but complaining that the steering isn't as light as their car.

And FWIW, when people talk about the lack of generics causing them great pain, usually they aren't making a solution, but instead are toying with the language. Doing the typical "make a library that solves all problems" sort of thing. When I am using Go it is almost always for a specific, practical requirement (as duct tape between processes, to orchestrate some high performance C code, etc), and it just...isn't a problem. It really isn't. Unless you're making library code it just isn't this issue it is held to be.

Analogies are almost always useless diversions, but this one is particularly ridiculous.

People are building real, working, successful solutions in Go with rather surprisingly regularity (which, if the comparison needs to be made, they don't seem to be doing with Rust). It is obviously working pretty well, and that "non-negotiable" point turned out to not be a showstopper.

A car without wheels? If we have to abuse analogies, more like a car with a manual transmission. People can have hysterics about how will they ever eat their burger while they drive, but somehow some people manage.

"JavaScript originally didn't have a built-in class system. Every popular framework built their own, and so did we."

I was not making a comment on any new development or change in direction, just that React (a tool I don't use) admitted to also jumping on the pretend-OOP thing.

I have yet to see an Angular project that doesn't qualify as tiny. For that purpose -- banging out some internal CRUDish app -- if it allows people to create working success, then it's a success. Instead people are busy arguing over the semantics of over-engineering a couple of text boxes, and that really is what leaves me boggling. Though of course, as is the nature of these things, there are over-dramatizing camps, and one month Angular is the greatest thing ever on HN, the next it's the demonstration of all that is wrong in the world. The reality, as always, is somewhere in between.

It wasn't that many years ago when people didn't even understand basic concepts like closures in JavaScript, or the power they bring. Now people are viciously arguing about the edges. It's all very surreal.

There is simply no way that you can say that you know Javascript and at the same time support Angular.

One of the most common features pushed by just about every framework (just saw it about React yesterday) is desperately, and leakily, trying to abstract Javascript into some sort of classic OOP language. Some of the most popular tools allow you to write in various compiled-to-JavaScript languages (TypeScript, CoffeeScript, GWT, etc). It's all very strange. But again, if JavaScript is treated just as a runtime, and if it works for a team, there is some measure of success.

Many of the replies thus far have quite rightly pointed out that the predominate contract/freeland/short term model actually puts even more power in the employer's hands, and is often used in an abusive, diminishing way. It is full-time employment made worse -- all of the problems and detriments, with fewer of the benefits.

There is an alternative model, but it is extremely hard to make a success. I build systems for financial services, and have a long, proven track record (one of the products I built half a decade ago, barely changed since, was just acquired by another company for big money). I decided to go solo, set up a corporation, and pitch my independent services for short term engagements. The premise is that it amplifies my own motivations, focuses my work, and intrinsically improves my rewards.

A surgeon ready to swoop in and remove the cancer -- focusing on my specialty and utilizing my somewhat unique set of talents -- leaving a well-documented, working, tested, proven solution for your organization to pick up and run with. This can be for load sharing, for capacity extensions, or because certain talents don't exist on the team. It allows me to specialize in a way that I couldn't do in one engagement, and I don't end up whiling my days away reading Reddit (which is the case for a significant percentage of full-time workers pretty much everywhere).

It is extremely difficult to get businesses to buy into this model. The first problem is the illusion of a "learning curve" -- if you have a learning curve in what you do (the classic "employees can't be productive for the first n months), you probably don't actually know what you're doing. I saw this in one firm where everyone was sure it couldn't work because their mystical financial calculations were so complex it would take months to understand them. Only they weren't actually complex whatsoever -- everyone was just blissfully in the dark about how to calculate simple things like IRR, so it seemed like some sort of unique, in house mystery meat.

A bit of a rant -- I could go on for pages -- but honestly most firms can't utilize the contract style employee because their own processes are so broken, their projects so tightly coupled and intertwined and undocumented, that they can't imagine how to separate something out.

[1] http://www.imdb.com/title/tt0787474/

There was a time a few years ago when you could ask what the best tech blogs where and there would quickly be thousands of posts. Now...most of those have been abandoned, and little has appeared in their place. Even among professional sites it's amazing how many technologies (for instance Intel's tablet chips) get almost no treatment at all, and astonishingly little actual effort is expended, so we just end up with some vapid, high-level commentary that is then blog spammed across autonomously created dupe sites.

It's just a wastelands. People stopped coming and people stopped being interested.

Technology blogs used to be fairly significant ventures. Now there are shockingly few that are still maintained, and even those (such as Coding Horror) detail dramatic declines in readership.

Every reality goes against your garbage post. Yet still you did it. Weird. HN gets stupider by the day.

[1] - http://www.thekitchn.com/how-to-cook-spaghetti-squash-in-the...