DEV Community

Heidi Waterhouse
Heidi Waterhouse

Posted on • Originally published at heidiwaterhouse.com on

Is this the gate you want to keep?

Today on Twitter, I said:

Guarded by succulents

That’s a lot of response for me. Like “Livetweeting @kelseyhightower” levels of reaction. So let’s stop and talk about that for a bit.

Honestly, I wrote the tweet because a group I respect put out a call for coders to help under-indexed coders do something that is entirely unrelated to coding, and I was frustrated.

Developers are not automatically the smartest people in any room, and I wish we would stop treating them like they were. It leads to all sorts of workplace toxicity. Yes, this is about the Google thing. And the Uber thing, and the thousand and one other sexist and racist things we could rattle off.

Certainly, deifying coding is a contributing part of coders acting like they’re little tin gods. Why wouldn’t they be cocky, if everyone they work with acts like their skill is all that keeps the company afloat? Heck, sometimes entire companies are “acqui-hired” just to get a functional team of coders – the supporting cast and the product are jettisoned, as if they had no value.

I’ve worked with several startups, and at a certain stage, investors stop asking about your coders and developers, and start making noises like maybe there should be a manager, or a financial officer, or a CTO who thinks strategically and not tactically. That’s because at some point, coders are people who exist to execute a vision, but somebody had better have a vision.

A vision isn’t just a rosy sales plan – it comes with understanding the industry, the problem space, the user experience, the way other people will see and use and touch the product. It comes with sales and marketing and QA and tech docs and support. If you are not actively courting the best support staff money can buy and paying them enough to show you respect them, you are, flatly, a fool. A good support person can make or break customer retention.

I know a lot of developers, and I mostly like them. They’re smart, and they sometimes have an amazing array of interests and passions, within and outside work. But they’re not magical. You can’t actually multiply productivity with them, and they won’t save your company. They can execute. The really good ones can execute and anticipate your strategy and build toward it. But developers don’t end up leading companies because they’re really good at Javascript. They end up in leadership because they didn’t let their coding skills be their entire definition. They worked on getting better at people, and meetings, and product, and even more people.

So every time you talk about teaching girls to code, or asking coders to help other coders with non-code stuff, or putting on a code school with no exploration of other aspects of software development, you’re saying that there is only one right way to be in technology. That is a narrow gate you’re setting up. I don’t like it. It makes me angry, and not just because I don’t code, but because it devalues the contributions of all the other people who make the magic happen.

It takes so much more than code to make a product happen.

Here’s to the PM who works hard to balance conflicting priorities and goes to dozens of meetings, to make sure things turn out as well as possible.

To the QA tester, who designs and runs endless tests in permutations you would swear no human would try, because there is no one more cynical about human intelligence than a tester, and they’re always right.

To the UX designer, who is so often dismissed as “making things pretty”, when they’re actually “making your product usable”. They run hours of human tests, watching and iterating until your product is almost invisible to the user.

To the writers, both technical and marketing, who spend all their time trying to figure out how to make the product real and relevant and useful to the people at the sharp end of the stick.

To the sales and marketing teams, who really do sweat the small stuff, who are actually kind of sick of fancy dinners and travel and airport seats, but who keep at it because they believe in this product and its ability to solve problems. Also sometimes they make us stickers.

To security, who may actually be the smartest people in the room, but have harnessed it all to righteous paranoia so that we don’t have to sit up every night worrying the way they do.

To support, who spend all damn day talking to people who are angry that something is broken, and still pick up the phone and say “How can I help you?” at the next call. They get everything from eyerollingly stupid user errors to actual arcane and intermittent bugs, and we expect them to know their way around our entire stack to troubleshoot. They know so much about the product and the customers, if only we ever asked.

To sysadmins, operations, cable pullers, and the invisible backbone of our infrastructure. We only notice you when things go wrong, but they go right so much more often, and we never notice the rough spots you sanded over already.

To finance and accounting and accounts payable and HR and company operations, who keep the lights on, and the fridge stocked, and who do get paged at 2 in the morning if the cleaning crew sets off the burglar alarm. I’m looking forward to the day I see an office manager tweet an #oncallselfie. They are amazing, attentive, organized, detail-oriented people, and I’m in awe.

To everyone who brings us food, cleans our toilets, vacuums at 2 in the morning, and otherwise lets us live like petty royalty – we owe you so much, and we are too self-conscious to even say thank you sometimes.

To management. Yes, management. Who go to so many meetings, you don’t even know. They’re out there making tradeoffs and calculations and doing the best they can with what they have and when you think about it, they have zero ability to make any difference in the product. All the responsibility, none of the power, at least in that direction.


