Human words are a great deal fuzzier than the concepts they hope to cover. For instance, consider the word "love"; it means anything from stalker-level obsession to a moderate preferance ("I love pizza!"). In order to talk about anything precisely it is often necessary to specify what a given word refers to in some specific context.
Every writer has the right to choose what definitions they are using in a particular bit of text. If they say that they have chosen a particular definition of "love", that is not a point that can be usefully debated. Definitions are neither right nor wrong. They are only useful or not useful. What can be debated is statement the word is used to make.
In principle, one could have two people debating with each other, each choosing a very different definition of love. There is nothing wrong or illogical about this, except that it may be confusing.
This is my generic disclaimer I offer when choosing a definition:
- I am not saying this is the only definition. (If that were the case, I would have had no need to be clear in the first place.)
- When I've chosen a particular definition and then start talking about it, I have done so precisely because there are conventional meanings of the word for which my statements do not apply. If that were not the case, I would not have had to be specific. If I choose to talk about "stalker love", then I say "Love is evil", clearly I'm not claiming all love is evil.
- I am not saying you must use this definition for any purpose. Those if you wish to disagree directly when I've used a definition, it would be somewhat simpler to use the same one as me if you can, and failing that, important to be clear about your own use of the term lest everyone become confused.
When I was younger, I thought leadership was oversold, and what really mattered were the people on the team.
I have recanted this belief.
I still don't entirely understand why leadership is so important, but the experience I've collected over the years is pretty clear on the matter. My best guesses are that it is some combination of the following:
- It is true that the performance of a team is bounded on top by both the quality of the team and the quality of the leadership, but people tend to badly underestimate how much quality and talent there is in the world. The average person is above average in some significant way. I would agree world-class results require a world-class team, but for a given team, it's a rare time when the biggest problem the team has is a true lack of talent. I'm sure it happens, but I've never witnessed it in 15 years, whereas I've witnessed many teams failing to live up to their obvious potential because of bad leadership. So, in a sense it is true that neither leadership nor team talent is more important, but in practice, since team talent is generally a given the leadership will be the most important determining factor between failure and success.
- It is true the team is who provides the day-to-day progress on a problem, but it's generally the leadership making a lot of little decisions that add up over time; little words that affect morale, small key decisions that affect efficiency by a few percent, that little bit of vision-from-experience that avoids blowing a few days on a bad path, the careful selection of problems to personally take on. It adds up to a lot, and especially when the leadership is blowing these little calls consistently, no team is good enough to undo the damage... especially when the leadership actively prevents the repairs!
I do agree that it's important not to fetishize leadership and never to forget the team gets credit too, but over the years my estimation of the importance of true leadership has been going consistently up, not down.
A fixed up version of this post of mine.
It's time for gas stations to drop that nine tenths of a cent off their signs.
Learn You a Haskell for Great Good! (A Beginner's Guide) by Miran Lipovača, published by No Starch Press (2011). No Starch was kind enough to send me an advance copy for review.
Haskell books for "real programmers" are still thin on the ground, being limited at the moment to Real World Haskell (2008) and possibly Programming in Haskell (2007). As its introduction states, this book is aimed at existing programmers who are currently fluent in something like Java, C++, or Python, and would like to learn Haskell.
I put my take on the traditional discussion of why you should consider learning Haskell in another blog post, so we can get on with the review here.
The hardest thing about learning Haskell with no previous functional experience is bootstrapping the strong foundation that you've long since taken for granted in your imperative language. If you don't have this strong grasp of the fundamentals, then every line of code is an invitation to get stuck on some subtle issue, and you'll never have the fluency that great work requires until you have that foundation.
This book is the best way I know to obtain the Haskell foundation you need for fluency.
No Starch Press asked me to write a review of the new Haskell book, Learn You a Haskell for Great Good!. I started to write a section about myself and my view of Haskell for context, and realized that it really needed to be its own post as it grew to a length where it was self-indulgent to make it part of the review. But it fits as its own post nicely.
| Past Posts -> |
