> We don't even "work with" each other. If you don't learn anything else from this, get this: we work alone.

I don't get this. I like working in a team, and like working with people. I can't imagine working alone all the time. I am more productive when I am with the team, and interacting with the team than when I am alone in a room.

I know everyone works differently, but almost no one seemingly is willing to discuss an alternate version of this. I'm tired of the old 'meetings suck, PM's suck' cliches. When I was working for a large internet company, we got a lot of work done in meetings and lots of PM's were respected.

> I can't imagine working alone all the time

I can. I like working that way because it lets me focus and write really good code.

being around people, is more social, but I'm not writing code while I'm doing it. Which doesn't mean that it doesn't have its place, because it does (meetings are necessary to get a shared clear plan of how to work together on something, getting help on a problem or helping out with a problem builds trust/camraderie among team members)

> I'm tired of the old 'meetings suck, PM's suck' cliches

Just as I'm sure tons of programmers are irritated hearing you seem to suggest that working on their own is somehow bad or wrong.

> When I was working for a large internet company, we got a lot of work done in meetings and lots of PM's were respected.

How did you get work done in meetings? By definition, meetings are stopping work to communicate; the most work-efficient approach is to optimize away the need for meetings as much as possible.

> By definition, meetings are stopping work to communicate

You have implicitly and uselessly defined "work" as "everything you do that's not communicating".

I can write code and solve problems all day long by myself. So can my coworkers and housemates. When we have meetings at work, we figure out which problems to solve and why. Why is it that the coding part is considered "work" and the meetings is considered "not-work"? I would just be a lone programmer working on subsets of the wrong problem without the meetings. Lately, I feel like the "work" gets done in the meetings, and I just tidy up afterwards (for a few days) by myself. That's because the answers are easy, but the right questions are hard.

Let's try this: meetings are stopping implementing to communicate. Or, from another perspective, coding is postponing meetings until new issues/questions have been solved.

> Why is it that the coding part is considered "work" and the meetings is considered "not-work"?

In kernel terms, meetings and PMs are the scheduler, and you are the threads/processes being scheduled.

Is the scheduler doing work? Yes. Is that work simply overhead required to keep the pipeline full and fair scheduling of work occuring? Yes.

> Let's try this: meetings are stopping implementing to communicate or from another perspective coding is postponing meetings until new issues/questions have been solved

Or to put this another way, meetings are a page fault interrupt that is taken because the necessary backing store (the solution to issues/questions) is not available.

They're almost pure cost. Spending any more time there than you absolutely need to is a waste.

> Spending any more time there than you absolutely need to is a waste.

This is a tautology. Spending any more time anywhere on anything is a waste. The point that you're missing is that just because some meetings add no value doesn't mean that no meetings add value.

> The point that you're missing is that just because some meetings add no value doesn't mean that no meetings add value.

The fact that some meetings add value doesn't mean all or even most meetings add value.

My analogy holds; page fault handlers add value. They also incur a heavy cost and you want to avoid faulting if it at all possible.

I agree. You asked "How do you get work done in meetings" and implied it was impossible. I argue that just because there is no work accomplished in your meetings or most meetings doesn't mean that no work can be done in meetings. No one anywhere is suggesting that valuable work is accomplished in all meetings. But when you suggest that no work is accomplished in any meeting, you're wrong.

