Yes, I agree. Like all things it's a balance. In looking to refine skills everyone will require tuning in different areas. A programmer may be great at writing code but often fails to identify re-use of libraries/patterns. Reading others' code and technical articles may assist him/her in developing in that area. Likewise you may be able to tell when a writer lacks a 'lumberhouse of books'.
Being aware of why you are not developing a skill is probably key -- review from others helps to provide insight into potential underdeveloped areas.
While reading helps to improve your understanding of what makes good writing, I feel writing regularly is more important. You need to learn to foster your own ideas through writing, being careful not to just think what others write.
"For ever reading, never to be read." - The Dunciad III
I'd also suggest a book to read on the plane: http://www.alaindebotton.com/the_art_of_travel.asp. A good read to explore some of the common, but not often openly discussed, feelings and responses people have to travelling.
I agree, this was a good comment and a nice followup to the article.
The use of the 'disagreeing with a commonly agreed concept' pattern, whilst useful, can be overused leading to discussions that get railroaded by blockers that gain credibility through the perception of being deep, simply for sake questioning.
Climate change discussions jump to mind here. 'Skeptics' ride on their ability to question fundamental and long-agree d concepts from the ocean and atmospheric sciences. They seem 'deep' in that they have questioned base concepts but in the end their argument is always flawed. Others who perhaps haven't the background or understanding don't see any flawed argument, just a 'deep' questioning of these concepts and thus gain some level of credibility. This can cloud discussions and create mis-information in my opinion.
Not in the context of other people (specifically non-Americans) trying to understand feedback. I find I can say something to an American that is "fantastic!" only to be told by a German "that it would never work". It just emphasises the need to get feedback from multiple avenues, ideally from people who have different world-views. Your example reactions to the three startups backs this point up.
Anyone know whether they used a documentation tool to generate the 'example on right' style pages? E.g. https://stripe.com/api/docs?lang=python#delete_customer. It's very clean. The general layout and feel of the API doco is great.
'...REST always been a part of rails?'
'...obsolete technology'
How is REST -- a set of architectural principles and constraints -- obsolete when you use it every time you browse to a web page? I feel people need to start treating REST more for what it is rather than an API or some library, or SOAP for that matter.
You need to manage your risk. Without a risk management strategy, failure is likely to be worse. Obviously a pilot won't blindly seek failure to improve (I'll head for that mountain to see how well this baby handles crash landing).
'...accidently...' - A lot can learnt (and mitigated against) from accidents.
I agree it's not black and white, but I think failure is more stark and thus sticks with us, helping us to grow.
I agree, I find his material very good. I think he has good timing and his voice is in no way annoying; something I often find off putting with audio CD's. He has a good ability to remove the 'mumbo bumbo bullshit' (as he puts it) and get to the core of what is important.
I also started with the Google tech talk and went on to his other work.
- Pretty sure it was Peter Norvig