Thanks for sharing. I'm having the same struggle and can really relate. I feel very lonely as a consultant trying to show a whole project how to be pragmatic and not only care about making better hashtables, but to actually care about the customer and the product as a whole. The funny thing is that some companies (generally younger and smaller ones) can be so very professional, while bigger ones house teams which are really stagnant and have a completely unrealistic view on software development. I suppose it's logical considering the "do or die" situation that most startups are in, but its sad to see these money black- holes thrive within large organisations.
The right balance between technical and pragmatic is project specific. Here are a couple of heuristics I use to find it.
1) Minimize the overall time investment required to have an acceptable solution to the problem. Time investment includes maintenance and debugging.
2) Make sure the marginal benefit to additional time spent in one area of the project exceeds the opportunity cost of focusing on other areas. E.g. It's good to spend a lot of time on getting the overall architecture right but it matters far less to optimize the business logic (for one thing it tends to change more often and for another it's hardly ever the performance bottleneck).
6 comments
[ 2.8 ms ] story [ 34.2 ms ] threadIt's not a black or white issue like pregnancy.
It's possible to be pragmatically technical, and technically pragmatic.
It involves building discipline, from being burnt from over-engineering or trivializing matters. That's all us, no one else.
1) Minimize the overall time investment required to have an acceptable solution to the problem. Time investment includes maintenance and debugging.
2) Make sure the marginal benefit to additional time spent in one area of the project exceeds the opportunity cost of focusing on other areas. E.g. It's good to spend a lot of time on getting the overall architecture right but it matters far less to optimize the business logic (for one thing it tends to change more often and for another it's hardly ever the performance bottleneck).