4 ms·
Simply because it's never a case of spending "a few extra hours" when learning and evaluating a new tool. There are many "unseen" hours in troubleshooting, monk
by psycr 13y ago
Simply because it's never a case of spending "a few extra hours" when learning and evaluating a new tool. There are many "unseen" hours in troubleshooting, monkey patching, and re-evaluation. These are real costs that can be avoided by defaulting to known best practices (at the expense of ultimate performance).
- simondlr 13y agoWorked with friend on a new idea (while also trying new tech across the board), ended up in this: http://simondlr.com/post/26360955465/dynamodb-is-awesome-but http://simondlr.com/post/26360955465/dynamodb-is-awesome-but When we got traction, we wanted to change databases, but because it was just a weekend hack no one wanted to spend time doing it and eventually killed the app. It was our own doing of course (choosing new tech to work with). But yes. Work with what you know when testing ideas, unless you also want to play with new tech.
- threeseed 13y agoRight. So then the mantra should be "pick the technology stack you know best" as opposed to "don't obsess about performance". They aren't the same thing.