jasonwocky

Just because an industry supports multiple players doesn't make it a commodity. Commoditization is what happens when the product is widely seen as "good enough" that consumers don't value most of the industry's innovation anymore.

If Uber and Lyft run out of profitable ideas, and only have "reduce costs" left as a means to more profits, THEN it's a commodity.

I read the parent post three times. I didn't see any generalizations in its text at all.

> The next time I go to a client who wants a scalable international web application that needs... well, the same stuff that's in pretty much every other scalable international web application. Why shouldn't I run it up on a framework that provides all that and save myself (and the client) six months of building, glue code, integration, and all the other testing?

Sounds like you're a consultant / freelancer (like me). For folks in our position, frameworks are win-win. We can become specialists in them, get things implemented quickly and more cheaply than an alternative, and satisfy our clients.

Of course, also having been on the other side, I know that the pain of frameworks comes later, in long-term maintenance. This is because the frameworks more or less "define reality" for the applications that are hosted within them. And when an applications business needs start to reach beyond what the framework is capable of making easy, then the development tradeoffs start to get nasty.

"No matter which you choose, whether to use a framework or not to use a framework, you are destined to end up regretting your decision." - A smart ex-colleague of mine.

> Meh. I've had nightmares from a movie once in my life.

Some of us weren't so lucky.

Depends on the use case. For automated testing, if I'm developing service A, then locally I'd usually I'd want to stub B & C with something like Mountebank (http://www.mbtest.org/) (though I've never used it to do a post-back as you describe...not sure if it supports that out of the box).

If I just wanted to poke around a running system to see how things interact manually, yeah I'd run everything locally. Probably using Docker images for each dependency service and Vagrant to manage the suite of those images, to preserve my sanity.

> FWIW, I've found that building a robust and deep "API Gateway" is the key to making SOA/Microservices work. Otherwise, you end up with duplication and latency.

The risk here is that the API gateway gets too big, and its gravity starts attracting more and more functionality, until you have a brand new monolithic application.

I like the gateway approach, but generally I want to have multiple gateways, each serving as a "Microservice Facade" for a particular application or small set of applications. New applications get new Facades.

There ends up being some duplication across the facades, but basically I think "so be it". As long as the core services are factored out and own their business logic, I don't mind if the consuming applications have some duplication.

Decisions based on average (a/k/a "mean") salaries, however, are only relying on a small part of the picture. Personally I'd like to see standard deviations accounted for in here. I have the feeling that it is easier to make 1.5x to 2x these "averages" in some cities than in others, especially for people with experience.

> Check out the size of the dogs being walked near Central Park. Where do these people live?!

True, it's NYC is an expensive place to try and mix in all of the creature comforts of suburban life. The big dog, the fancy car, lots of square footage of living space. And to young kids, just out of college, who've never known anything other than suburban living before moving to NYC, these may seem like "baseline necessities" that you have to sacrifice in order to live here.

Once you accept that the baselines of city living are different from the baselines of suburban life, things get a lot simpler (and cheaper).

If there are developers unable to "enjoy" living in NYC at a $125-$140k base salary, then that's on them. Plenty of single people love life here on salaries of $45-60k, and are even able to save money.

> Finance has distorted the baseline of what it means to be successful in NYC.

This is obviously only if you try to keep up with them and the other Joneses. There are too many people here. Nobody notices if you don't have a dog, or a car, or a big apartment.

I own a place in a nice neighborhood in Brooklyn, don't want for much, and provide for my family all on a way less than Google/Finance salary. I think that's a perfectly fine definition of success.

> This just makes it that much more likely that institutions will hesitate before offering free access to materials online.

No, it doesn't "just" do that.

> "The results are remarkably consistent across all sectors and all forms of privatisation and outsourcing: there is no empirical evidence that the private sector is intrinsically more efficient"

Exactly this. I've spent years in both sectors. People suck at running things, not governments.

This sounds reasonable, though if you hire the Best-Programmer-Available regardless of the presence of a specific technical skill, I'd be surprised if they really take a year to get firing on all cylinders. Maybe a month or two at most would be what I would expect in the sorts of places I've worked.

Sure, some places (especially in startup land) can't even afford to wait even a month, but that doesn't make the dynamic any less of an antipattern. Instead it's just one of the painful tradeoffs people make while they need to manage their runway extra closely.

> When interviewing for a specific role, you have to think very hard about what it is you are trying to do - and don't just fall back on generic cut and paste questions.

I think this is true, but it raises a question about "hiring for a specific role."

I find that when companies do this, they're in a reactive mode. Which of course is going to happen from time to time, but the reason memes like the OP get born is because many companies are habitually reactive when it comes to hiring.

I don't follow a lot of sports, but I follow NFL football. Each year, the teams get to "draft" (a/k/a hire) incoming players from college. When it comes to the NFL draft, there are two prevailing philosophies: "Draft for Need" and "Draft Best Player Available". Without question, teams that stick to more of a BPA approach tend to have longer term success. Teams that draft for need sometimes get that player that helps them get over the hump and win a championship, but more often they're trading away long-term greatness for some short-term pain relief.

