Helping my students overcome command-line bullshittery (2014)

I don't see it as an issue of respecting other developers based upon their preferences. I don't care that much about mere preferences. But I do think there are consequentialist downsides to promoting a situation where people are incentivized to stop feeling curious about reductionist understanding of many things. I also think it's fairly obvious at this point in history that endeavors which are correlated with good financial outcomes are often not correlated to outcomes that are widely agreed to be "normatively good." You can make even more than your example front-end devs if you're willing to sling 25-year-old C++ to incrementally maintain some monstrous business reporting and compliance system in an overtly corrupt bank. It doesn't mean we should (or shouldn't) see such a career choice as a generally "good" thing, or that the market forces of the world superimpose to produce that as a lucrative employment option at all should be seen as a good thing about the world's market forces.

I think your question is a bit too vague for me to be very interested in it. "What motivates me" probably changes based on how hungry I am, and there are super basic answers like "I happened to be good at math" that can better explain most of my motivation than some wistfully self-reflective assessment.

But, if I someone pulled a gun on me in a darkened alley and made me answer, I would say that my motivation to be interested in tech is that you can create so much with it, and I like working in a creative/design-space capacity, and I don't have any natural talent for other forms of compositional creativity like writing or music.

There are certain other people whose respect and thoughtful opinions I value (I doubt any of them would choose to work for Google, at least not modern Google), but I want to retain independence of thought too and I don't mind if pushes me slightly along the Martin Gardner "hermits and cranks" spectrum.

I do care about financial success, but only because I've been dealt a harsh set of external responsibilities in life and I don't feel I have much choice but to use whatever talents I have to claw out of that. That being said, though, in the two most lucrative and status-gaining positions I've had, I couldn't stomach the office politics and the way that arbitrary political and status signaling consistently overruled evidence-based pragmatism, and I quit those jobs despite putting myself in extremely risky financial situations both times. I can't say for sure, but I think if I had to face those situations again, knowing what I know now, I still would quit, and possibly would have quit even sooner.

But if I had to say one specific thing that is the motivation, I would say it is that I want to personally feel a sense of pride and craftsmanship in my work. When I solve a business problem by writing software, I want to feel like the way I solved it was full of craftsmanship, in addition to feeling proud of the final product. The manner in which I work is very important to me, perhaps much more important than the actual tasks that comprise the work itself.

Most tech jobs are horrible from this point of view because the only aspect of the job that can be consistently micromanaged from an outside point of view is the manner in which the work is completed (use this tech stack, log progress in this Agile/Scrum software, etc). You can't yet jack into a programmer's brain and micromanage their approach, from a creative point of view, so middle managers settle for micromanaging the outward appearances of how work gets done.

I could speculate too much, and too incoherently, but I think my comments about how we're teaching people to fundamentally value thinking about component abstractions more than reductionist understanding of atomic units relate to this, and go along with efforts to commoditize software labor. My preference is that this should be stopped. One way to help stop it is to lobby for valuing low-level understanding and fundamental curiosity more than, say, which kind of programming has the highest paying job openings right now.

right, but it needs to be done again by the single person maintaining the automation tools, who presumably is more of the "programmer" than "user" inclination. everyone else in the lab benefits.

>The people who make the most (founding CEOs) often have the wimpiest coding skills of all. What makes for a status hierarchy where the closer to the machine you are, the higher the status?

Continuing your analogy a bit further, we can say that many politicians (dictators) make much much more than most founding CEOs and they have the wimpiest of wimpiest coding skills of all! I mean, we must not confuse between the ability to make more with ability to tackle technical problems. Regarding the status hierarchy, we can see that Nicola Tesla was certainly very closer to machine as compared many people, surely he has a very high position in the status hierarchy than most of the run of the mill founding CEOs with wimpiest coding skills.

if i could sum things up, basically the author views the actual research/prototyping as the largest value the students can provide as opposed to becoming skilled systems programmers, i think it makes a lot of sense. a lot of counter-arguments seem to be in favor of putting those students through their paces in a bootcamp style of fashion where they struggle and learn about the intricacies and nuances of command line tools and development environments before they actually start writing programs, also a fair argument. however, i see the two arguments as orthogonal, his goal is to produce research scientists that discover new algorithms and new areas of research, not software engineers that work necessarily at twitter or facebook, etc. for the author, i suggest using some tools for building reproducible development environments like vagrant (mac os x). for things like command line option permutations and drudgery, perhaps creating some wrappers, scripts, or tools to automate some of these steps would be worth the investment and potentially a one time effort, it seems that copy/pasting scripts seemed to help. often times things are created out of necessity, frameworks or higher order tools evolve out of these things. at the end of the day, developing software should evolve, just like languages, where you have higher order languages that start to remove the lower level details and complexities so that you can focus on the bigger picture (e.g. java, springsource, jquery, cloud foundry, etc).

for the record, i went through all the bullshittery at one point in my career, and don't regret any of the countless, mind-numbing hours spent trying to figure things out, but i don't work in the field of direct research.

You can't teach someone to read or write without learning the alphabet.

The command-line is the alphabet. You may have flowery notions of the wonderful poetry you're going to write, but if you can't spell a word the real bullshit is to think you're an awesome poet in the first place.