I think there are two mind sets when it comes to programming, those that relish in learning every detail in a particular technology and those that find beauty in simplicity.
(technically there is probably a third which is just a hack).
I don't think that these two programmer see eye to eye. One looks to apply the chains of functions to a problem to simplify the task at hand. While the other looks to creatively attack the problem with a minimalistic approach to writing code. They find beauty in recursion and abstraction, through interfacing things so that common logic can provide different results based on plug-able interfaces.
They are different mind sets entirely, where one looks to reuse existing library code the other looks to not write as little code as possible through creativity. Both are very valid programmer types and both can achieve mastery, it is more just a matter of how ones mind works. I myself am the latter, I love abstracting problems away till they just seem to disappear. I love closures and delegates, interfaces and anonymous functions. These are my utensils of mastery.
One thing I have noticed though is that programmers tend to work better with other programmer of the same type. For most of my career I have worked with the same development team. Many of the guys I trained and then they trained others. We are like a caravan of programming gypsies one of us would find a position at a start-up or find backing and the rest would follow in time.
Anyway, after the sale of the last company we where at I had to go out and find a real job. I did, and the entire team was of the other type it seems that they had amassed in a similar fashion as my group of developers and ended up there. Anyways, I have to say, for the first time in my life I was a drag on the team it just seemed that my code and their code just never jived, i mean it all worked properly but when I would have to work on one of their code or they would have to work on my code it was just hours of lost productivity. I eventually resigned because it was clear that for the first time in my life I was not working out as a developer. I was just mediocre at doing it there way.
Anyway, just food for thought, maybe you are like me Daniel and see the elegance of code. While the other guy sees the robustness.
"I think there are two mind sets when it comes to programming, those that relish in learning every detail in a particular technology and those that find beauty in simplicity."
These don't strike me as conflicting traits.
I can love succinct solutions and still like knowing minute details about what I'm using. (It seems like a requirement for the best solution).
(You need these traits if you want to 'hack/kludge' in changes to an existing (ugly) system without breaking it; so you can be a terrible hack too!)
You would have to provide a proper definitions of simplicity, beauty, etc.
"I think there are two mind sets when it comes to programming, those that relish in learning every detail in a particular technology and those that find beauty in simplicity. (technically there is probably a third which is just a hack).
I don't think that these two programmer see eye to eye. One looks to apply the chains of functions to a problem to simplify the task at hand. While the other looks to creatively attack the problem with a minimalistic approach to writing code. They find beauty in recursion and abstraction, through interfacing things so that common logic can provide different results based on plug-able interfaces."
You've essentially just described the difference between a left-brained person and a right-brained person, although I'm not sure this has much to do with whether you like using libraries or not.
Left-brained people use the language centers of their brain more heavily. That's why they spend so much time trying to come up with the right names, adding comments, and adding documentation while ignoring useful abstractions.
Right-brained people build instinctual models in their heads. That's why they spend so much time thinking out interfaces and how things fit together and so little time thinking about the semantics.
The only thing I'd be careful of is in using terms like "simplicity", "creativity", and "elegance". The left-brained guy thinks his code is just as simple, elegant, and creative as the right-brained guy thinks his is. The difference is what they're measuring these things by.
In general, I think the ultimate goal is for these two types to learn working together. That can be a very great thing for a team, but can be fairly frustrating.
I don't think that these two programmer see eye to eye. One looks to apply the chains of functions to a problem to simplify the task at hand. While the other looks to creatively attack the problem with a minimalistic approach to writing code. They find beauty in recursion and abstraction, through interfacing things so that common logic can provide different results based on plug-able interfaces.
They are different mind sets entirely, where one looks to reuse existing library code the other looks to not write as little code as possible through creativity. Both are very valid programmer types and both can achieve mastery, it is more just a matter of how ones mind works. I myself am the latter, I love abstracting problems away till they just seem to disappear. I love closures and delegates, interfaces and anonymous functions. These are my utensils of mastery.
One thing I have noticed though is that programmers tend to work better with other programmer of the same type. For most of my career I have worked with the same development team. Many of the guys I trained and then they trained others. We are like a caravan of programming gypsies one of us would find a position at a start-up or find backing and the rest would follow in time.
Anyway, after the sale of the last company we where at I had to go out and find a real job. I did, and the entire team was of the other type it seems that they had amassed in a similar fashion as my group of developers and ended up there. Anyways, I have to say, for the first time in my life I was a drag on the team it just seemed that my code and their code just never jived, i mean it all worked properly but when I would have to work on one of their code or they would have to work on my code it was just hours of lost productivity. I eventually resigned because it was clear that for the first time in my life I was not working out as a developer. I was just mediocre at doing it there way.
Anyway, just food for thought, maybe you are like me Daniel and see the elegance of code. While the other guy sees the robustness.