Having worked in the financial industry for a few years, this is definitely necessary. Financial companies over the last few decades have shifted from a culture of responsibility to a culture of sales. There is constant pressure to "streamline" the underwriting process, i.e. cut out safeguards and checks and throw money at people as quickly as possible. When there are no effective incentives to do a good job, they aren't going to do it, and the burden will be shifted off to the public.
What's great about this is you're hedging your bets (prudent) while acknowledging the worker's needs as well. The problem without some kind of middle ground like this is that it reeeeeally feels like getting screwed when you're working above your pay grade for an extended period of time without explicit acknowledgement. I've had a lot of unhappy friends in roles like that where they were doing team lead / manager stuff and getting jerked around by HR and their boss for months or years. Now they're hypersensitive to anything that smells remotely like that experience. I like how you're making a public commitment but making sure to manage your risk. It's a great compromise.
That may very well happen over time. Non-Bay workers may bid down the price of coding labor, and remote workers from disparate markets will bid against each other, and eventually some "global market clearing price" may be established. Economic theory doesn't operate instantaneously, though. It manifests over time as individual actors bid and negotiate. Remote work is relatively new and its substitutability is being figured out. In the meantime companies may exploit the inefficiencies (and so might workers).
But prices aren't based on fairness, they are based on demand and supply. If there is a supply of workers willing to work at a lower price in areas outside of San Francisco, then it makes sense for a company to purchase their cheaper labor if it supplies the same value as the more expensive labor.
I'm someone who chose the predictable suburban values, and I still say amen to your analysis (especially the final sentence). It's like people have no sense of what real character (in a person or place) is actually comprised of. And let's be honest, even the food and beer in these places are frequently mediocre.
That's exactly why you should read it, and other great works. "Those who don't learn from history" and all that. I just recently read "On the Shortness of Life" by Seneca and I'll be damned if it couldn't have been written yesterday.
I'm glad the NYT has with a single op-ed answered the fundamental question of the American Experiment.
Snark aside, there are entire great works of Western thought on the question of whether men are capable of governing themselves. It is literally the the opening question of "The Federalist Papers," for Christ's sake. A breezy survey of a smattering of social science is bringing a knife to an intellectual gun fight, and comes up well short of making a meaningful contribution.
The biggest thing for me is experiencing my own emotions almost like coming upon landmarks while driving. They stop being "you" and start to be just part of the scenery as you drive along through your life.
One counterintuitive trick that has worked for me is to fire up my "manager brain" in daily life. When you do most white collar work, especially as a manager, your job consists largely of filtering a huge number of potential inputs/jobs and focusing intently on the highest value/leverage ones. Instead of fighting my increasing tendency to scan for a new dopamine hit, I allow my brain to wander for a moment and then to consider the highest value option, which frequently turns out to be continuing doing what I'm doing so that I gain the advantages and compound interest of depth in an activity and do not incur the cost of context switching. I will say that this takes a little enjoyment away from going truly deep and achieving flow, for example, where you lose your sense of time and become engrossed in the narrative/activity/whatever, but it's a bit of a jiu jitsu move and allows you to fight the world around you less and use it to your advantage a little more. I still think tuning out and removing distractions is valuable, but it's a good complementary practice.
Life is essentially a big collection of systems or games, and choosing to play the wrong ones is worse than playing the right ones badly. You can learn tricks to get promoted at some place that has a shitty culture, shitty bosses, etc., but at the end of they day all you'll have done is won the wrong game.
I think programming as a profession provides three main services:
1. Implementing user/client features (meeting demand)
2. Designing and maintaining an architecture flexible enough to continue adding features at a reasonable pace
3. Reducing complexity, which primarily involves picking the right primitives and reducing the number of variables as much as possible
2 and 3 are really just in service of 1, but the fact is that if you don't invest in flexibility/leverage/optionality and proactively keep yourself from getting swamped by an overwhelming number of "moving parts," your productivity will creep to a halt and formerly cost-effective features will no longer be economical, destroying your capability to provide customer value.
People not being on the same page is a massive problem. It especially constrains the leader herself, because she can't make any strong, clear decisions without second-guessing whether she has the authority to do so.
Yes and no. You could summarize 'The Wealth of Nations' the same way and it would also sound pretty basic and not worth the 800+ page read. I agree in general that 'Thinking in Bets' is conceptually thin, in the sense that there's a high text-to-ideas ratio, but there's some value in reading all of that. Duke does a good job of describing her own thoughts and experiences, in a way that makes you want to actually apply those ideas in your own life (rather than just read about them). A better book on the topic is 'Fooled by Randomness.' It's much more conceptually dense and covers a lot of the same ideas.
As in all things, we humans are predisposed to think in all-or-nothing terms. Agile works or it doesn't. Lean is effective or it's not. People just don't want to do the hard and nuanced work of realizing that these are just management methodologies (ffs). They will not by themselves make your business good or bad. There are a hundred other factors at play in your work life, from the personalities of upper management to the viability of your product. Picking a methodology, just like picking a religion or a philosophy or a brand of toothpaste, is not, and never will be, a silver bullet. It's a tool in the toolbox, with pros and cons. Nothing more.
Purely anecdotal, but I was a tutor for two years out of college and planned to be a teacher (originally college, then high school). I went into a different field for 3 reasons:
1. Pay
2. Professionalism - all of the teachers I saw and talked to under 65 were treated like dirt, and were micromanaged instead of being treated like professionals
3. Barriers to entry. By the time I got my Master's and decided I'd rather teach high school than spend several more years getting a PhD, it was financially impractical for me to go back for more years to get a teaching degree. It was also very difficult to find internships and open positions. One guy I know who did a straight teaching degree interviewed almost a HUNDRED TIMES despite doing incredibly well in his program and student teaching at a prestigious high school.
I'm sure the kids are doing fine without me, but I had stellar reviews from every kid and parent I ever worked with, and from professors I TA'd for. People have told me my whole life I should be a teacher (came up again just the other day with the guy I was pair programming with). I'd happily take less money to be a teacher, but when you add in factors 3 and especially 2, it just isn't worth it to me. I'm not going to suffer a bunch of professional abuse and take a financial hit to boot to do something that my society doesn't seem to genuinely value.
I'm not an expert, but anecdotally my uncle is a chemist at a company that makes plastics and they make all of theirs from natural gas. They do not drill, refine, or otherwise use oil.
I disagree with the other responses. I think it's both. You can get very quick results and feedback for experiments related to implementation. Code compiles or doesn't, tests pass or they fail. But whether you actually built the correct thing is definitely "wicked." A lot of times subtle bugs and user feedback surface weeks or months after the fact. It can be very hard to find out whether what you did worked for the business need, which is ultimately the main point of the job.
In other words, marketing is very important. I think as technical people we like to "evaluate things on merit," but the reality is that the technological complexity of our society has become such that it is virtually impossible for someone to gauge the quality of a product in a field where we're not an expert. That's part of why marketing takes on such importance.
This is a really interesting point. It reminds me of the story of the American soldier meeting a former Vietcong many years after the Vietnam war. The American said, "Every time we met you guys in the field we beat you. You never won a battle." The Vietcong replied, "That is true. It is also irrelevant." Vietnam was a great example of how misleading measures and statistics could be.
I tried to think of a counterargument to this and drew an almost total blank. There have been some great works of art over say the last 20 years or so—"Breaking Bad," "The Sopranos," and the like—but it's almost completely trash. I can't name more than a half-dozen things I'd have missed if I had thrown out my television and deleted Facebook etc.
This is actually discussed very intelligently in "The Mythical Man-Month." The author explains that large software projects have an inherent tension between coherence and efficiency. A small team maintains coherence, but cannot get the required amount of work done in a reasonable amount of time; a large team works faster at the expense of coherence. Balancing those two aspects effectively is what makes large projects successful.
I think the point is that "data" is useless until it becomes "knowledge," and that turning data into knowledge is a complicated and philosophical act. Business being business, most of the people running the show were never interested in the deeper questions of how to create knowledge. They just wanted a new arrow in the quiver. Once they realized the cost of actually doing the work, it became much less appealing.
Architectural coherence is such an important part of software design. I agree with your point completely—you need specialists for deep, specific problems, but you also need people with a view of the entire system.
Loose interpretation of "tools" but I pair program. It does wonders for clarity and focus most of the time, but can be exhausting and sometimes counterproductive for deep thought and analysis.
I disagree with this completely. Development is not line work, and doing it like line work creates unmaintainable, expensive crap. "The Mythical Man-Month" explains this well. Conceptual coherence is of the utmost importance in effective software systems, and you don't get that by just knocking out stories one-by-one like they're desktop support tickets.
After fixing a recent bug, I asked my client company what if any postmortem process they had. I informally noted about 8 factors that had driven the resolution time to ~8 hours from what probably could have been 1 or 2. Some of them were things we had no control over, but a good 4-5 were things in the application team's immediate control or within its orbit.
These are issues that will definitely recur in troubleshooting future bugs, and doing a proper postmortem could easily save 250+ man hours over the course of a year. What's more, fixing some of these issues would also aid in application development. So you're looking at immediate cost savings and improved development speed just by doing a napkin postmortem on a simple bug. I can't imagine how much more efficient an organization with an ingrained and professional postmortem culture would be.
Your first paragraphs are entirely correct. "Shadow banking," for example, has created a notoriously complex and opaque credit market.
Your last paragraph, though, is completely at odds with basic financial and economic theory. Loans make mathematical sense because you don't make just one of them; you aggregate capital and take calculated risks on a broad variety of prospects. Many of them are low-risk (e.g. loans backed by substantial assets), others are high-risk, and you adjust the interest charged so that to take on high-risk investments you must be compensated with high interest rates. Maybe you take the full downside on one or two investments (e.g. you invest in two outright frauds), but if you have fifty other loans that offset those losses by paying high rates of interest, then you still make a profit.
Also to your point in the second paragraph: equity is a bad tradeoff in many cases. If I'm starting a business that I expect to be hugely profitable, but I need $100,000 in startup costs, would I rather give up a big chunk of my company and pay out dividends for decades (or in perpetuity), or borrow the money and pay it back with a comparably small amount of interest quickly?