3 ms·
Yes, 100%. One thing I've enjoyed so far about being a contractor (but not a consultant) is that even as a relatively junior developer, I get to see the dirty
by zacharyvoase 14y ago
Yes, 100%.
One thing I've enjoyed so far about being a contractor (but not a consultant) is that even as a relatively junior developer, I get to see the dirty internals of many different companies, and spot patterns between them. This is one of them.
I've been at companies that decided to switch to hot new NoSQL distributed fault-tolerant join-free key-value vector clock databases, when really they only needed to add a couple of indexes to a few heavily-queried fields. I've seen language switches and full re-architectures based on perceived performance problems, but the complexities of the new architecture made request latencies worse (c.f. https://en.wikipedia.org/wiki/Second-system_effect https://en.wikipedia.org/wiki/Second-system_effect).
The best approach I've seen so far is described as 'list, rank, iterate'. Profile your problems aggressively, rank the issues in descending order of importance, and greedily work your way down the list, fixing them.
- jiggy2011 14y agoIf there's one thing that drives me potty it's people who claim that mysql is too slow for their requirements (usually low-medium traffic website), then I look at their implementation and see no indexes on non primary-key fields. Before NoSQL was a thing, I saw people break their data out into 1000s of .txt files to get around this.
- cnvogel 14y agoThe single most useful thing to address perceived performance problems: Measure your performance. A often neglected part of the "list, rank, iterate" cycle is generating performance indicators that can be quantitatively assessed.