andrest

This is my personal opinion of what could be the solution.

1) Ebooks will be kept on publishers' servers

2) A standard which all ebook readers can read will be adapted (during the crossover period publishers can keep ebooks in multiple formats)

This could be it. Now the retail sellers can sell the book for a lower cost. Every time a purchase is made, let's say a key is generated by the retailer (e.g. amazon) that will allow you to download the book from the publisher's (e.g. penguin) server.

or

3) An umbrella organization for all the publishers is created. The organization manages the ebook standard and hosts the ebooks themselves. Publishers pay money to the organization per download basis (to cover the hosting cost) + a yearly membership fee (to cover the management costs)

4) The umbrella organization can actually sell the ebooks itself (maybe even use advertising to cancel out the yearly membership fee) and/or resell them to major retailers.

Everybody could sell their book to the umbrella organization, pay for the sharing costs and make their book available around the world.

This would allow easier publishing, cut out the 30-40% retailer margin and make the books more available.

The current model has the retailers to closely tied to the whole system. Without them, nothing works, so they are the price-makers. Furthermore, retailers actually make the ereaders so they get to subsidize the reader and spread the cost on the books, this unfortunately provides disincentives to support other platforms. Therefore we need to centralize the distribution system.

The first steps would be creating an open standard that every retailer has to support, so we wouldn't have to be tied to their devices.

I don't want to discredit anybody, but we (well, I) have no clue what was the app like. From the sound of it, it could have been a text box filled with names and addresses on a white background, and this can be achieved by dragging and dropping in the Interface Builder.

Even if that is the case, there still is a point. Developing for iOS (or OS X for that sake) has been made easy. Just fire up Xcode and start typing. Contrary to Android platform a year or a two ago (last time when I checked it out), many more clicks and bits were needed before actual code could be written.

This is the point the article seems to make. The difference between a good candidate and an excellent one is huge. Like it was mentioned before, a good programmer can do in a day what a team of mediocre programmers can do in a week.

You say that companies should train mediocre programmers to be excellent programmers. This is not as straight-forward as it sounds, (a) the mediocre programmers might have already reached the limit of their capability (i.e no matter how much time they'll spend learning, the improvements will only be marginal), (b) it could take long time and as we all know, time is money.

I like to think of it as a simple exponential graph. Programming Skill on X-axis vs Time Spent Learning on Y-axis. In the beginning the progress will be fast for everybody, but at some point the progress will slow down indefinitely (i.e you've reached your maximum capacity). The point at which this will happen varies from person to person and there is unfortunately no way you can determine where that is. The only hint of the maximum capacity you can get is to compare how long the guy has been programming for and how skilled he is at given time.

As a result, it is more cost-effective to search for very good candidates for longer than to take handful on mediocre ones, take the risks, and train them.

It should be noted that a programming is without exceptions self-thought. Therefore there is no need for training per se, you will just need to take your time and do it yourself, as programming can not be taught, it can only be learned.