claudiusd

Most companies can't afford experienced people who will do a very good job and expect appropriate compensation for that work. If they could, then hiring these people would be a no-brainer.

>> Also, if companies were more open about the salary and compensation packages they will offer with a position, it might more effectively deter the unwanted "seniors" from even expressing interest.

I agree with you here. I would never personally reject someone with an impressive background without first communicating to them the "reality" of the position they're applying for.

>> Of course, there are extremes to the "too experienced" situation. If a person with a Ph.D in Biology and Astrophysics applies to a job at McDonald's, then perhaps something is off.

Ok, so where do you draw the line? At what point is it not OK to judge someone in this way?

Don't get me wrong - there is an ageism problem in the tech community. If we take these arguments at face value though and don't make an effort to understand why a rational, unbiased person might appear to discriminate, then cannot effectively address the problem.

Merely starting the interview process with someone who far exceeds the requirements for the role is a risk... my employees and I may waste our time interviewing this person just to find out their salary requirements are too high. I would say "too experienced" is a legitimate reason to reject someone from a role for this reason. This is especially true in the gaming industry, which is extremely competitive and has no shortage of young talent with low salary requirements that are appropriate for senior management.

The authors did a great job explaining the benefits of OCaml and why I as a developer should think about using the language. I actually want to play around with it now in a side project.

As a start-up manager though, I think the business case is strongly against them and don't believe there is any "competitive advantage" from using OCaml... in fact, I think the opposite. Here's why:

* There is not a strong community behind OCaml. You can't take advantage of the numerous libraries and references created by the community like you can with Ruby, Python, Javascript, Java, or any of the other mainstream languages. * OCaml is hard (and so are most functional programming languages). You will always need exceptionally talented developers to work on your code base and that will get expensive. * OCaml is not popular. You will have to pay an additional premium for OCaml developers due to the lack of experienced talent. * OCaml is a risk. If you're starting a consumer-oriented service, you need to prove there is a market for it. Will OCaml help you get to market faster? I don't know. Will Ruby-on-Rails? Yes. I'd pick RoR any day just to eliminate the risk of getting to market late.

While I don't necessarily agree with the end product and how it will be used, I say defense spending like this is ultimately good for the tech sector. It's funding innovation that wouldn't otherwise get funded and creates lots of attractive jobs in technology that will hopefully bring more people to the field.

We may not have even had the microwave oven today if it wasn't for defense spending on radar technology (http://en.wikipedia.org/wiki/Microwave_oven#Discovery).

Look no further than your customers for great 3rd-party accountability. If they love and use your product, they will pay you more money and recommend you to others. They should be the only thing that matters. In fact, by not having a board you have the luxury of only being accountable to them.

Are you installing this at work? What kind of trade secrets could you potentially leak? And how does it affect your corporate compliance requirements? If your email is subject to HIPAA regulation, then you may be leaking protected health information. That's pretty bad.

I, for one, rarely install plugins. I've written plugins for my own amusement that can do some very bad things, and it's just too easy. Think twice people.

I've read this same advice in one form or another many times. This is all well-known stuff and "clients" still aren't learning as far as I can tell. I don't think they'll ever learn because proper software engineering practice is counterintuitive and the attitude of management will not lend itself to these practices.

Instead of talking about the problems, I think we need to arm engineers with techniques for defending proper software engineering practices. Lean and Agile methodologies have helped considerably, but I think more work is needed to truly ease many of these frustrations. I'll let you know once I've figured it out...

Any normal business would respond to demand by its customers, but the telecoms have an oligopoly which they can leverage to increase revenues at their customers' expense. If the "fast lane" were allowed, Comcast would have a decent argument for not providing its customers the bandwidth they paid for to high-traffic sites: "we'd love to give you the bandwidth but the Googles and NetFlixes refused to pay for it". That position is totally back-asswards, is a result of their oligopoly, and is not in the best interest of consumers.

Comcast will continue to do just fine without forcing companies to pay for the "fast lane".

His argument was that he could not find appropriate legal representation because of the gag order, and that the DOJ would not cooperate in kind with his legal team once assembled. Do you think his delays were too long given these constraints and the fact that he has a company to run?

If I have sympathy for Levison it's because he was intimidated into laying aside his moral beliefs. It could happen to any of us.

Here's my testing strategy (YMMV):

1. Feature tests for the "happy path" - make sure the system requirements work as described from the user's perspective with full integration. I usually just write a couple.

2. Integration tests for high-level system components - these are more functional in nature but capture all boundary cases for the components that sit closest to the user. These are my saving grace when refactoring.

