In my experience, there is a thin line between "blameless" cultures and "responsibility-less" cultures. Blameless cultures accept that we are all human, make mistakes, have off periods, etc. "Responsibility-less" cultures are as you describe -- they eschew honest conversations about the actual forces that affect projects. Instead they tend to repeat the same process discussions ad nauseum, typically discussing symptoms rather than the actual causes.
Since we as humans often prefer to avoid conflict (sometimes at all costs), it's not uncommon to see companies tilt towards the latter. This is exacerbated in "scale up" environments when rapid personnel changes make it difficult to build the kind of trust necessary for direct, honest communication.
> One sort of answer would be how people are convinced that their data is not important.
When I'm wandering through my yard watering plants, I like to imagine a world where our personal data, or more precisely access to it, is treated more like mineral rights today.
Companies would be required to pay a small micro-payment royalty anytime your data was used to make them money, and you would be able to transfer/split the rights just as you could mineral rights today. This micro-payment world would supplant the current "your data is the price of admission" world we live in.
We do not live in a "your data is the price of admission" world. We live in a "your data is extra gravy we monetize for free because in small quantities it is useless to you but in aggregate it has value so we will extract that value even if you've already paid for the product and legally own it"
While not limited to the Soda industry, this sentiment is expressed pretty vividly (even comparing testimony, marketing etc.) in the documentary Fed Up[1]. Worth a watch if this sort of thing is interesting to you and currently available on Netflix.
In all fairness, it makes it pretty tough to take your comment seriously when you consistently refer to Rails when you mean Ruby.
Also, I have to disagree. Like the author of the post, I found Olsen's book to be a delightful read. It is certainly not a great "first book" on Ruby, however. I think you ought to read it once you've gained a little better understanding - its wonderful for smoothing out edges and cementing some of the more advanced concepts.
Good point with 'Rails'—my mistake—and I understand that now my competence could be questioned. I meant Ruby of course (which is Rails' core and if you got Ruby well you are a much better Rails dev and I think that's the #1 reason when reading Ruby books => Rails).
I appreciate the author and his work but frankly: I got so frustrated with the style. Go and read chapter 13 and compare all the blog posts about Singleton out there (it's a huge difference). Reading one chapter again and again just to see that someone on StackOverflow drew a far better picture doesn't make you happy. Or take the next chapter 14 about class instance variables: this topic is brought to the reader in a very verbose style and again, the net full of blogs and Q&As deliver better much results. People there even discuss and question the benefit or real-world usage of class instance variables which is fully omitted in the book.
>> its wonderful for smoothing out edges and cementing some of the more advanced concepts
Sorry, I totally disagree, especially the advanced stuff is delivered in better quality in the net. Don't get me wrong but your words sound like the typical not-helpful Amazon reviews (which made me buying this book). BTW, there more annoying parts like squeezing every subject at the end of a chapter in a monotone structure ("Staying out of trouble", "In the wild", etc.) which is getting boring quickly, doesn't give one a better understanding and feels like the author going through his checklist for every chapter.
According to an Oct 2011 answer by Zach Holman on Quora[1], they only release publicly the number of users. According to the homepage, that number is currently at 1,455,656 (hosting 2,444,052 repos). You could extrapolate from their with an average repo size, but I haven't seen any good information on what that size would be.
It's not impossible to remain a creator while using an iPad (or other tablet) - at least not when it comes to development. There are certainly people who are happily developing on an iPad (albeit with a more powerful remote backend)[1]. I think we are likely to see even more of a shift in this direction as these devices become even more capable.
Ok, granted, it seems to work but when you look at the configuration:
iPad 2 (16Gb, WiFi)
Apple wireless keyboard
Stilgut adjustable angle stand/case
iSSH
Linode 512 running Ubuntu 11.04
Apple VGA adapter
This is basically the same configuration as an iMac! I'll take an example, most of the programmers I know when doing some serious coding have 2+ monitors because it's always good to run on the side, get the result live. Or just because you need to compare two files. On such a small screen, it's close to impossible. Also for a programmer a lot of the wasted time is browsing through long files, with an ipad and, again, a small screen = nightmare.
This is just not really that serious. There is not going to be widespread adoption of serious programmers doing this in anger. I promise. It's not going to happen. It's fitting a square peg in a round hole. This attitude wants me to have this overly complicated setup to have a really horrible version of what I can do swimmingly well with a little Thinkpad or whatever notebook you like. Done and done. No nonsense.
Snide comments aside, I think you're missing a lot of value in slides 26 through 34, the section on communication. Reducing the 'spin-up' time for new employees and documenting even the one-off conversations seems like a great way to increase productivity.
User westiseast posted a blog post[1] about A/B testing a grid vs. list product displays on his online tea shop, Min River Tea, which lead to a pretty good discussion on the topic[2].
I sleep ~4 hours a night during the week. I find that if I sleep more (~6-8), I am not tired again by the time the remaining hours have passed and it is time for me to sleep again. For instance, when I sleep 6 hours, I am not ready to sleep again 18 hours later. This becomes a real problem after two nights or so, at which point I have a lot of trouble falling asleep.
I do tend to sleep more on the weekends, but I often end up essentially forcing myself to sleep come Sunday night.
Since we as humans often prefer to avoid conflict (sometimes at all costs), it's not uncommon to see companies tilt towards the latter. This is exacerbated in "scale up" environments when rapid personnel changes make it difficult to build the kind of trust necessary for direct, honest communication.