3 ms·

I think this phenomenon is an artifact of the media that we as programmers consume. The easiest way to become an programmer celebrity is to build tools (languag

I think this phenomenon is an artifact of the media that we as programmers consume. The easiest way to become an programmer celebrity is to build tools (languages/frameworks/etc.) for other programmers. Many programmers of equal skill are out there programming to solve actual problems, but the HN sphere and like are awash with people programming on programming itself. Which, while is surely intellectually stimulating, does seem a bit 'meta' and removed from why we're all doing this in the first place. But people who work on programming tools get the most press because those topics appeal most broadly to the audience of their peers. Then people in that audience see those topics as 'hot' and focus their energy on them. It's a reinforcing cycle. It reminds me of the ideas in this article: http://slatestarcodex.com/2014/12/17/the-toxoplasma-of-rage/ http://slatestarcodex.com/2014/12/17/the-toxoplasma-of-rage/

oinksoft 12y ago
> programming on programming itself ... does seem a bit > 'meta' and removed from why we're all doing this in the > first place. I heartily disagree, and think that tools vs. "actual problems" is a false dichotomy. Software design/engineering is very much its own discipline. A good API/framework/whatever can lower defect rates and generally make your software more coherent and maintainable. That saves time, money, and headaches. We should absolutely care about the tools we use, because nobody else is going to, hence "programming on programming." Attributing that to a quest for "celebrity" is cynical, and I don't see how you can blame programmers for seeking a good professional reputation by creating tools for their peers.
deleted 12y ago
[deleted]
SiVal 12y ago
I teach my kids that the systems they are programming should be considered onions of abstraction layers. They need to understand how to choose from among the options available at each level and to realize that those options are constantly changing. This onion is the only way we can deal with the ever-widening diversification and combinatorial explosion of hardware platforms, communications channels, types of users, geographic dispersion, data sources, problems to solve, etc. Improvements at one layer demand adaptations at another; accumulate enough options at one layer and you need to encapsulate them in another. And the bigger these onions get, the more leverage they provide to anyone who uses them, meaning any improvement you make to some part of the onion is contributing to solving a thousand, or a million "actual problems" simultaneously. If solving end-user problems is "why we're all doing this in the first place," a toolmaker who can solve 50% of each of a million different problems simultaneously is contributing more than those of us who solve the remaining 50% of just one.

oinksoft 12y ago

> programming on programming itself ... does seem a bit > 'meta' and removed from why we're all doing this in the > first place. I heartily disagree, and think that tools vs. "actual problems" is a false dichotomy. Software design/engineering is very much its own discipline. A good API/framework/whatever can lower defect rates and generally make your software more coherent and maintainable. That saves time, money, and headaches. We should absolutely care about the tools we use, because nobody else is going to, hence "programming on programming." Attributing that to a quest for "celebrity" is cynical, and I don't see how you can blame programmers for seeking a good professional reputation by creating tools for their peers.

deleted 12y ago

[deleted]

SiVal 12y ago

I teach my kids that the systems they are programming should be considered onions of abstraction layers. They need to understand how to choose from among the options available at each level and to realize that those options are constantly changing. This onion is the only way we can deal with the ever-widening diversification and combinatorial explosion of hardware platforms, communications channels, types of users, geographic dispersion, data sources, problems to solve, etc. Improvements at one layer demand adaptations at another; accumulate enough options at one layer and you need to encapsulate them in another. And the bigger these onions get, the more leverage they provide to anyone who uses them, meaning any improvement you make to some part of the onion is contributing to solving a thousand, or a million "actual problems" simultaneously. If solving end-user problems is "why we're all doing this in the first place," a toolmaker who can solve 50% of each of a million different problems simultaneously is contributing more than those of us who solve the remaining 50% of just one.