The Software Scientist
evanmiller.org
evanmiller.org
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.
It assumes that years of experience mean you shouldn't be programming. Which seems...odd to me.
Architecture requires experience. Writing the fastest quick sort in a given language is an exercise for fresh young brains.
I can't see the reasoning here. Surely it's a job for someone who has written previous sorting algorithms, understands the trade-offs between speed and memory, and understand the pitfalls that can be fallen into when sorting different kinds of data?
I don't think that's the angle the author was talking about.
He's actually saying this:
"By and large, programming (in terms in jobs/careers/economics) is a young man’s game"
The qualification I added in parentheses would be a fair reading based on his previous sentence: "...take a job as a software engineer."
Likewise, his 3 bullet points after the "young man's game" is about "jobs", not skill or intellect. Basically, it's about ageism in context of job slots.
Despite all the employment verbiage surrounding "young man", people are still misinterpreting it as:
"By and large, programming (in terms in intellectual ability) is a young man’s game"
Perhaps readers are too conditioned by the mathematician G.H. Hardy quote, "math is a young man's game"[1] in which he was talking about about intellectual output.
[1] http://en.wikipedia.org/wiki/G._H._Hardy#Hardy.27s_aphorisms
Readers might just be conditioned to taking things at face value.
The author's next blog post is titled Attracting Millennial Engineers - http://www.evanmiller.org/attracting-millennial-engineers.ht...
I can't tell if it's satire.
What do your younger colleagues think?
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).
Not to sound like a major kiss-ass or anything ;)
* "reduce career path anxiety" * "enhance engineering organizations' self-understanding" * "advance the general understanding of the right way to develop software" * "raise awareness about the sponsoring engineering organization" * "bring out some of those 'big picture' thinkers from the woodwork"
The third point is the only one close to the traditional role of a scientist, though "general understanding" takes more than data and statistics from a single organization. Otherwise, this seems to be a pretty blatant misappropriation of the name "scientist"!
In order to do a superlative job as a manager of a software engineering team, one has to master these same skills. Perhaps the term "Software Scientist" will help distinguish good software engineering management practices from bad ones, but I fail to see how "The Software Scientist" is not a management role.
The only way that the post makes sense to me is that if the organization is large enough, have a role that supports CTO / VPE's efforts and tried to do it in a more data-driven way.
So this way CTO / VPE still have those responsibilities, but have a person who is fully focused on measuring the impact of changes and getting data.
I think these would be very special roles and very few organizations, so not enough to really talk about it as an alternative to the two traditional tracks. That said, there is certainly there is value in this role.
Then, as the project matures you'll find that that gained speed comes at a price, a price that will sooner or later offset the higher wages demanded by the ones that are further along in their life (dependents, more aware of their value).
If there are young really good programmers (it does happen, I've met a couple) then they tend to be exploited even worse, they will end up creating a large amount of value for peanuts.
But that's rare enough that it doesn't change the situation too much.
So I don't see any inconsistency, it's just time shifted.
> 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?
Mgr: "We'll need $140k to get him."
HR: "The band for Senior Engineer is $100k to 125k."
Mgr: "So you can't do $140?"
HR: "Nope."
Mgr: "What if I hire him for a *Principal* Engineer position?"
HR: "I need to talk to the CFO about whether we need Principal Engineers.">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.
As a PhD holding computer scientist and practicing researcher, I cringe at the title "software scientist"....
(In fact, I suspect none of them are that young -- but I don't know all the ages of, say, everyone on the leaderboard, so I can't assert that as fact. Edit: Also, not everyone that age here can rightly be called a programmer.)
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.
What does this mean? Is software engineering "below" programming? Do software engineers write less code?
I've only been in the industry for a few years, mostly working on my own. I've assumed these titles were arbitrary. Are they not?
In my experience, while a software scientist or fixer is highly valued, they aren't necessarily highly paid moreso than anyone else on a team. Also, a technical lead is not always going to do this job or do it well if given it.
The largest part of development doesn't rely on someone with this specialization to write the initial code for any feature, yet without this skillset a team will ship some terrible code without realizing it.
I don't really see any group hiring for this kind of role.
As a side-point, I am often shocked that we don't see more research into how to make software teams more productive coming out of places like Google/Facebook/Microsoft etc, given that these companies (claim to) live and die by the effectiveness of their engineering. If a large amount of their expenditure is in software, to the point they'll buy entire companies just for the engineers, why aren't they financing the large-scale experiments that will settle certain questions for good?
When I worked at an investment bank, the code quality was crap, and the staff turnover was high. Didn't matter, because they literally had enough money to throw at the problem and keep hiring more people.
This said, I think that the "data science" title is silly. It used to mean "what we call machine learning to make it sound more practical and less AI-ish", then it meant "watered down job that occasionally involves running an off-the-shelf regression or clustering algorithm", and then it meant "any job that involves data". I don't hold out higher hopes for "software scientist".
We seem, in this industry, to have given up on restoring integrity to software engineering itself, so that everyone over 30 is strategizing to become some kind of XWP ("X Who Programs") rather than a JAP "Just A Programmer"), as I've discussed at length here: http://michaelochurch.wordpress.com/2012/08/26/xwp-vs-jap/ . We are so desperate to establish ourselves as better than "those programmers" who crank out Java classes and can't function without an IDE... and I understand this, because I don't want to be lumped in with them on compensation or autonomy. That said, I find it sad that we haven't managed to sell what we do (solve problems using software) as something with intrinsic integrity.
Because we've been raping the word "scientist" (e.g. "data scientist" for someone who worked with Hadoop once) for half a decade or more (and should really give it back to the people who have the right to use it) I would be more inclined to call myself a software strategist. Career-wise, I'm far past the level of the average engineer, and refuse to do (unless it's my own company, in which case I'll do the most undignified work just because it needs to get done) the sort of jobs that regular "software engineers" do in most companies (e.g. line-of-business Java-mines work) and I don't think of code as where I add value, but rather my knowledge about problem solving in a more general sense. I've probably evolved out of an engineering role (as defined by the business) and into that of a strategist who does some engineering and coding (especially because it can be a lot of fun). Of course, I'm hesitant to write a "software strategist" essay, because I don't want to see that title get mangled either.
Instead, you want the freedom to write code, but a job title that makes it clear that you don't have to write any code. If you're a data scientist or an architect or in R&D, you get this freedom. It's best, in sum, if you get to build things and solve problems by writing code, but aren't seen as a cog that can be plugged into any code-writing or -reading hole.