The next time you hear someone talk about tech jobs as if they were all coding, stop and think a moment. I don’t want to devalue coding – it’s pretty cool. But I do want to pull all these other positions into the limelight of tech, and say,

“All of us make the product, and that’s awesome.”

This post was originally published on heidiwaterhouse.com

Oldest comments (22)

Collapse
 
ben profile image
Ben Halpern

Great post. I totally agree and I think you articulated it wonderfully.

Can I ask a tangential question? What, in your mind, is the "tech industry" and what is a "tech job"?

Collapse
 
wiredferret profile image
Heidi Waterhouse

If this were an easy definition, we'd have less confusion. I think the tech industry is people who are making software (for the most part) and web/app stuff. If you ask someone what their company makes, and they say "an app that lets you", they're in the tech industry.

Tech JOBS are much bigger, because there are coders, ops people, UX, DBAs, etc doing technology-oriented jobs in manufacturing, sales, insurance, transportation, etc.

That said, when we say "people in tech", we generally (and wrongly) mean "people who make the internet".

Collapse
 
ben profile image
Ben Halpern

we generally (and wrongly) mean

I'm satisfied by this way of saying it. I'm annoyed by some of the semantics in the same way I'm kind of annoyed by the word "serverless" in relation to that computing trend. But I also need to accept that's what folks settled on and language is hard to control.

Again, great piece above.

Collapse
 
robdwaller profile image
Rob Waller

Good post.

Do you think this can depend on where you're doing tech and code? Say a product company based in Silicon Valley vs an agency based in London?

Collapse
 
wiredferret profile image
Heidi Waterhouse

It can, but I've worked with people from New Zealand to Bangalore to Boston, and it's a pervasive theme. Better some places, worse others, but never great.

Collapse
 
antonfrattaroli profile image
Anton Frattaroli

I met a woman who was a QA tester. Together we made a 10x team. I married her. We don't work together anymore, but now my life is 10x for sure.

Collapse
 
wiredferret profile image
Heidi Waterhouse

A+ life choice.

Collapse
 
Sloan, the sloth mascot
Comment deleted
Collapse
 
weswedding profile image
Weston Wedding

You imply she is jealous, upset, or in denial. You make it personal.

You could have simply addressed her on a factual basis, but you decided to turn your response into a personal attack in many ways. Why is that?

Collapse
 
Sloan, the sloth mascot
Comment deleted
 
weswedding profile image
Weston Wedding

You made a neutral point about how software being developed literally couldn't exist without developers and that, therefore, there was a basis for valuing developers more than a manager. You made a rational argument.

That is a very different thing than going after her personally. Which is what you did by calling her jealous and upset and telling her she's in denial. All of these things which are entirely speculative and unarguably insulting.

Collapse
 
val_baca profile image
Valentin Baca • Edited

The original "x" was the worst developer and the "10x dev" was the best developer in comparison; on some metrics the best was 25x or 5x or 10x, so "10x" was chosen as a catch-all to indicate that there was an order-of magnitude difference.

Somehow in all the talk around the "10x dev" the "x" became morphed into the "average" or "mediocre" developer, which is just wrong.

The original study that found huge variations in individual programming productivity was conducted in the late 1960s by Sackman, Erikson, and Grant (1968). They studied professional programmers with an average of 7 years’ experience and found that the ratio of initial coding time between the best and worst programmers was about 20 to 1; the ratio of debugging times over 25 to 1; of program size 5 to 1; and of program execution speed about 10 to 1. They found no relationship between a programmer’s amount of experience and code quality or productivity.

Detailed examination of Sackman, Erickson, and Grant's findings shows some flaws in their methodology... However, even after accounting for the flaws, their data still shows more than a 10-fold difference between the best programmers and the worst.

In years since the original study, the general finding that "There are order-of-magnitude differences among programmers" has been confirmed by many other studies of professional programmers (Curtis 1981, Mills 1983, DeMarco and Lister 1985, Curtis et al. 1986, Card 1987, Boehm and Papaccio 1988, Valett and McGarry 1989, Boehm et al 2000)...
Augustine, N. R. 1979. "Augustine’s Laws and Major System Development Programs." Defense Systems Management Review: 50-76.

Boehm, Barry W., and Philip N. Papaccio. 1988. "Understanding and Controlling Software Costs." IEEE Transactions on Software Engineering SE-14, no. 10 (October): 1462-77.

Boehm, Barry, et al, 2000. Software Cost Estimation with Cocomo II, Boston, Mass.: Addison Wesley, 2000.

Boehm, Barry W., T. E. Gray, and T. Seewaldt. 1984. "Prototyping Versus Specifying: A Multiproject Experiment." IEEE Transactions on Software Engineering SE-10, no. 3 (May): 290-303. Also in Jones 1986b.

