I read LHOD just a few months ago. Great stuff!
370 karma · joined June 19, 2009
So obviously you can save money by shortening call durations. This has a nice side effect of reducing the number of customers (over time), which also helps reduce support costs.
#metricsDrivenManagement
But I do know that tools often make it easy for people do incredibly stupid things by accident. Like the 'sudo remove file' command followed by '-rf' in the wrong place. I rimraf a lot; it's very useful. It's a miracle I haven't wiped out any computers doing so...
Other factors:
* "everyone else does it"
* Open floor plans seem like a good idea when you first hear them; the downsides are not immediately obvious. Verbal reasoning, no matter how flawed, almost always wins.
* The decision makers tend to be blissfully unaware of the dynamics of knowledge work because their work is typically interrupt-driven. Thus, they don't see any problem putting 50 programmers in a cramped and echoey gymnasium.
* Even if the decision maker is fully aware, their boss might not agree to a higher-cost office plan. Actual dollars will almost always beat non-metrics like "compounded employee productivity" or "time and money not wasted due to mistakes caused by people operating in a distracting environment".
--Yes, in theory you could design an experiment, but that would delay the decision and probably require spending money. And the outcome would probably be misinterpreted: the open floor people will be louder and will appear to be working harder. (But are they actually more productive or are they just scrambling to fix all the bugs they created?)
Why does this happen? In the best case, it's a misguided attempt at career development. Or it's a way to figure out who to give more money and who to fire. Usually there is an element of fear: "I'm afraid my employees will not work hard unless there is the threat of a bad performance review".
To be fair, ranking employees does sound like a good idea if you don't know anything about humans. Most management activities are really just things that sound like a good idea (but fall apart under scrutiny). To be more fair, bad management is the norm, so no one has good mentors and role models. "If everyone else does this, then it can't be wrong." It's another vicious cycle.
The premise of "failing to convince management" relies on the notion that "management can do no wrong". For example, if you tell your boss that we're about to drive the bus off a cliff, and he doesn't listen, it's your fault.
This is the way things work in many organizations, it's an old-school approach to management, but to me it is purely dysfunctional. When someone tells me I'm about to drive off a cliff, I say, "Wow, thanks! What did I fail to see that got us into this mess in the first place?"
Aside from Tufte's notion of blame, I think his essay is very instructive.
However this may not be true. While trying to find an e-source, I read that there were some politically-motivated rumors that the white house ordered the shuttle to launch for this reason. Feynman investigated that rumor and didn't find any evidence that the white house ordered the launch.
It's possible the detail about an on-air tv conversation between the president and a schoolteacher astronaut could have been fabricated as well to make Reagan look bad, or it could have been based on elements of truth. For example she was expected to broadcast 2 lessons to students from space, so the capability definitely existed. It doesn't seem too far out that they would have liked for this conversation to happen during the State of the Union, though that doesn't mean the white house ordered the launch.
I read this in Edward Tufte's essay Visual and Statistical Thinking (http://www.edwardtufte.com/tufte/books_textb), which discusses how better information displays might have convinced NASA management to postpone the launch. It also appears as a chapter in his book Visual Explanations.
I didn't have any luck finding sources on the internet (lots of keyword overlap). Tufte is much better informed than pretty much all of us, though it's possible he printed what amounts to an unsubstantiated rumor. FWIW he also served on the Columbia accident investigation board.
I think there were other pressures to launch as well. The launch date had been postponed 3 times already for various reasons. Cynical danek: I wouldn't be too surprised if some manager's performance review was based on how many launches took place on the scheduled date.
One way PPT is low-res is that there is not enough room on a slide to type full sentences. It wants you to dilute your thoughts into a bullet list or some similar fragmented format.
Often a presentation involves a series of slides, and ideally you'd want the audience to make comparisons between slides e.g. Before XXX, After XXX, & Therefore XXX is good. The sequentiality of slides is another example of it being low-res. This increases the cognitive effort needed to engage with your content, making it difficult for anyone to actually think critically about what you are saying. In other words, it's a great sales tool!
The paper handout is an excellent idea. You can fit the information of about 250 ppt slides onto a standard 11x17 sheet of paper.
PPT can be useful in other cases (I've used it for drawing seating charts), but it tends to be pretty terrible for presenting any sort of analytical content. I've seen a many PPT presentations from accomplished, smart people, and I can't recall a single one that wouldn't have been more effective as a paper handout.
PowerPoint is a slideware operating system which forces the presenter to contort the content into its low-resolution format. This necessarily makes the content less understandable, unless the content happens to be photographs and your topic is something like art history. It's easy to say it's the fault of bad presenters, but other formats don't necessarily make your audience dumber; with PowerPoint it is the rule rather than the exception.
"The average number of numbers on a powerpoint slide is 12. This is slightly better than communist propaganda (Pravda 1982). For comparison, see the sports page." --me, poorly paraphrasing
Discussion of how slideware led to 2 space shuttle explosions: PowerPoint Does Rocket Science--and Better Techniques for Technical Reports http://www.edwardtufte.com/bboard/q-and-a-fetch-msg?msg_id=0...
Tufte's textbooklet on powerpoint (an excerpt from his book Beautiful Evidence): The Cognitive Style of PowerPoint: Pitching Out Corrupts Within http://www.edwardtufte.com/tufte/powerpoint
I tend to avoid using out parameters. I've written extension methods to replace the typical out param framework methods.. For example, instead of int.parse(string s, out int i), we have "123".TryParse<int>(), which returns a nullable int. instead of TryGetValue on dictionary, we have GetOrDefault(key, optional default val) and GetOrDefaultAsNullable(key).
I think the new out parameter syntax is an improvement, but I'm still on the fence about whether out parameters are even a good idea when we can instead return a single type that encodes the same information.
I'd be interested in hearing other viewpoints on this.
What's wrong with adding the word "is" between "X" and "considered"?
Who is doing the considering?
What is X harmful towards?
Can anyone explain why this is a thing?
Do you disagree that C# has similarities to other languages? C# is based on Java, which is somewhat based on C++. Basically anyone who does a CS course learns one of these. In comparison, I don't know any programs that use Haskell, oCaml, scala, or ML (I had a single class in which I had to use ML fora single project). What I mean to say is, functional programming is not widely taught. I don't think this is controversial.
Do you disagree that any person that is reasonably smart and that you'd want to hire could become productive in c# within a few days, given that they've used java or C++ before. This is a super-low risk gamble. I don't think this is controversial.
The only indicator that someone can become productive in F# is that they have experience in one of F#, Lisp, ML, Haskell, etc. I don't think this is controversial.
Hiring people is hard. Maybe you haven't been involved in the process, but you have to interview hundreds of people just to find that one person who is smart, is a culture fit in your company, and has enough self-discipline and a high-enough level of consciousness to go about their work in a pragmatic and intelligent manner.
Now imagine that you are CTO of a new company and you are deciding between c# and f#. If you startup becomes successful, you'll have to quickly ramp up in hiring engineers. If your startup doesn't become successful, you'll quickly have to ramp up in having someone else hire you.
Assuming we are a rational person, that is we are doing a startup in the hopes that it will be successful, then our plans will facilitate the hiring of many engineers.
Fast forward to when we need to hire many engineers. Also, remember you don't have loads of time to spend doing this, because you're the CTO of a startup and you have shit to do. Also, remember it's hard for startups to hire because 1) risk and 2) you aren't google.
Now imagine taking your pool of candidates and reducing it by 99%.
In what ways in Thiel full of BS?
In what ways is this type of thinking myopic and detrimental?
In what situations would you advise someone not to spend their time working on the most important thing they could be doing?
For example, suppose the next most important thing for your business to do is to reduce marketing spend. you make that someone's goal, and that person focuses on reducing CPA for several weeks. obviously, you don't want this person to divert their time to answer support emails--you want them focused on saving your company boatloads of money.