3. Unit tests for methods and other low-level components - these primarily serve my "integration tests" by factoring out the functionality of low-level components and allowing me to focus on their integration. Here I'll use mocking if it's convenient, and when refactoring these usually get re-written.

Notice that this strategy says nothing about TDD, but I would argue that following the principles of TDD makes this strategy strictly work better.

While your TDD methodology may be flawed, this focus on end-user value has proved itself time and time again. Discussions like this one only play into DHH's flawed logic and do the programming public a disservice by pretending like there's some argument about whether TDD is effective or not.

TDD works great if you do it right. A TDD methodology may or may not work depending on the circumstance. Choose the methodology that's most appropriate for the situation and you will have success.

Sam Altman and others need to put their money where their mouths are - if you want bigger option pools for employees then remove this clause from your term sheets and encourage other investors to do the same. If you think that more employee equity is good for business, then give us more flexibility with the option pool and share the dilution with us. Don't blame us when the real change starts with you.

Now this isn't to say that doctors are bad people who want to make you sick... on the contrary, most of the doctors I know are more passionate about helping people than making money. They are, however, subject to whims of the hospital they work for, which I can almost guarantee is more interested in making a buck than keeping you healthy. This is true of all large companies though, and as Clayton Christensen has taught us, this sort of marginal thinking usually leads to disruptive innovation by a start-up.

<shameless_plug> Want to disrupt health care? Omada Health is hiring! http://omadahealth.com/jobs </shameless_plug>

Preventive care programs like the one at HQP are proving that preventive care is effective, but sending a nurse to your home regularly is expensive and I'd question the ROI from doing so, absent some focus on a particular disease. With a solid ROI and some good hard evidence, HQP shouldn't have to rely on CMS to keep them afloat... with some work they would be able to sell their program to payers.

HQP also isn't addressing the systemic issues I mentioned above, so what's especially frustrating about the article is that they bash on ACOs, which is one of the first attempts by CMS to actually align incentives and mend those issues. And frankly, those changes aren't going to be good for hospitals... I'm sure a lot will go out of business as people get healthier and don't need them. This piece of the article in particular makes me question HQP's motives.

Deep learning, on the other hand, is about using layers of classifiers to progressively recognize higher-order concepts. In computer vision, for example, the first layer of classifiers may be recognizing things like edges, blocks of color, and other simple concepts, while progressive things may be recognizing things like "arm", "desk", or "cat" from the lower-order concepts.

There's a book I read a while ago that was super-interesting and digs in to how one researcher leveraged knowledge about how the human brain works to develop one of these deep learning methods: "On Intelligence" by Jeff Hawkins (http://www.amazon.com/On-Intelligence-Jeff-Hawkins/dp/B000GQ...)

The book describes efficient, sustainable ways achieve changes in your body, the premise being to make changes with the smallest amount of work possible. I put on 10 lbs of muscle in 2 months following its weight gain advice. My girlfriend tried the slow-carb diet and saw no effect, but I have heard that working for a few people. It's an interesting read nonetheless and will change your perspective on diet and exercise.

I think the OP did exactly that, realizing that Rails is the better long-term solution for their engineering activity. I wouldn't say they "moved" from NodeJS to RoR, because that implies that that they chose a new technology to solve the same problem - they didn't... they chose NodeJS for prototyping and RoR for production.

I had the same experience transitioning from a prototype RoR app to a production app also written in RoR - I still did significant rewriting to improve testability/test coverage and make it more RESTful, but I didn't need to switch frameworks to do that.

Even if compensation did scale linearly with productivity, two programmers with productivity X are still worse than one programmer with productivity 2X since communication costs grow as the team size grows.

I wouldn't be a prudent businessman if I didn't fight relentlessly for the best developers...

A third party that works with many companies builds up a vocabulary of techniques, data sets, and experience that allow them to enter a new environment and be 10 times as effective as any internal team of analysts.

Don't know if anyone has heard of Lattice Engines (http://www.lattice-engines.com/) but they are today integrating external data with internal cross-functional data to extract insights that are saving large companies (that I'm sure already have teams of very talented analysts) millions of dollars.

The only thing that's really going to come through on a resume is (a), and I might be able to glean some of (b) and (c) from your cover-letter. It's rare enough to see full-stack RoR programmers on the job hunt though, so (a) alone is enough to get a call from me. Your resume almost doesn't matter, as long as it doesn't violate (c).

For me at least, just put together a generic resume and write a frank, friendly email/cover-letter. Even though I'll probably call you regardless of the cover-letter, a good one may give me enough confidence to skip right to on on-site (or coffee).

I hope this gets built into something tangible.