21–30 of 54 posts
> The engineer becomes a kind of nomadic hermit (“Principal Engineer”)
"hermit" implies some level of isolation. Is that really the case of distinguished/principal/fellow engineers? Is there any evidence or data available?
"By and large, programming is a young man’s game" As a middle-aged programmer who is a much better programmer now than I was when I was young, I'd argue with the article's initial premise.
The military is a "young man's game." Most new recruits are 18. But the people in charge, who do the strategizing and so on, are not. It sounds to me like the article is suggesting another way for experienced programmers to be held in high esteem, not suggesting that old programmers are no good. So I honestly do not understand most of the criticisms of this article being posted here on HN. Maybe there is no real diff…
You have older NCOs in the military as well as senior officers, but for the most part rank and seniority is a pyramid in the millitary; just like most hyper competitive dev shops...there are older people at the top, just much fewer of them than younger people...and where did the other people go who fell off the pyramid? As a PhD holding computer scientist and practicing researcher, I cringe at the title "software sci…
More so than in civilian life. The US military has a formal "up or out" policy and a schedule: https://en.wikipedia.org/wiki/High_Year_Tenure . That's for enlisted men. For officers, it's tougher, although more complicated; if you're passed over for promotion twice, you're usually out.
"By and large, programming is a young man’s game" As a middle-aged programmer who is a much better programmer now than I was when I was young, I'd argue with the article's initial premise.
"By and large, programming is a young man’s game" As a middle-aged programmer who is a much better programmer now than I was when I was young, I'd argue with the article's initial premise.
What do your younger colleagues think?
"By and large, programming is a young man’s game" As a middle-aged programmer who is a much better programmer now than I was when I was young, I'd argue with the article's initial premise.
Would such a person practice real science, or just apply the first test that cones to mind, and ignore all of the confounding factors?
>Statistical education. This is currently optional
The data world is going to be an interesting place in the near future, filled with people running statistical tests they don't truly understand, and drawing spurious conclusions. But, I guess it already works that way in some fields.
Earlier quoted context omitted.
You have older NCOs in the military as well as senior officers, but for the most part rank and seniority is a pyramid in the millitary; just like most hyper competitive dev shops...there are older people at the top, just much fewer of them than younger people...and where did the other people go who fell off the pyramid? As a PhD holding computer scientist and practicing researcher, I cringe at the title "software sci…
It's fine if you cringe. :-) I am just saying that I simply do not see the slam on older programmers that others seem to be taking away from this article. It seems to me there are plenty of older programmers on HN and some of most esteemed folks here are not 22-25 years old and are, instead, a good bit older (in some cases, old enough to have kids that age, in theory if not in reality). (In fact, I suspect none of th…
"By and large, programming is a young man’s game" As a middle-aged programmer who is a much better programmer now than I was when I was young, I'd argue with the article's initial premise.
Stupid, business-driven programming involves Scrum tickets and story points and production support rotations and 15-hour days. It's quixotic, obedient, and culturally charismatic (to non-technical people who think greatness is produced by renegade geniuses in garages) but vapid.
So, a certain type of programming is a young man's game-- insofar as anyone else would stick out as not belonging in an arena defined by quixotry-- but that's a stupid type of programming that involves (a) total subordination to the business, (b) extremely long hours and high stress despite mathematically insignificant incentive compensation (e.g. 0.01% equity slices), and (c) not very interesting projects, rendered intellectually challenging only because of the obscene deadlines, limited resources, and political roadblocks that sometimes lead to invention by necessity (but, more often, create kludges and frustration).