About Focuses on Results
HBRI was reading a Harvard Business Review article, on lifelong learning, and more precisely on growing skills inside company. One of that skill is focuses on results.
Said like this, focuses on results can only be a good thing, but this reminds me some discussions with colleagues. What can be opposed to results, and as most tech people like do things right, what can be opposed to results and seems the right things to do.
Here are some oppositions developers face all the time.
- Make it work VS make it nice or elegant way.
- Rules are rules (like coding rules) VS sometime a simpler way could make sense.
- Best practice VS it depends.
- I will not do this, it’s not the art of doings things VS well, it works, I can live with that.
This reminds me an old conference about the over engineering on DRY concept. A brilliant talk from a Microsoft guy, taking example of a client asking for something that could open a can. Developers would build a giant knife that sure could open the can, but also do lots of other stuffs, but the only thing the client asked for was a can opener.
It seems like the question about focuses on result could be an idealist VS pragmatic question. It could even be swift to a quality VS quantity question.
I am not saying one is better that the other, but some compromise could be done. I know persons who really do not like do compromise on those subjects, saying that there is only one way, the good way, almost the “pure” way.
Well, “Focuses on Result” could seem straight forward, but it is not right?