Hear, hear! Posted it as I've been raving about ion (particularly s-exp support) to non-amazonians, but credit goes all to them.
It's particularly interesting to see the fixes and improvements from the actual open source cleanup effort getting to (many) Internal production services.
I've read recently the book that the article references - Why Humans like Junk food - and it's a fascinating read - despite being poorly written.
Putting theories behind food appreciation, like Vanishing Caloric Density, the Umami flavor (MSG, garlic and Friends) and flavor familiarity (vanyloids are present in breast milk) - on the context of foods your familiar with, changes your perspective when you're tasting any kind of food, allowing you to deconstruct what are you experiencing: "Ho, I like this because it's greasy, and it salty, and it has loads of umami from the garlic".
It allowed me to deconstruct a common action, changing it from an immediate appreciation to a more rational, pondered thought process.
The application looks good with interesting articles at the time of writing.
As a note though, I opened the link because I thought it was related to Monocle magazine (http://monocle.com/) which also provides high quality content (albeit not community-sourced). Maybe reviewing the name is in order?
Starting by congratulating Tesla in their system, which should win some converts, but there's something bothering me with it.
An automobile network that's also owning their "refueling" network concerns me with the usual lock in concerns. What'd append when other brands want to offer the same service? A multitude of recharge posts all accross the land space each under their car brand flag? Figuring that there's only tesla and ford on this city, instead of the Nissan charging station that I need?
This particular solution seems very specific to Tesla (or even only model S), is there any standard or independent initiative for battery-exchange stations?
The point about prioritizing clearing road-blocks for your team cannot be underestimated, but, in my experience, with a serious caveat:
- Unless your SURE you have the time, do not put the technical task onto yourself, try to redirect.
I've made that blunder over and over again: saying "heh, I'll hack this little bit up tomorrow", and in the middle of planning, helping other people and so forth you postpone, losing the blocked developers attention and focus.
Other than that, great write-up on my job description :)
Cork allows some contact of the wine with oxygen, allowing it to evolve over the years.
For wines that lose their primary characteristic when aged (think fruity, fresh wines, normally whites) a screw top is the way to go, for something you want to keep in your cellar and let it evolve a bit till is just right, I'll take cork every day.
Throwing my 2 cents into the bucket:
I'm involved in a small embedded device project, where we wanted our UI to be completely decoupled from a legacy, very heavy, single-threaded component.
We decided to model the whole UI transition flow into DFA's, using events from the touchscreen (pre-processed) as inputs. The state machine is modelled with boost::statechart, which has proven to live to it's thread-safe reputation.
The jump in development speed and the absence of flow bug is nothing short of remarkable from this experiment.
Although I pushed for it, I was a bit fearful that the formality would make developers resist the architecture, but I'm pleasantly surprised the opposite has happened!
...but, we haven't launched yet, so, fingers crossed. :)
I agree with you to a point, but would maintain that a significant amount of behavioural and cultural data coming from the "5 button" research, would also apply to touchscreen devices.
>>> Nokia's software was good and competent, but they simply don't have access to the mountains of UX data needed to develop the next generation of OS's to compete on the touch screen.
This statement doesn't seem correct to me. Nokia has a vast amount of research on mobile UX, even from before Apple joined the play, probably as no one other company. As a (stellar) example, check out Jan Chipchase's work (http://janchipchase.com/) with a ton of in-loco research on mobile phone usage, and many research papers presented - with a particular focus on the non-developed world.
In my opinion Nokia suffered from big-company chronic slowness: the current cash-cow was still providing the income, hence all future investment was unfocused, under-funded.
PS: A nice question is still how much/if any of the investment of Nokia in the undeveloped world will still be able to bring some returns. Windows Phone completely eschews that...
Not panning this, but isn't this Mythical Man-Month's observation? That the communication overhead increase in adding team members grows -exponentially- quadratically with the number of developers?
(This does match my experience. 40+ teams simply accomplishing less and less than a very small, co-located or constantly in contact team).