It is not just the cost in physical printing (which has a significant labor component as well). You need a truck driver to physically move the books from the print facility to the store (which also costs fuel and the use of the truck). You have to pay for the physical space of the book store. You need someone to stock the shelves, someone to physically check out the customer. You have loss due to stolen books, loss due to books damaged too much on the shelves to sell. Unsold copies. A distribution network. And everyone needs to make their profit. When you buy a physical book off the shelf at a store, how much of the money you paid do you think the publisher actually nets on it? If you think it's more than 10 cents on the dollar, you don't know anything about commerce.
The just-in-time printing is mostly used for delivery of back-catalog titles, and mostly to Amazon and B&N, rather than to bookstores (because special orders are relatively rare). The small number of actual POD printers are typically located in the same city as major online booksellers' distribution centers, and they bulk deliver books to them by the truckload, so the transportation cost is so cheap that it gets lost in the noise. Unsold copies are usually limited to at most one or two copies by Amazon unless the book is already selling in bulk, so again, that gets lost in the noise, at least for moderately high-sales titles.
And so on. As for how much the publisher nets, that 10% estimate is probably in the ballpark for POD books. For books printed in larger quantities, of course, the reduced printing cost increases the publisher share.
If anything, the cost to edit a manuscript into an epub file is a negligible part of the cost of the finished product.
If all you do is export it from InDesign, then yes, it's a negligible part of the cost, but the formatting is also likely to be mediocre. If done well, it's a decent chunk of change, though still not huge.:-)
This. I mean, you should be able to invest that in the stock market and average at least $8 million per year, permanently, allowing enough extra money to compensate for inflation. That's enough for a team of at least 20 engineers plus renting space for them to work, equipment costs, health insurance, etc. So barring the website being insanely complex, you should literally be able to run it on that without even touching the principal, even without bringing in a penny of revenue. What the heck are these people doing with all that money?
True, though there are thresholds below which expansion makes no sense. Say I have a bookstore. I have ten employees and overlap them to keep the store open during reasonable business hours.
Adding five more employees is unlikely to provide any additional ROI unless I can claim to be the only 24-hour bookstore in the region, and only then if there's actually a group of people who wake up at three in the morning, think to themselves, "I need to read something to help me get to sleep", then put on their clothes, drive to a bookstore, buy a book, drive home, take off their clothes, curl up, and read the book.
Adding ten more employees would be enough to open up a second bookstore in a nearby town. Assuming there are enough customers to keep both businesses alive, then yes, given available capital, there's more work to be done.
In big businesses, the interesting thresholds tend to be even bigger and more dependent on things other than available capital. You have a lot of opportunities for bringing in a new person in various parts of the company as workload increases over time, of course, but the really interesting, rapid growth happens when the company decides that they want to go after a new market segment, which means they have to ramp up their staff fairly dramatically. That requires more than just capital; it requires big ideas and a reasonable probability of making enough money to make it worth the effort.
That's why even though Apple's U.S. profits alone could cover the cost of hiring on the order of 700,000 full-time software engineers, they have on the order of one percent of that number. So probably only about one or two percent of their revenue goes into staffing (ignoring C*O and VP bonuses). Even if you double or triple that number to cover the cost of renting or building office spaces, assuming you ignore the occasional massively over-budget project like the spaceship, total employee costs still probably fall down in the single-digit range percentage-wise. In other words, if they needed more people, they would easily be able to afford many more people, so bringing more money into the U.S. won't change their hiring at all. This tends to be true for all sufficiently large businesses. In other words, there's a threshold of capitalization beyond which adding more money won't result in more jobs.
The bottom line is that if you want to increase the number of available jobs, the best way is to raise taxes on big businesses and use that to offset a reduction in taxes on smaller businesses. Those smaller businesses still have room to grow, and every dollar that they pay in taxes is a dollar that they can't pay their employees; for bigger businesses, every dollar they pay in taxes is just a dollar that they can't pay their shareholders, which although certainly beneficial, does not create jobs.
Of course, a big part of the problem is that in the 1970s, California enacted a property tax scheme that is perfectly designed to limit homeowners' ability to move. By making property taxes be based solely on the purchase price instead of on the actual value of the home, people would pay dramatically more in property taxes every year if they sell one house and buy a second one even if they break even on the deal.
Prop 13 drastically skews the proportion of renters to owners by forcing people to rent out their old place so they can afford the rent on a new place instead of selling and buying. It also discourages new people from entering the market by making them pay the bulk of the cost of goods and services while folks who have been there for a few years pay proportionally less. The result is one of the most screwed up real estate markets anywhere in the world.
(BTW, Sunnyvale mobile home parks are only ~$1k per month and only maybe $50–75k to buy an old house and move it out of the way, plus the cost of whatever you move in. That extra $1,500 per month + $75k is the Google tax you pay for living five minutes closer to work.)
Another part of the problem is that the Bay Area lacks a proper region-wide planning commission with authority to regulate zoning across the various cities. So you have places like Menlo Park, where the only housing is private estates for the rich C*Os, with lots of businesses out near the shore where land is cheap (because it smells of rotting fish), and you have Gilroy and Morgan Hill that are almost entirely housing, with few businesses.
IMO, what we really need is to have some government entity that slowly converts business-use land in the South Bay to residential use and says "No" whenever big companies say that they want to expand their presence in the South Bay, encouraging them to build satellite offices farther south instead. And offer tax incentives to locate new businesses outside the SF/Peninsula/South Bay area. Adding more businesses farther south would increase the reverse commute traffic and reduce the primary commute proportionally, and opening up more farmland to development would go a long way towards reducing the cost of housing as well.
Unfortunately, that's unlikely to happen unless there's a single management agency that has some authority across all the different administrative districts. Right now, each city wants to get its share of the tax revenue from new businesses, and they mostly don't care about the clustering problems that result from it. Nobody is taking a bird's eye view of the problem, or if they are, they don't have the authority to do anything about it.
Greece, as best I understand it, is screwed up because the government paid for it without actually having the revenue to pay for it. That makes them far more like the modern borrow-and-spend Republicans than the tax-and-spend progressives. When, over a five-year period, a country's tax revenue increases by 31% and government spending increases by 87%, you're going to have a serious increase in your national debt. The United states solves this by devaluing its currency. Unfortunately, the Greeks are part of the Eurozone, and thus are limited in how much currency they can print each year, which means they can't just print more money to avoid becoming crippled by their national debt.
Of course, to make matters worse, their national debt is so huge relative to their GDP that it probably wouldn't help even if they could print money.
Even in relatively good times, Greece was borrowing over 8% of their GDP every year. That's simply unsustainable. As a result, while U.S. states have debts that are on the order of a third to half their GDP, Greece has debt that is on the order of double their GDP. Imagine if the state of California took on a third of the national debt by itself, and you're in the ballpark. Nobody in the U.S. government—even the most socialist progressives who advocate a base income—are crazy enough to borrow that kind of money, I don't think.
But a bigger problem is not the amount of spending, but rather the types of spending that the Greek government has done. Instead of building infrastructure that would actually benefit them financially (e.g. factories), they spent frivolously on things like a giant sports venue for the 2004 Olympics that didn't cover its costs and that they couldn't afford to actually maintain afterwards. Their social security system is or was broken, with such fascinating flaws as paying out pensions to single female children of dead retirees. The state airline was a giant money pit for many years. And their military spending at the start of the crisis bordered on insanity (sound Republican enough for you?) at something like 7% of their GDP—proportionally more than the U.S. spent while fighting two wars.
No, the Greek government is a prime example of what happens when Reagan-Republican-style borrow-and-spend budgets get out of control and are not tempered by true fiscal conservatives insisting on balanced budgets and rainy day funds and so on. It is the polar opposite of progressive ways of handling budgeting (which, if they got out of control, would result in a tax rate that's so high that the people themselves would demand cuts in spending).
Here's what happened in about 150 years under "conservative" US government policies:
Grew from small, isolated, breakaway country to the richest, most powerful country on the planet, with the highest standard of living.
Here's what happened under "liberal" government policies:
Declared our independence from Great Britain in the first place.
You have the right to be on Slashdot and argue about which ideology is better because of liberal policies.
Along the way, freed slaves and saw life expectancy become the highest in the world.
Lincoln was most assuredly not conservative. Republican, yes. Conservative, no. His policies resembled those of modern progressives more than modern conservatives, though even that is something of a stretch, because unlike 99% of modern politicians, Lincoln was actually a respectable statesman.
Contrast to what happened in "progressive"/socialist/liberal nations such as Venezuela, Greece, and the Soviet Union.
Progressive != socialist != liberal.
Additionally, Greece's problems stemmed from government overspending without enough taxation to cover the expenses. That's more similar to what Republicans do today than Democrats. And both Venezuela and Russia had problems where a few people at the top of the party essentially lived in luxury while the poor starved, which makes it more like a caste system than true socialism.
Besides, essentially zero modern progressives view socialism as the be-all and end-all of public policy, but rather as a useful tool to use in limited ways for the public good. That's radically different from a country that attempts to use pure socialism as its sole policy (which is exactly as foolish as using pure capitalism as the sole public policy).
Legally, it's a grey area. If your employment contract has morality clauses, for example, you can be punished for things done outside of work. However, usually that is limited to situations where your contract explicitly states it, which usually happens when working for religious institutions (or, occasionally, schools). You can also be fired for actions that reflect badly on your company, but that assumes that A. people know the author works for that company, and B. they have reason to somehow connect the two. And of course, in at-will states, your employment can be potentially terminated for any reason, though in many, the implied covenant of good faith might give the author grounds to argue that this was without cause, done out of malice arising out of personal embarrassment on the part of the management team.
The bottom line would be that the author should contact a lawyer who regularly deals with employment law in that part of the country, because whether he has a case or not is highly dependent on where the author is located, and I'm pretty sure it won't be open-and-shut no matter where the author lives. However, the fact that the author has not revealed where he works does open the opportunity for the lawyer to point out that bringing this to court will cast their company in a very bad light publicly, whereas an out-of-court settlement for... say ten years' salary will not. Depending on how terrified the company is, such (entirely legal) blackmail might actually be more effective than bringing a suit.
With that said, there's a magic point beyond which developers start to leave the platform and less software gets developed for the platform.
So they still have to care about developers enough to stay on the right side of that tipping point.
In my experience, what makes it chaotic is the vast expanse of code that you didn't write personally. I've seen big chunks of functionality have to be completely rewritten because even major frameworks from major companies like Apple sometimes have bugs that are showstoppers when used in some way that the original author didn't expect. Most people normally assume that external dependencies already work when estimating, because after all, those are major frameworks written by major companies with testing resources.
Now extend that to code written by random engineers with limited testing resources. Normally, you assume that your internal code works, because after all, people are using it every day. But what happens when there's an edge case you didn't notice? If it isn't a crash, a bug in a suitably complex app often isn't easy to track down, and even when it is a crash, it might be some subtle multithreading race condition that can be utter misery to debug. And the larger the app, the more opportunities for untested code paths to suddenly find themselves on the hot path. This is why estimating is hard; you aren't just estimating how long it will take to get your code working; you're also estimating how long it will take you to fix everybody else's mess.
One prominent example is minimum wage regulations. While the intent behind these may have been good, what they've ended up becoming are huge burdens to businesses that are already on the brink. It's not economically viable for a business to pay somebody far more than the value they're providing. What is the end result? Fewer jobs, and a lot more focus on automating away low-end jobs. This actually leaves people worse off than they were before the minimum wage regulations were put into place!
That's a very naïve view of reality. For every business that's on the brink, there are hundreds that are doing well, and many that are turning record profits. A business that cannot afford to pay its employees a living wage is almost certainly doomed anyway, so allowing it to pay a less than a living wage is just delaying the inevitable slightly. The business will fail. Let it fail.
Keeping a business on life support by letting it pay a subminimum wage doesn't help anyone in the long term, and doesn't help very many people even in the short term. But allowing businesses to pay a subminimum wage does hurt people who work for all those other companies that actually are profitable, because given the opportunity to pay their employees less, they will do so.
More to the point, if that is the only business providing jobs in a particular community, then that community is doomed. Keeping the business alive a little longer by depressing wages just encourages people to stay in the doomed community and make less and less money, thus making them less and less able to afford to move to a community that isn't doomed. So continuing to pay those employees a wage actually ends up hurting those employees more than it helps, at least in the aggregate, though the individual employees might not believe it at the time.
I don't think that's true at all. Most of the pro-life voters I've known are people who genuinely care about protecting the unborn. Most of the pro-life politicians at least appear to be using the abortion issue as a means to get elected (though I suppose it is also possible that they're genuine but clueless). The number of pro-life folks who are actually misogynists is probably fairly small, though I'm sure that they do exist.
When the chip returns, we have to test it and make sure it is correct before we make any last minute changes. So there is a 72 hour bring-up period, most of us work 18 hour shifts and the campus is open around the clock with three meals served a day.
When you're talking about a short-term crunch period, sometimes those really are unavoidable, because of events that could not have been predicted ahead of time. When that happens, what matters is that the period be A. short, B. bounded, and C. rewarded with extra vacation to balance out the crunch. If an employer does that, it isn't a big deal. When an employer drives people to work 18 hours a day all year around, though, that's a much bigger deal.
That said, to some degree, what you're describing is still a failure of management. The final deadline might not be movable, but the milestones on the way to that deadline are movable, and the number of employees you throw at the problem is also adjustable. There are two ways to trivially fix the problem in your case:
Move the deadline for the design earlier. This approach will initially mean slightly longer hours during the entire project, but over the long term, will make it worth hiring one or two extra employees to reduce the workload. By doing that, you'll have an entire week or even two weeks at the end of the process for the bring-up period instead of 72 hours.
Hire contractors to offload most of the testing during surge periods. I guarantee you can find people who will do short-term contracts for a week if you throw the right amount of money in their direction, and I guarantee there are plenty of other companies that need testers only part-time. Work with those other companies and build up a contractor talent pool. Spend two days preparing for the tests, then three days doing the tests. Make a larger quantity of engineering test samples so that you can parallelize the tests better, and use three times as many people during that week so that everybody works sane hours.
This isn't rocket science. Either approach above would make those crunches completely unnecessary, and the combination would do so in a way that isn't even particularly painful for the company or the employees. However, both approaches require management to A. acknowledge that there's a problem, and B. care enough to fix it.
He wanted the growth, the stock options... and he wasn't cut-out for the demands:
Yes and no. Most startups have the opportunities for growth, stock options that could become valuable, etc., though you always have a decent chance of not getting anything from them other than more work. But there's definitely a point beyond which that extra work qualifies as worker abuse. This is why we need stronger laws on employee work hours.
Don't get me wrong; I'm okay with people hiring "exempt employees" with the understanding that their work hours will vary throughout the year, depending on what is happening. Where that scheme goes off the rails is when that turns into an expectation that you'll work 50+ hours every week—something that is fundamentally unsafe from a psychological perspective, causing serious harm to workers when done over a prolonged period. And from what I've read, Uber is one of "those companies".
Make no mistake, that culture is entirely the fault of Uber's management. Young people tend to think they're invincible, so without managers telling them to do otherwise, they will work themselves into the ground—sometimes literally. They think that by working ridiculous hours, they'll get ahead of their coworkers, and when enough people do that, others start to believe that long hours are required; thus, a work culture forms around that expectation.
What those young people don't realize is that those longer hours invariably lead to bad decision-making and lower quality output. Statistically, for every hour above about thirty hours, productivity falls off, and by about 50 hours or so, productivity actually goes negative; for every hour worked beyond that limit, you end up doing more than an hour of extra work to fix the additional screw-ups caused by the hour of extra work. For this reason, it is crucial for every tech business to have competent managers who strongly encourage employees to maintain a healthy work-life balance. Managers who do not do this—managers who prioritize short-term gains over worker health—invariably lead to worker burnout, long-term low productivity, and yes, suicides.
Unfortunately, between Uber and video game companies, it is pretty clear that self-regulation by industry isn't working, and that government needs to step in. Exempt shouldn't mean "we own your life". It should mean "40 hours average", i.e. the same as non-exempt workers, but allowing for seasonal variation. It should be illegal for exempt workers to spend more than an average of 40 hours per week spread across a one-year period. Huge fines are quite literally the only thing that companies like Uber will understand.
No, actually it's the solution to the abortion false dichotomy. And this isn't by any means the first story on the subject. A team in Japan did early animal testing in an artificial womb at least a decade back. I know this because I remember having a conversation about funding the development of this technology as a way for anti-abortion folks to put their money where their mouths are while on a church choir trip in 2008.
The fact of the matter is that abortion is worse than a wedge issue. It's a false dichotomy. Why would anyone in their right minds not want both a right to life for the fetus and a right to choose for the mother? The nature of birth involves trading the rights of one person for those of another, and that's the only thing that makes the abortion issue challenging for people to navigate. The mere existence of artificial womb technology is a game-changer.
If Republicans were actually serious about ending abortion, they would have jumped on this a decade back, and would have insisted on pouring funding into making this technology viable. We'd see research dollars being poured into that instead of into missile shields and random weapons research, and this technology would be fully viable by now, because with enough people working on it, the advances would happen faster. But they haven't done this, because they would lose most of their seats if abortion actually became illegal in a way that wouldn't get undone in a future power shift.
A truly intelligent, competent candidate for office, then, should be pointing this out, and should be running on a campaign of making artificial wombs available soon, and then making abortion illegal, requiring patients to instead get outpatient transfer surgery to move the fetus to an artificial womb. And the government should massively subsidize the transfer and pay for the incubation in cases where the woman gives up a fetus for adoption in utero so that no one chooses a back alley abortion over saving a life. And the government should require insurance companies to cover the transfer and incubation in cases where the life of the mother or fetus would be in jeopardy if a pregnancy continued, so that women with high-risk pregnancies can keep their kids without risking their own lives and the lives of their kids.
The mind-boggling thing about this, at least in my mind, is that our politicians still haven't thought of it. This should have been obvious to any competent leader at least ten years ago when the first study came out. Arguably, it should have been obvious earlier than that. I've been advocating this as a solution to the abortion debate for so long that I can no longer even remember when I started advocating it. If I ever run for office, I swear I'll run with the promise of being pro-life and pro-choice—no more false dichotomies. The American people deserve at least that much competence from their politicians.
Technically, it is possible to get into med school with only three years of undergrad education, and a fraction of a percent of M.D. degrees are actually awarded to people under those circumstances, but realistically, you won't get into medical school to get an M.D. without first obtaining an undergraduate bachelor's degree. Similarly, you won't get into law school to get a J.D. degree without an undergrad degree.
You could certainly argue that they're equivalent to Master's degrees, but they most certainly are not undergraduate degrees.
It makes it easier to drop support for older equipment if they can just provide you a replacement rental unit. Over the long haul, the cost savings might actually add up to more than the cost of the hardware.
In the long run, I'd expect the tools to adapt to solve those problems more transparently, e.g. through the use of standardized libraries that hide the parallelization behind procedural wrappers so that developers can write seemingly procedural code, but gain the benefits of massively parallelized code for the pieces that matter.
Functional programming and unit testing are things you don't see widely used in the videogame development world, at least that I've seen.
I'd expect functional programming to be used quite a bit in that space, but only for very small chunks of performance-critical code, such as massively parallel bits down in the guts of raytracing engines. Now whether they actually use functional programming languages or not is another question.
Unit testing is something you don't see widely used in software development, period, unfortunately. But the industry is getting better. Slowly. Very slowly. Very, very slowly. Glacially, really.
It needs to be done and done well. Very tempting. But alas, just like drug use, there's only so much any sane person can write about the subject, because anyone who knows functional programming well enough to fully explain why it is harmful is probably mentally damaged beyond the point of being able to understand why it is harmful.:-D
The thing is, functional programming is a good paradigm for students to be exposed to in school. Briefly. It forces you to think about data flow through your program, and forces you to think about your software as a giant state machine and visualize how the states change as your software does work. It is not the only way to teach that concept, but it is a halfway decent way. And once you pick up those concepts, you'll start to understand why singletons are so useful (approximately the polar opposite of functional programming, but often the software equivalent of the data you'd be passing around in a functional world).
So basically, there's a time and a place for everything, and it's called college. But just like with drugs, if you continue to do significant amounts of functional programming after that, don't be surprised if the rest of us ask what you're smoking. Functional programming as a real-world paradigm tends to be almost invariably a disaster, because it neither fits the way we think about problems (human thinking is almost entirely procedural) nor the way machines do work (computers are inherently procedural). It can provide useful extensions to procedural programming languages that serve specific purposes (e.g. closures), but calling functional programming useful for that reason is akin to calling a diesel-electric freight train a perfect commuter car that saves fuel because a Prius is also hybrid hydrocarbon-electric.
About the only space where functional programming techniques might really make sense is when working in a massively multithreaded environment, e.g. creating really efficient implementations of certain massively parallelizable functions (such as FFTs). But for the most part, that functional programming is limited to creating components that are then utilized as small (but performance-critical) parts in what is otherwise on the whole still procedural (or OO) software.
Outside of those very limited scopes, though, the theoretically ivory-tower-pure, zero-side-effect functional programming model is pure garbage. Real world systems don't just have side effects; they are side effects, whether you're talking about storing data on disk, sending it over a wire, drawing it on the screen, reading data from a keyboard, or whatever. The notion of treating all of those "side effects" as some giant state object that mutates as it gets passed around is fundamentally antithetical to real-world use of the data, because state must be stored to be useful. And the entire notion of passing around the complete state of real-world software is so far beyond infeasible that the concept is utterly laughable. Cell phones have a gigabyte of RAM, not a petabyte. There's simply no way to write something like MS Word in a pure functional language, because it would take all the computing resources on the planet to barely run a single instance of it.
Using functional programming in most real-world environments, then, cannot possibly do anything but cause brain damage, because the whole functional paradigm is wrong for the problem space. It is like cutting the grass on a football field using only a single pair of nail clippers—theoretically possible, but completely infeasible. To that end, although I wouldn't say that functional programming is inherently considered harmful, it should be approached with approximately the same level of skepticism as goto statements, and for approximately the same reason. When used correctly, in a very limited way, it is a powerful tool to have in your toolbox that can seriously improve your software. When overused or misused, it is a black hole that consumes infinite amounts of programmer time while emitting very little.
Where I used to work, we called this the "Stack Overflow Effect" because so much bad code written by well-meaning people was floating around Stack Overflow that did things in dangerous, security-risky ways, such as telling people to disable TLS chain validation so they could use a self-signed cert for their test environment, then wondering why so many apps shipped with chain validation turned off in the production versions of the app.
I've actually written security documentation whose primary purpose was to provide a single set of code snippets that were known to do things in the right way so that we could plaster Stack Overflow with links to the doc. Then, when people say, "but can't I just...", we can say, "No", and point them atdocumentation explaining why so that at least when they do something stupid anyway, we can say, "Dude, what part of 'no, that is incredibly dangerous' didn't you understand?"
Which is worthless if the payment terminal is compromised, because the card can't know it the payment terminal is sending out messages on its own behalf or on behalf of another hacked payment terminal on the other side of the country.
Transaction log:
Terminal 1 gets a chipped card that it recognizes as "special". It contacts a C&C server and finds Terminal 2.
Terminal 2 reads the card number from some poor sucker's card and sends it to Terminal 1.
Terminal 1 relays the response to the card provider.
The bank sends back transaction info.
Terminal 1 relays that to Terminal 2.
Terminal 2 sends it to that same poor sucker's card for signing, gets the response, and sends it to Terminal 1.
Terminal 1 relays the signed response to the card provider.
As far as the card provider is concerned, the card physically present in Terminal 1 was actually used in Terminal 2.
The chip doesn't do that much, really. Most attacks on credit cards for the past decade have been attacks on the payment terminals themselves, and there's nothing fundamentally preventing someone who has already compromised a bunch of payment terminals from setting up a C&C server, and using it to let them make purchases for free by making the payment terminals recognize their chip in some way and relay the request through a different payment terminal to somebody else's card.
The only thing that would truly increase security would be having a screen on the individual card that shows the purchase info and a button on the individual card that lets you authorize it. As long as the information display and the authorization keystroke are handled by a potentially insecure, Internet-connected device, the biggest security problem with these systems cannot be solved.
Slashdot Mirror
The just-in-time printing is mostly used for delivery of back-catalog titles, and mostly to Amazon and B&N, rather than to bookstores (because special orders are relatively rare). The small number of actual POD printers are typically located in the same city as major online booksellers' distribution centers, and they bulk deliver books to them by the truckload, so the transportation cost is so cheap that it gets lost in the noise. Unsold copies are usually limited to at most one or two copies by Amazon unless the book is already selling in bulk, so again, that gets lost in the noise, at least for moderately high-sales titles. And so on. As for how much the publisher nets, that 10% estimate is probably in the ballpark for POD books. For books printed in larger quantities, of course, the reduced printing cost increases the publisher share.
If all you do is export it from InDesign, then yes, it's a negligible part of the cost, but the formatting is also likely to be mediocre. If done well, it's a decent chunk of change, though still not huge. :-)
This. I mean, you should be able to invest that in the stock market and average at least $8 million per year, permanently, allowing enough extra money to compensate for inflation. That's enough for a team of at least 20 engineers plus renting space for them to work, equipment costs, health insurance, etc. So barring the website being insanely complex, you should literally be able to run it on that without even touching the principal, even without bringing in a penny of revenue. What the heck are these people doing with all that money?
True, though there are thresholds below which expansion makes no sense. Say I have a bookstore. I have ten employees and overlap them to keep the store open during reasonable business hours.
In big businesses, the interesting thresholds tend to be even bigger and more dependent on things other than available capital. You have a lot of opportunities for bringing in a new person in various parts of the company as workload increases over time, of course, but the really interesting, rapid growth happens when the company decides that they want to go after a new market segment, which means they have to ramp up their staff fairly dramatically. That requires more than just capital; it requires big ideas and a reasonable probability of making enough money to make it worth the effort.
That's why even though Apple's U.S. profits alone could cover the cost of hiring on the order of 700,000 full-time software engineers, they have on the order of one percent of that number. So probably only about one or two percent of their revenue goes into staffing (ignoring C*O and VP bonuses). Even if you double or triple that number to cover the cost of renting or building office spaces, assuming you ignore the occasional massively over-budget project like the spaceship, total employee costs still probably fall down in the single-digit range percentage-wise. In other words, if they needed more people, they would easily be able to afford many more people, so bringing more money into the U.S. won't change their hiring at all. This tends to be true for all sufficiently large businesses. In other words, there's a threshold of capitalization beyond which adding more money won't result in more jobs.
The bottom line is that if you want to increase the number of available jobs, the best way is to raise taxes on big businesses and use that to offset a reduction in taxes on smaller businesses. Those smaller businesses still have room to grow, and every dollar that they pay in taxes is a dollar that they can't pay their employees; for bigger businesses, every dollar they pay in taxes is just a dollar that they can't pay their shareholders, which although certainly beneficial, does not create jobs.
Of course, a big part of the problem is that in the 1970s, California enacted a property tax scheme that is perfectly designed to limit homeowners' ability to move. By making property taxes be based solely on the purchase price instead of on the actual value of the home, people would pay dramatically more in property taxes every year if they sell one house and buy a second one even if they break even on the deal.
Prop 13 drastically skews the proportion of renters to owners by forcing people to rent out their old place so they can afford the rent on a new place instead of selling and buying. It also discourages new people from entering the market by making them pay the bulk of the cost of goods and services while folks who have been there for a few years pay proportionally less. The result is one of the most screwed up real estate markets anywhere in the world.
(BTW, Sunnyvale mobile home parks are only ~$1k per month and only maybe $50–75k to buy an old house and move it out of the way, plus the cost of whatever you move in. That extra $1,500 per month + $75k is the Google tax you pay for living five minutes closer to work.)
Another part of the problem is that the Bay Area lacks a proper region-wide planning commission with authority to regulate zoning across the various cities. So you have places like Menlo Park, where the only housing is private estates for the rich C*Os, with lots of businesses out near the shore where land is cheap (because it smells of rotting fish), and you have Gilroy and Morgan Hill that are almost entirely housing, with few businesses.
IMO, what we really need is to have some government entity that slowly converts business-use land in the South Bay to residential use and says "No" whenever big companies say that they want to expand their presence in the South Bay, encouraging them to build satellite offices farther south instead. And offer tax incentives to locate new businesses outside the SF/Peninsula/South Bay area. Adding more businesses farther south would increase the reverse commute traffic and reduce the primary commute proportionally, and opening up more farmland to development would go a long way towards reducing the cost of housing as well.
Unfortunately, that's unlikely to happen unless there's a single management agency that has some authority across all the different administrative districts. Right now, each city wants to get its share of the tax revenue from new businesses, and they mostly don't care about the clustering problems that result from it. Nobody is taking a bird's eye view of the problem, or if they are, they don't have the authority to do anything about it.
Greece, as best I understand it, is screwed up because the government paid for it without actually having the revenue to pay for it. That makes them far more like the modern borrow-and-spend Republicans than the tax-and-spend progressives. When, over a five-year period, a country's tax revenue increases by 31% and government spending increases by 87%, you're going to have a serious increase in your national debt. The United states solves this by devaluing its currency. Unfortunately, the Greeks are part of the Eurozone, and thus are limited in how much currency they can print each year, which means they can't just print more money to avoid becoming crippled by their national debt.
Of course, to make matters worse, their national debt is so huge relative to their GDP that it probably wouldn't help even if they could print money. Even in relatively good times, Greece was borrowing over 8% of their GDP every year. That's simply unsustainable. As a result, while U.S. states have debts that are on the order of a third to half their GDP, Greece has debt that is on the order of double their GDP. Imagine if the state of California took on a third of the national debt by itself, and you're in the ballpark. Nobody in the U.S. government—even the most socialist progressives who advocate a base income—are crazy enough to borrow that kind of money, I don't think.
But a bigger problem is not the amount of spending, but rather the types of spending that the Greek government has done. Instead of building infrastructure that would actually benefit them financially (e.g. factories), they spent frivolously on things like a giant sports venue for the 2004 Olympics that didn't cover its costs and that they couldn't afford to actually maintain afterwards. Their social security system is or was broken, with such fascinating flaws as paying out pensions to single female children of dead retirees. The state airline was a giant money pit for many years. And their military spending at the start of the crisis bordered on insanity (sound Republican enough for you?) at something like 7% of their GDP—proportionally more than the U.S. spent while fighting two wars.
No, the Greek government is a prime example of what happens when Reagan-Republican-style borrow-and-spend budgets get out of control and are not tempered by true fiscal conservatives insisting on balanced budgets and rainy day funds and so on. It is the polar opposite of progressive ways of handling budgeting (which, if they got out of control, would result in a tax rate that's so high that the people themselves would demand cuts in spending).
What department in the government, precisely, should regulate internet communication other than the Federal Communications Commission?
Here's what happened under "liberal" government policies:
You have the right to be on Slashdot and argue about which ideology is better because of liberal policies.
Lincoln was most assuredly not conservative. Republican, yes. Conservative, no. His policies resembled those of modern progressives more than modern conservatives, though even that is something of a stretch, because unlike 99% of modern politicians, Lincoln was actually a respectable statesman.
Progressive != socialist != liberal.
Additionally, Greece's problems stemmed from government overspending without enough taxation to cover the expenses. That's more similar to what Republicans do today than Democrats. And both Venezuela and Russia had problems where a few people at the top of the party essentially lived in luxury while the poor starved, which makes it more like a caste system than true socialism.
Besides, essentially zero modern progressives view socialism as the be-all and end-all of public policy, but rather as a useful tool to use in limited ways for the public good. That's radically different from a country that attempts to use pure socialism as its sole policy (which is exactly as foolish as using pure capitalism as the sole public policy).
Legally, it's a grey area. If your employment contract has morality clauses, for example, you can be punished for things done outside of work. However, usually that is limited to situations where your contract explicitly states it, which usually happens when working for religious institutions (or, occasionally, schools). You can also be fired for actions that reflect badly on your company, but that assumes that A. people know the author works for that company, and B. they have reason to somehow connect the two. And of course, in at-will states, your employment can be potentially terminated for any reason, though in many, the implied covenant of good faith might give the author grounds to argue that this was without cause, done out of malice arising out of personal embarrassment on the part of the management team.
The bottom line would be that the author should contact a lawyer who regularly deals with employment law in that part of the country, because whether he has a case or not is highly dependent on where the author is located, and I'm pretty sure it won't be open-and-shut no matter where the author lives. However, the fact that the author has not revealed where he works does open the opportunity for the lawyer to point out that bringing this to court will cast their company in a very bad light publicly, whereas an out-of-court settlement for... say ten years' salary will not. Depending on how terrified the company is, such (entirely legal) blackmail might actually be more effective than bringing a suit.
With that said, there's a magic point beyond which developers start to leave the platform and less software gets developed for the platform. So they still have to care about developers enough to stay on the right side of that tipping point.
In my experience, what makes it chaotic is the vast expanse of code that you didn't write personally. I've seen big chunks of functionality have to be completely rewritten because even major frameworks from major companies like Apple sometimes have bugs that are showstoppers when used in some way that the original author didn't expect. Most people normally assume that external dependencies already work when estimating, because after all, those are major frameworks written by major companies with testing resources.
Now extend that to code written by random engineers with limited testing resources. Normally, you assume that your internal code works, because after all, people are using it every day. But what happens when there's an edge case you didn't notice? If it isn't a crash, a bug in a suitably complex app often isn't easy to track down, and even when it is a crash, it might be some subtle multithreading race condition that can be utter misery to debug. And the larger the app, the more opportunities for untested code paths to suddenly find themselves on the hot path. This is why estimating is hard; you aren't just estimating how long it will take to get your code working; you're also estimating how long it will take you to fix everybody else's mess.
That's a very naïve view of reality. For every business that's on the brink, there are hundreds that are doing well, and many that are turning record profits. A business that cannot afford to pay its employees a living wage is almost certainly doomed anyway, so allowing it to pay a less than a living wage is just delaying the inevitable slightly. The business will fail. Let it fail.
Keeping a business on life support by letting it pay a subminimum wage doesn't help anyone in the long term, and doesn't help very many people even in the short term. But allowing businesses to pay a subminimum wage does hurt people who work for all those other companies that actually are profitable, because given the opportunity to pay their employees less, they will do so.
More to the point, if that is the only business providing jobs in a particular community, then that community is doomed. Keeping the business alive a little longer by depressing wages just encourages people to stay in the doomed community and make less and less money, thus making them less and less able to afford to move to a community that isn't doomed. So continuing to pay those employees a wage actually ends up hurting those employees more than it helps, at least in the aggregate, though the individual employees might not believe it at the time.
I don't think that's true at all. Most of the pro-life voters I've known are people who genuinely care about protecting the unborn. Most of the pro-life politicians at least appear to be using the abortion issue as a means to get elected (though I suppose it is also possible that they're genuine but clueless). The number of pro-life folks who are actually misogynists is probably fairly small, though I'm sure that they do exist.
When you're talking about a short-term crunch period, sometimes those really are unavoidable, because of events that could not have been predicted ahead of time. When that happens, what matters is that the period be A. short, B. bounded, and C. rewarded with extra vacation to balance out the crunch. If an employer does that, it isn't a big deal. When an employer drives people to work 18 hours a day all year around, though, that's a much bigger deal.
That said, to some degree, what you're describing is still a failure of management. The final deadline might not be movable, but the milestones on the way to that deadline are movable, and the number of employees you throw at the problem is also adjustable. There are two ways to trivially fix the problem in your case:
This isn't rocket science. Either approach above would make those crunches completely unnecessary, and the combination would do so in a way that isn't even particularly painful for the company or the employees. However, both approaches require management to A. acknowledge that there's a problem, and B. care enough to fix it.
Yes and no. Most startups have the opportunities for growth, stock options that could become valuable, etc., though you always have a decent chance of not getting anything from them other than more work. But there's definitely a point beyond which that extra work qualifies as worker abuse. This is why we need stronger laws on employee work hours.
Don't get me wrong; I'm okay with people hiring "exempt employees" with the understanding that their work hours will vary throughout the year, depending on what is happening. Where that scheme goes off the rails is when that turns into an expectation that you'll work 50+ hours every week—something that is fundamentally unsafe from a psychological perspective, causing serious harm to workers when done over a prolonged period. And from what I've read, Uber is one of "those companies".
Make no mistake, that culture is entirely the fault of Uber's management. Young people tend to think they're invincible, so without managers telling them to do otherwise, they will work themselves into the ground—sometimes literally. They think that by working ridiculous hours, they'll get ahead of their coworkers, and when enough people do that, others start to believe that long hours are required; thus, a work culture forms around that expectation.
What those young people don't realize is that those longer hours invariably lead to bad decision-making and lower quality output. Statistically, for every hour above about thirty hours, productivity falls off, and by about 50 hours or so, productivity actually goes negative; for every hour worked beyond that limit, you end up doing more than an hour of extra work to fix the additional screw-ups caused by the hour of extra work. For this reason, it is crucial for every tech business to have competent managers who strongly encourage employees to maintain a healthy work-life balance. Managers who do not do this—managers who prioritize short-term gains over worker health—invariably lead to worker burnout, long-term low productivity, and yes, suicides.
Unfortunately, between Uber and video game companies, it is pretty clear that self-regulation by industry isn't working, and that government needs to step in. Exempt shouldn't mean "we own your life". It should mean "40 hours average", i.e. the same as non-exempt workers, but allowing for seasonal variation. It should be illegal for exempt workers to spend more than an average of 40 hours per week spread across a one-year period. Huge fines are quite literally the only thing that companies like Uber will understand.
No, actually it's the solution to the abortion false dichotomy. And this isn't by any means the first story on the subject. A team in Japan did early animal testing in an artificial womb at least a decade back. I know this because I remember having a conversation about funding the development of this technology as a way for anti-abortion folks to put their money where their mouths are while on a church choir trip in 2008.
The fact of the matter is that abortion is worse than a wedge issue. It's a false dichotomy. Why would anyone in their right minds not want both a right to life for the fetus and a right to choose for the mother? The nature of birth involves trading the rights of one person for those of another, and that's the only thing that makes the abortion issue challenging for people to navigate. The mere existence of artificial womb technology is a game-changer.
If Republicans were actually serious about ending abortion, they would have jumped on this a decade back, and would have insisted on pouring funding into making this technology viable. We'd see research dollars being poured into that instead of into missile shields and random weapons research, and this technology would be fully viable by now, because with enough people working on it, the advances would happen faster. But they haven't done this, because they would lose most of their seats if abortion actually became illegal in a way that wouldn't get undone in a future power shift.
A truly intelligent, competent candidate for office, then, should be pointing this out, and should be running on a campaign of making artificial wombs available soon, and then making abortion illegal, requiring patients to instead get outpatient transfer surgery to move the fetus to an artificial womb. And the government should massively subsidize the transfer and pay for the incubation in cases where the woman gives up a fetus for adoption in utero so that no one chooses a back alley abortion over saving a life. And the government should require insurance companies to cover the transfer and incubation in cases where the life of the mother or fetus would be in jeopardy if a pregnancy continued, so that women with high-risk pregnancies can keep their kids without risking their own lives and the lives of their kids.
The mind-boggling thing about this, at least in my mind, is that our politicians still haven't thought of it. This should have been obvious to any competent leader at least ten years ago when the first study came out. Arguably, it should have been obvious earlier than that. I've been advocating this as a solution to the abortion debate for so long that I can no longer even remember when I started advocating it. If I ever run for office, I swear I'll run with the promise of being pro-life and pro-choice—no more false dichotomies. The American people deserve at least that much competence from their politicians.
Technically, it is possible to get into med school with only three years of undergrad education, and a fraction of a percent of M.D. degrees are actually awarded to people under those circumstances, but realistically, you won't get into medical school to get an M.D. without first obtaining an undergraduate bachelor's degree. Similarly, you won't get into law school to get a J.D. degree without an undergrad degree.
You could certainly argue that they're equivalent to Master's degrees, but they most certainly are not undergraduate degrees.
It makes it easier to drop support for older equipment if they can just provide you a replacement rental unit. Over the long haul, the cost savings might actually add up to more than the cost of the hardware.
... and launching your package with a delivery cannon that sticks out the sunroof.
In the long run, I'd expect the tools to adapt to solve those problems more transparently, e.g. through the use of standardized libraries that hide the parallelization behind procedural wrappers so that developers can write seemingly procedural code, but gain the benefits of massively parallelized code for the pieces that matter.
Or not; hard to say.
For that to be even ostensibly correct, you're missing one single quote mark and some double quotes, e.g.
"There are to many 'it's, don't you think?" he said.
And even that is arguable, because those aren't really apostrophes; they just happen to use the same key on the keyboard, typically.
With only two exceptions, the plural of any word is always spelled with an 's', not an apostrophe followed by an s. The exceptions are:
And even then, those exceptions might depend on what style guide you go by.
I'd expect functional programming to be used quite a bit in that space, but only for very small chunks of performance-critical code, such as massively parallel bits down in the guts of raytracing engines. Now whether they actually use functional programming languages or not is another question.
Unit testing is something you don't see widely used in software development, period, unfortunately. But the industry is getting better. Slowly. Very slowly. Very, very slowly. Glacially, really.
It needs to be done and done well. Very tempting. But alas, just like drug use, there's only so much any sane person can write about the subject, because anyone who knows functional programming well enough to fully explain why it is harmful is probably mentally damaged beyond the point of being able to understand why it is harmful. :-D
The thing is, functional programming is a good paradigm for students to be exposed to in school. Briefly. It forces you to think about data flow through your program, and forces you to think about your software as a giant state machine and visualize how the states change as your software does work. It is not the only way to teach that concept, but it is a halfway decent way. And once you pick up those concepts, you'll start to understand why singletons are so useful (approximately the polar opposite of functional programming, but often the software equivalent of the data you'd be passing around in a functional world).
So basically, there's a time and a place for everything, and it's called college. But just like with drugs, if you continue to do significant amounts of functional programming after that, don't be surprised if the rest of us ask what you're smoking. Functional programming as a real-world paradigm tends to be almost invariably a disaster, because it neither fits the way we think about problems (human thinking is almost entirely procedural) nor the way machines do work (computers are inherently procedural). It can provide useful extensions to procedural programming languages that serve specific purposes (e.g. closures), but calling functional programming useful for that reason is akin to calling a diesel-electric freight train a perfect commuter car that saves fuel because a Prius is also hybrid hydrocarbon-electric.
About the only space where functional programming techniques might really make sense is when working in a massively multithreaded environment, e.g. creating really efficient implementations of certain massively parallelizable functions (such as FFTs). But for the most part, that functional programming is limited to creating components that are then utilized as small (but performance-critical) parts in what is otherwise on the whole still procedural (or OO) software.
Outside of those very limited scopes, though, the theoretically ivory-tower-pure, zero-side-effect functional programming model is pure garbage. Real world systems don't just have side effects; they are side effects, whether you're talking about storing data on disk, sending it over a wire, drawing it on the screen, reading data from a keyboard, or whatever. The notion of treating all of those "side effects" as some giant state object that mutates as it gets passed around is fundamentally antithetical to real-world use of the data, because state must be stored to be useful. And the entire notion of passing around the complete state of real-world software is so far beyond infeasible that the concept is utterly laughable. Cell phones have a gigabyte of RAM, not a petabyte. There's simply no way to write something like MS Word in a pure functional language, because it would take all the computing resources on the planet to barely run a single instance of it.
Using functional programming in most real-world environments, then, cannot possibly do anything but cause brain damage, because the whole functional paradigm is wrong for the problem space. It is like cutting the grass on a football field using only a single pair of nail clippers—theoretically possible, but completely infeasible. To that end, although I wouldn't say that functional programming is inherently considered harmful, it should be approached with approximately the same level of skepticism as goto statements, and for approximately the same reason. When used correctly, in a very limited way, it is a powerful tool to have in your toolbox that can seriously improve your software. When overused or misused, it is a black hole that consumes infinite amounts of programmer time while emitting very little.
Where I used to work, we called this the "Stack Overflow Effect" because so much bad code written by well-meaning people was floating around Stack Overflow that did things in dangerous, security-risky ways, such as telling people to disable TLS chain validation so they could use a self-signed cert for their test environment, then wondering why so many apps shipped with chain validation turned off in the production versions of the app.
I've actually written security documentation whose primary purpose was to provide a single set of code snippets that were known to do things in the right way so that we could plaster Stack Overflow with links to the doc. Then, when people say, "but can't I just...", we can say, "No", and point them atdocumentation explaining why so that at least when they do something stupid anyway, we can say, "Dude, what part of 'no, that is incredibly dangerous' didn't you understand?"
Which is worthless if the payment terminal is compromised, because the card can't know it the payment terminal is sending out messages on its own behalf or on behalf of another hacked payment terminal on the other side of the country.
Transaction log:
As far as the card provider is concerned, the card physically present in Terminal 1 was actually used in Terminal 2.
The chip doesn't do that much, really. Most attacks on credit cards for the past decade have been attacks on the payment terminals themselves, and there's nothing fundamentally preventing someone who has already compromised a bunch of payment terminals from setting up a C&C server, and using it to let them make purchases for free by making the payment terminals recognize their chip in some way and relay the request through a different payment terminal to somebody else's card.
The only thing that would truly increase security would be having a screen on the individual card that shows the purchase info and a button on the individual card that lets you authorize it. As long as the information display and the authorization keystroke are handled by a potentially insecure, Internet-connected device, the biggest security problem with these systems cannot be solved.