I'm sorry you've had such a bad experience with meetings; it must be common or the stereotype wouldn't exist. My workplace is different. Since my most valuable work is accomplished in meetings, I wish I could be in meetings all of the time. The only reason I can't is because we frequently need long breaks to implement the work we did in the meetings. In fact, coding is a much heavier cost than meetings; unnecessary coding is much worse than unnecessary meetings and you want to avoid unnecessary coding at all costs (even though it's usually still quite fun). Just because you develop software doesn't mean you should spend as much time as possible writing code. Just because you produce code at work doesn't mean you're only working when you're coding.

> But when you suggest that no work is accomplished in any meeting, you're wrong.

This is where we disagree. Talking about work isn't tangible work. Talking unblocks work, to a point.

> I'm sorry you've had such a bad experience with meetings; it must be common or the stereotype wouldn't exist.

Given that my experience spans roughly 15 years, major corporations, small and large startups, in both management (director, VP, and C-level roles) and engineering (software, systems) I'm inclined to trust my experience that meetings are generally a work-substitution mechanism and a means of furthering political/social career advancement, and bad PMs (which is, sadly, most of them) are the worst offenders of them all.

Man, no offense, but you seem extremely short-sighted here. So when you and a couple coworkers are architecting a system, deciding what the pipeline of information flow is going to be, where the security holes may be, stopping any latency or unnecessary operations, and making sure the user knows how to use the damn thing on top of that - and you aren't writing code, but instead communicating with your coworkers - you don't think that's work? How could it not be?

What is work? Is it the typing of the code, the architecture of the software, or the decisions about what the software should do for the user? The latter 2 can be at least improved in meetings, where the clash of different opinions can produce a better outcome than just one person implementing their whims.

We can make lists until the cows come home, but passing them around amongst ourselves is not going to make one bit of difference.

How about actually asking for all of those things?

For instance, only once in 25+ years in this business have I heard an engineer ask for a decent chair. He got it. Period.

On that same theme, let's start giving the same honesty and information we demand from others. The "impossible" example in the article is meant to be humorous, but is actually painfully true. Rarely is something really impossible, just hard, complicated, insanely expensive, inconvenient or downright useless, but rarely "impossible".

But we bitch about wanting truth, honesty, information and not being patronized. Guess how seriously that will be taken as long as we don't reciprocate.

We don't ask, because we've learned from both direct & indirect experience that we won't get it (and may be punished for asking). We're good at making something from nothing, we just do it and others expect us to; thus making most needs seem a matter of wants, and wants being looked down on as waste, we learn there is little point in asking for more.

You are a good manager, sensitive to how a little money spent on a good chair can make a great difference. Alas, you are not the only one subordinates are exposed to, and takes little for others to undo the good you did.

Impossible tasks:

Can we get a snapshot of the internet at 6 AM each morning?

Can you send a physical package from Los Angeles to New York City in 14 minutes?

Can you write software that will province 100% accuracy of handwritings for all human beings on the planet? (That's arguably more possible than the Los Angeles example above, but only in theory)

Can you write software that will write the sequel to the Lord of the Rings?

Can you write software that will complete Mozart's unfinished Requiem Mass in d minor?

Can you get a complete list of valid email addresses of actual people on the entire internet, in all countries?

Can you write software that will convert what it sees through a camera as speech, thus allowing a blind person to walk around a city and have the software describe, in details, what the device with the camera is pointing at?

Can you create software that can replicate the artificial intelligence of a common fly, and be placed in a device the size of a hand-powered drone, with the ability to actually fly and avoid being hit?

1 - build a large enough datacenter to constantly crawl the internet. build each morning.

2 - build something that does, maybe a remote controlled rocket

3 - we can start and work on that direction

4 - there are software that generates stories already

5 - same kind of software can be adapted to generate music, you could use machine learning to follow the same logic from the part we have to finish it

6 - you can start and do incremental updates each day

7 - Thats actually a nice idea to use computer vision to tts, someone could actually make this as an app to google glass

8 - not long ago circulated a story about the army developing something like this

2: Distance from Los Angeles to NYC: 2790 miles. Distance in kilometers: 4469.58. Kilometers per hours: 19,155, for arrival in 14 minutes. NASA's X-43A has a top speed of 10,000 km/hr (by comparison, the SR-71 has a top speed of 3,529 km/h). So NASA's fastest plane, the X-43A, could not make it in time to satisfy the requirements.

It is possible to say that sometimes in the future, perhaps distant future, all things are ultimately possible, but that's not what we're talking about, is it. We're not worried whether sometime in the future we will be able to zoom around the galaxy and perhaps Andromeda on wormhole ships, in fancy flights of the imagination that would even surpass the bounds of science fiction and enter the realm of fantasy. No, rather we get silly requirements from managers who wants these things delivered in the next twelve to eighteen months.

Also note that a data center that crawled the entire internet daily would probably have to re-implement Google, and even Google most probably doesn't crawl the entire net daily.

Software that generate stories already... Please. Name one bestseller in the past, well, ever, that was automatically generated.

We can put an ICBM on someone's doorstep ~8000km away in just over half of an hour. Putting a package ~4500km away in 15 may be doable. You just better be ready to catch it at a couple miles per second.

Will the package detonate 100 feet in the air?

Twilight.

At least I am pretty sure...

Oh, and Google glass is a freaking disaster. If someone has one at a party at my house, I will kindly ask them to take them off and put them in their car. If they refuse, I will kindly ask them to leave. If they refuse I will kindly remind them that the Los Angeles Police Department will help remind them that in my house, I get to say who gets to stay.

Engineers should spend more time telling their managers why something is impractical rather than impossible.

Impossible becomes a crutch very easily.

Many times management does not know enough to understand the explanations.

Given proper audience, many computer people are able to base their reasoning for rejection on actual physical laws and theories, but since management many times is unaware of these laws and theories of physics, management dismisses the claims of impossibility as "primadonna behavior".

Well said!

*Can you send a physical package from Los Angeles to New York City in 14 minutes?

Nope. But we might be able to do NYC to LA in minus 3 hours on a fast drone.

I understand where you are coming from but...

...this attitude is indicative of a lot of engineers that end up being resented by the rest of the team -- expecting to be treated differently than others, secretly believing their skills make them superior.

Our skill is intense concentration. Imagine a soloist violinist mentally rehearsing his performance for later that evening. On the outside he looks sullen, near sleep. Inside, however, there's a 120 piece orchestra with the crazy Russian conductor, and the German harpist is plucking strings, and the soloist is counting in his head, watching the conductor, trying to perfectly time the moment when he begins moving the bow's horse hairs across the fourth string, vibrating his wrist, ring finger on the high e, indicating the moment of the hero's death and ascension to heaven, in the emotional denouement of the 45 minute piece.

Just as there are many people who neither appreciate classical music nor the skill, talent, and concentration required to play it well, so there are many people who neither appreciate computer programming nor the skill, talent, and concentration required to do it well.

As an aside, if you want to hear some fantastically good classical music, head over to youtube and search for the Vienna Philharmonic's rendition of Rimsky-Korsakov's Scheherazade conducted by Valery Gergiev at the Salsburg Festival in 2005.

Alternatively, watch the film Amadeus.

It's not about superiority. It's about time not being wasted and the act of engineering requiring unbroken long periods of concentration.

It's not an attitude. It's just the harsh reality of being in an environment where you work most efficiently when you're not being interrupted.

>The "true" list at the end, like a Hollywood ending, was probably not necessary.

I sometimes think that, being of an inherently analytical bent, engineers tend to underestimate the inability of others to add facts and observations together into a coherent truth.

As I read the original list, although I saw it clearly for what it was, I felt my blood pressure rise. It fairly accurately describes the apparent attitudes of some senior managers I have suffered over the years.

Indeed. I had originally left off the ending, but a few people who previewed the essay told me they showed it to others (who don't know me), and they said they weren't sure if I was joking or serious.

No need to be that harsh. It is good enough to recall a fact,a software engineer is a producer but a product manager is an overhead.

I think he needs to go back to school. He even doesn't know what the job description of a software engineer is. He says:"Software engineers write code ..."

Moreover, he contradicts himself. He compares himself with Steve Jobs. He says:"Don’t bother with the details." But, Jobs said:"Details matter. It's worth waiting to get it right."

I'm assuming you never got to the "Afterword" (perhaps due to anger or frustration?), as it is at that point that the author reveals that the entire article up to that point is the exact opposite of what he supports.

This does of course make for the argument that perhaps this style of writing is not suitable for skimming, though I'd agree with another comment on this post that after reading the part about 95% of 3,875,000 equating to approximately 1,000,000, I was definitely more perceptive that something silly was going on.

No, I didn't get to that point. I bet Ken had a lot of fun by his article and probably in his talks too. This is a good way to create buzz.

Number 5! Or just give me $1500 and I'll build one that crushes everything else for 75% of the price.

amendment to 8: add "human" to the list, in first position, obviously.

Excellent list.

7. Never lie to us. We are used to our machines always telling the truth. We insist on no less from other humans.

I've started to think of this as an impedance mismatch between engineers and managers. Our "subordinates" (computers, compilers) tell us we fucked up at our jobs by giving them nonsensical instructions. "Your brackets don't match and I don't know WTF to do. Line 87, fix your shit or I'm doing nothing." Being nonsentient machines, they don't fear getting fired so they tell the truth.

We get a kind of feedback from "subordinates" that managers never, ever get. We program them to come to us speedily with bad news. Managers, on the other hand, program us (by having temper tantrums and occasionally turning off peoples' incomes) as well as each other to do the opposite.

Regarding 1 (pair programming), I find that we work well with all our own personalities but not other people's :)