[angersock]

A lot of the problem is the sort of Morlock/wizard reputation engineers have built for themselves--we are the magic fingers that make the magical machines work, and woe be unto those who would pry into our secrets. We make a bunch of theatrics about learning to program and code, but in doing so only cement in the notion that it is somehow an unnatural act, not the logical extension of communication and problem-solving we all know it to be.

So, of course, we're an other--and in a business sense, that means we're less likely to be brought in for business decisions and less likely to be trusted when we give feedback and honestly less likely (due to time spent with an orderly worldview and fairly deterministic systems) to have useful perspectives on how to do conduct sales or marketing.

And that sort of thing means that, when it's time to talk equity or raises or whatever, we're at a disadvantage: we don't even see ourselves as normal employees subject to the same progress of Labor that everyone else at a company might enjoy, and they see us as magical unicorns that get treated differently (and can be taken advantage of). You'll note in my language here a strong us-vs-them streak, which somewhat underscores my point.

I think one of the biggest issues of respect is that there is something different about writing software than making physical things on an assembly line: if I write, in three months, a VBA/Access line-of-business package that the folks sell for the next four years unchanged, I feel that I deserve a different sort of compensation than if I did phone support/data-entry for the same functionality for those same four years.

I think part of the issue is that we understand that, if well done, software can be reproduced for free and yield dividends far out of proportion to the invested effort: as such, it seems only right that we take a more equity-focused approach. At the same time, because we are an "other", we're less likely to be trusted with that sort of situation (a problem I face even now at my current company).

Lastly, we have a sort of weird ongoing psychic trauma as we work on these things--we feel the effect of every hack put in to make a deadline, every corner cut to satisfy a weird business use case, and every test left unwritten because goddamnitthishastobedonebyFridaythatsthelaunchday. It's a level of madness that, if you're not an engineer, you don't appreciate...and then you wonder why your engineers start jumping ship and you can't find new or good coders.

[ipsin]

I'm curious about what you mean by the theatrics of learning to code.

I like to present coding as "a thing you could do right now if you wanted", but I also think it's important to not describe it as easy, because that's frustrating to those trying to learn.

Your Morlock/wizard comment is what scares me about the traditional office environment, because I suspect that's the actual situation.

I had a friend who said I should come work at the phone company because "I'd be the smartest one there".

First, I wouldn't be, and second, "you're the smartest one there" sounds like a succinct description of hell.

[angersock]

So, the theatrics--and I say this like I'm not about to go out in 3 hours and do volunteer work perpetuating the problem myself!--are that somehow coding is any bit different from just breaking a problem into small, solvable pieces and then explaining to somebody else (in our case, usually, a computer) how to step through those pieces.

The theatrics are things like talking about whatever language is hot (doesn't matter), whatever language is fastest (doesn't matter until later), how important it is to learn to code (it isn't, except it really is), how important it is to get subpopulation X into the industry (I'll explain more in a second on that), how "not scary" things that look "scary" are, and so forth.

In some ways, I feel that we put so much an emphasis on learning to code and making it accessible that we forget that it is a skill that is ultimately vocational and practical--it's not snowflake work, it's done to solve a problem. I fear that in our eagerness to make things more accessible we're yet again making our field out to be somehow special enough to warrant that different treatment.

I'd much prefer that we treat it as "this is how you solve a problem", or "here's a cool thing we can do", or anything that's just more understated and chill than how we seem to go about it.

A special note about the "making it more attractive to subpopulation X":

(I'm going to choose X = ciswomen, because that's what I've got the most experience with)

Friend went to Chile and while there helped out at an "introduce women to computing" event, of the same sort he and I volunteer at here stateside. He reported (as memory serves) that the attitude there of the women was "Oh, okay, new thingy, cool!", whereas at our events here it's usually "Oh, computers/programming isn't really a girl thing, so we're trying something foreign and maybe a little uncomfortable but fun".

I've even seen--much to my chagrin!--women helpfully setting double-standards that serve to undermine their peers when new to the field. At one of our recurring events, somebody who had some experience (hard-won, former non-tech background, got in by way of blogging and SEO, now doing Python) was trying to explain to one of her neighbors that "Oh, well, if you're a girl, you probably haven't seen this before, right angersock?". I was quite flummoxed. The problem there was that she was giving her peers the mental out of "Oh, another woman had problems with this--so, it's okay if I have problems with it...it's not expected of us anyways". It's incredibly subtle and incredibly toxic.

By contrast, in Chile, my friend found that because the computers and internet and whatnot were (relatively) so new in their spread, everybody was considered a novice, and so there were a lot fewer gender boundaries inhibiting learning and exploration.

I am saddened everytime we present tech as something being new or novel or "something to be made easy" because I believe that in doing so we perpetuate the idea that programming has to be hard or that it is some sort of optional skill. Ideally, it should be something like riding a bike or sex--you know how to do it, everybody kind of knows how to do it, and maybe you end up doing it every day with people you enjoy the company of.

[mikegioia]

This is absolutely great and 100% on the mark. I especially agree with "we feel the effect of every hack put in to make a deadline". It's almost a relationship you can develop with the codebase; you can spend so much time in there that it begins to mean more. We finally removed a section of ugly code that's been in the system for over 2 years and I'll tell ya, I felt emotionally uplifted after it, as if a weight had been removed.

[michaelochurch]

Perhaps 10% of managers and executives are talented and worth a damn. The other 90% are really good at playing politics and externalizing costs. Technical debt is a great way to externalize costs, because the ones who suffer are usually late-coming maintenance engineers (who tend to be juniors, with no credibility).

Middle management (MacLeod Clueless) used to be the bilge pump system of the company. It cleaned up messes made above by self-dealing executives (MacLeod Sociopaths) and from below by checked-out subordinates (MacLeod Losers). Now, that function is being pushed increasingly to tech. We're what self-dealing HR thugs and narcissistic executives externalize their costs into.