Card, David N. 1987. "A Software Technology Evaluation Program." Information and Software Technology 29, no. 6 (July/August): 291-300.

Curtis, Bill. 1981. "Substantiating Programmer Variability." Proceedings of the IEEE 69, no. 7: 846.

Curtis, Bill, et al. 1986. "Software Psychology: The Need for an Interdisciplinary Program." Proceedings of the IEEE 74, no. 8: 1092-1106.

DeMarco, Tom, and Timothy Lister. 1985. "Programmer Performance and the Effects of the Workplace." Proceedings of the 8th International Conference on Software Engineering. Washington, D.C.: IEEE Computer Society Press, 268-72.

DeMarco, Tom and Timothy Lister, 1999. Peopleware: Productive Projects and Teams, 2d Ed. New York: Dorset House, 1999.

Mills, Harlan D. 1983. Software Productivity. Boston, Mass.: Little, Brown.

Sackman, H., W.J. Erikson, and E. E. Grant. 1968. "Exploratory Experimental Studies Comparing Online and Offline Programming Performance." Communications of the ACM 11, no. 1 (January): 3-11.

Valett, J., and F. E. McGarry. 1989. "A Summary of Software Measurement Experiences in the Software Engineering Laboratory." Journal of Systems and Software 9, no. 2 (February): 137-48.

Weinberg, Gerald M., and Edward L. Schulman. 1974. "Goals and Performance in Computer Programming." Human Factors 16, no. 1 (February): 70-77.
Collapse
 
wiredferret profile image
Heidi Waterhouse

Thanks for bringing the footnotes. It makes my lapsed-academic heart so happy.

Collapse
 
weswedding profile image
Weston Wedding

I've poked around the Google for a bit and I'm having trouble really understanding what an "under-indexed coder" is.

Collapse
 
wiredferret profile image
Heidi Waterhouse

A person who belongs to a group that is under-represented in technology. If technology were really a level playing field, we would expect the representation of people of color, white women, disabled people, etc, to be about the same as in the general population. Since it's not, something is weird with both the pipeline and retention that is causing people to drop out at different rates. Many people prefer this to "minority", because, for instance, there is a tiny majority of women in the world, just not in tech.

medium.com/@duretti/how-to-get-eng...

Collapse
 
weswedding profile image
Weston Wedding

I understand now, thanks!

Collapse
 
codemouse92 profile image
Jason C. McDonald • Edited

...to content development, who has compiled a wordlist for our reading game that is rivaling most textbooks. (Seriously, I would NOT want the job of any of my company's content developers. I do not know how they do what they do.)

Great article!

Collapse
 
blaketweeted profile image
Blake Campbell

You bring up some really great points. Often when examining Tech companies people get overlooked for how valuable they really are to the success of the company. Cars are useless without key components, same goes for Tech teams.

If you are not actively courting the best support staff money can buy and paying them enough to show you respect them, you are, flatly, a fool.
I disagree with this statement because paying someone lots of money !== respect. Respect is more about treating them as a valuable member. You don't need the best team money can buy, you need a good team with great leadership.

Overall I think you did great on writing about the importance of the team as a whole! Looking forward to more from you.

Collapse
 
rhymes profile image
rhymes • Edited

I think the gist of what she meant was the following: you can think I'm valuable but if I, as an employee, can't make ends meet to reach the end of the month, you're telling me I am not valuable enough, and hence you're not respecting me enough :D

It's not about the absolute amount of money you pay yes, on that we agree, it's about being paid enough.

The same goes with the pay gap. If you have two people of different genders with the same skills and responsibilities and titles and one of the two is payed substantially less than the other you're not valuing both the same way. Even if to their faces you are equally nice and respecting.

The second the person less paid finds out is going to think you don't value them enough, and that's true.

I find very Basecamp's pay structure a very interesting experiment: m.signalvnoise.com/how-we-pay-peop...

Collapse
 
blaketweeted profile image
Blake Campbell

Yeah, that makes a lot more sense with that context.

Basecamp's pay is a great example of how compensation should be handled. I love how they pay the same regardless of location, that's amazing. Thank you for linking that!

Thread Thread
 
rhymes profile image
rhymes • Edited

Yeah Basecamp's strategy is very cool. The only minor flaw I can imagine is that people living in places in the world that are wildly more expensive than Chicago could be discouraged from applying but I reckon they are not that many and as you said, pay is not everything and Basecamp seems very transparent from day one ;-)

Collapse
 
wiredferret profile image
Heidi Waterhouse

Money does not substitute for respect, but it's a good proxy for how much a company values your contribution. Great leadership can only do so much about morale and retention in the face of knowing that you're paid half as much as the person on the other side of the room.