Comment by eldavido
8 years ago
I know this was half in jest but it speaks to a larger point, that of the "implementation ghetto".
I'm going to get a lot of pushback for saying this, but there are basically three roles in any company: (a) people who do the work, (b) people who make sure the work gets done, and (c) people who decide what work to do.
If you follow the strategy outlined above, you will never rise beyond a pure implementer of someone else's vision.
Empirically, understanding more about the business domain and industry seem to be important if you want to do (b) or (c). If anyone has more tips, I'd love to hear them.
EDIT: When I say "above", I'm talking about in the comment two levels up, not the article.
You missed the step of "understand why each technology exists."
If you understand why a technology exists you are gaining an understanding of problems, and after repeating a few times over a decade you may see patterns in problems that are being solved.
It's easy to mock "AbstractSingletonProxyFactoryBean" but whoever created it was not being wholly onanistic, and if you can't understand why it was created, you are going to be in trouble if you ever create your own framework.
I dunno, this seems almost like what those with vision do. They have a high-level understanding of what's cool and hip and what "should" be used to solve problem other people have had and they think that they can just copy paste it onto their own problem. Then the people who actually have to do the implementation are constantly questioning/regretting, "why was this decision made?"
I'm not sure it's something that can be filtered for, but I don't want to work in an org where technical decisions are made by those who's hands aren't dirty.