jasonwocky

Not really, since the dependencies between them are now explicit. Yes the stitching is its own complexity, but divide-and-conquer is a pretty time-honored approach to effective problem solving.

Plus I think there's a big difference in respect a full-stack team / tech leader garners over someone who doesn't really understand the technical challenges of half the team.

I don't get your math entirely...if a contract is two months long, wouldn't it be 150x40 or 6000? Sure, I had to tighten my belt during month one, but at the end of month 3 I've got 6k and the person who took the 100 day rate has 4k + whatever they can make in a third month. If they extend another month at the same rate, we both have 6k at the end of month 3, except I only did 2/3 the work.

> , the main issue is just making sure to live in the actual city rather than the suburbs, if you want a city lifestyle.

Yeah but then your cost of living shoots up. I mean, I've priced Austin real estate. If I want to buy 2BR apartment in downtown Austin (the closest analogy to where I currently live in Brooklyn) I'm looking at half-million dollar properties. Which is fine for an NYC boy like me, it's what I'm used to, but then why am I moving again?

Good list, but as a contractor in the US, the one thing that sticks out that I don't agree with (necessarily) is:

-Getting 450 a day is always better than siting idle waiting for that 550-600 a day contract.

I'm fine with making a tradeoff like that for very short term work, but I don't want to commit myself to long- or medium-term work at any sort of significant discount.

If I'm confident I can get that 550 eventually, it easily pays for those days I spend on the beach.

Yeah, when I worked for 5 years as a developer in municipal government, I may have had less total take home pay than some of my peers, but my "hourly rate" was easily comparable. I had 5 weeks of vacation a year to start, and worked 35 hours a week, every week.

When I left, it wasn't because of the money.

> Everything I've seen seems so "In my experience..." as opposed to a formal proof.

The scientific method is ill-equipped to formally prove a generalized theory of software development. There are too many significant variables at play; too many equations to solve. We are left with little but "In my experience..." to guide us (as well as local experimentation, where science can actually be of some help).

Some issues are just 10x others, I guess.

> Most people can't begin to program; conversely, most people can begin to run.

This is based on what? You really think that most people can't be taught the basics of "Hello World", or a function that multiplies two numbers?

Plenty of people write Excel formulas when faced with the need to. That's "beginning to program".

I don't think the article is blaming Google. Just har-har'ing with attitude that Google maybe isn't as smart as its cracked up to be.

The mindset enshrined in this comment will certainly kill any attempt to be Agile. But while common, thankfully it's not universal.

I don't see how this is true. If you're building slack into your cycle there should be regular investment time available that a pure flow-based system wouldn't have.

If there's no slack in your sprint schedule, well there's your problem.

Yeah, I'm a big proponent of the thoughtfulness you describe. I don't like it when people shroud rudeness & cognitive miserliness as "just calling things like they see them." I prefer "See it, think about it, then call it."

I really value honesty, but not every emotion-laden thought that passes through our heads deserves airtime.

I thought it was obvious on its face that "vigorous debate" isn't the "only" way that bad ideas end up dying. In fact, plenty of bad ideas have come out of vigorous debate.