I think hiring for software teams (and just about anything where there is a lot of variance in depth and breadth of skill) follows the same pattern. Hiring for a specific role is an antipattern (albeit sometimes a necessary one). If you have a very specific role to fill, perhaps a freelancer or a consultant might be a better fit for easing the short-term pain. Then you let them go as soon as they're no longer needed.

Hah! Shows what you know. I've got a 500 on my laptop, too ;)

I don't think you read danr's logic correctly, but I could be wrong.

I interpreted it as "The reason women want to be treated differently [from how they are NOW] is that the world is a sexist place." Not, "The reason women want to be treated differently [from MEN] is that the world is a sexist place."

An Amiga cast as the wrong thing to buy? Heaven forbid.

What's it matter how he'd fit in most Valley startups today? He was who he needed to be for his time.

Not to mention, what happens to "most" Valley startups, anyways?

Sure, I just thought that the parent was only presenting one side of the math.

> For example: the pyramids, cannot be build by one man, but wouldn't have existed if it wasn't for central leadership.

Because they were valueless items to the thousands of people that it took to slave and die creating them? Yes, those things probably wouldn't have been erected if it were a democratic society at the time. I don't see how that's a bad thing.

The Pyramids are in fact a perfect example of the perils of the "strong leader" model of leadership. At the time, they were a fantastic waste of their society's resources.

Divisiveness will, in fact, kill a team. We're on the same page about that. However, teams throughout history and software development that have had "strong leaders" have plenty of track record of being internally divided. Focusing on "Steve Jobs" is a huge example of survivor bias. Nobody hears about the "strongly led" teams that don't make it big, or anywhere.

Democracy doesn't "divide" teams. It gives people a voice to work through their already present divisions. However, the key word there is work. Simply saying you're a democracy without having patience to go through the work won't get you anywhere. Neither will putting together a team filled with people with irreconcilable differences.

Well, to be fair, there's also a chance of getting more value.

And so what then? You use it because it has traction and because other professionals use it? Or because, as many professionals find, it's the most capable tool for the job at ahnd?

It's an interface for professionals. It takes awhile to learn, but when you do, you're rewarded with quite efficient access to the tools given how much Photoshop is capable of.

Not to discount the value added in this case, but remember that the report is possibly biased in the same way that many "We rewrote it and now its 10x as awesome as it was before!" reports are. Rewrites almost always tend to result in higher quality code, regardless of what the rewrite is to or from.

I don't really follow many of the author's objections. I think he or she left out a lot of reasoning.

"This code reminds me of a simple server-side scripting language such as JSP or ASP that’s used to fill HTML templates with database content. These languages have their place in the web development stack — but on the server, not in the browser."

Says who? What's the rationale for where a language belongs?

"Although templating is the correct solution, doing it in the browser is fundamentally wrong. The cost of application maintenance should not be offloaded onto all their users’s browsers (we’re talking millions of hits per month here) — especially not the mobile ones. This job belongs on the server."

Again, based on what?

"My point is that I expected far more front-enders to embrace Angular. I have the feeling their number is surprisingly low — see also the problems my clients had with finding good front-end Angular consultants. "

More stuff based on feeling rather than empirical evidence. And clients have trouble finding good front-end developers these days no matter what the technology is.

"A more important reason may be pushback from the JavaScript community. Angular has evoked some serious criticism."

Find me a framework that hasn't evoked serious criticism from some corner of the Internet.

Look, I'm no fan of Angular. In fact I've never written a thing in it. It doesn't really fit my style of front-end development (and I'm a Java programmer!). I'm more of a libraries-over-frameworks guy. But this article is not very well-reasoned.

> I believe judges have compelled people to surrender decryption keys.

Doesn't seem to be a widespread practice. As far as I can see, the only Federal Appeals court case to have confronted the issue ruled against compelling a suspect to decrypt their own laptop.

http://en.wikipedia.org/wiki/Fifth_Amendment_to_the_United_S...

> It is in concept no different to having a magical safe which can't be opened by any method except the owner's key. The court does have the authority to compel you to surrender that key

It is different, but only because you have the explicit right to remain silent. The US government can legally compel you to do lots of things, but not talk (or otherwise communicate information that's potentially against your interest...generally).

Absolutely. I have a certain level of friendliness to random strangers. But customers of any kind? I sincerely care about their experience of dealing with me and my company. So if I come off as more friendly when dealing with them, I'd say that's genuine.

Same here. I work from home and often enough have a 2-year old wander into my office. Talk about random interruptions. But I don't notice skipping more than a beat.

Maybe it's because I don't tend to work with really bad codebases that force me to keep huge mental models in my head while I'm making changes. Or perhaps I'm fast at getting ideas onto paper so that the stuff I need to keep in memory remains small. Either way, the dynamic the article describes is not an absolute, universal thing. There are environmental / behavioral factors at work besides "Developer, Interrupted."

How in the world do you know that the friendliness is fake?

It might come under fair use, but can this site afford to make that case?

It does seem like an awful lot of one show to be using. They'd probably be better off if they pulled this mix of concepts from multiple sources. There's really no educational reason this site needs to be Seinfeld only. It seems like they're trading off the original content perhaps a little more than is fair.

A colleague of mine has often said, "Regardless of whether you choose to use a framework or not, eventually you'll be regretting your decision."