This week, all the blog posts and articles I read came from Pointer. I spent most of my free time finishing up the book Twenty Six Words (highly recommend!) and then starting Weapons of Math Destruction by Cathy O’Neil.
Questionable Advice: Can Engineering Productivity Be Measured?
Author: Charity Majors
The author answers a reader question about whether you can measure the productivity of an engineer using data and metrics. She gives a resounding no:
Your execs should fucking well know this: how would THEY like to be evaluated based on, like, how many emails they send in a day? Do they believe that would be good for the business? Or would they object that they are tasked with the holistic success of the org, and that their roles are too complex to reduce to a set of metrics without context?
This actually makes my blood boil. It is condescending as fuck for leadership to treat engineers like task-crunching interchangeable cogs. It reveals a deep misunderstanding of how sociotechnical systems are developed and sustained (plus authoritarian tendencies, and usually a big dollop of personal insecurity).
Love it! As an alternative, she suggests:
- Outcome-based management that practices focusing on impact, plus
- Team level health metrics, combined with
- Engineering ladder and regular lightweight reviews, and
- Managers who are well calibrated across the org, and encouraged to interrogate their own biases openly & with curiosity.
The team-level evaluation is important because individuals don’t own code; teams do. Leadership should be more outcome-oriented, Majors argues. “The harder the problem, the more senior the contributor, the less business anyone has dictating the details of how or why.”
Tech Sector Job Interviews Assess Anxiety, Not Software Skills
Author: Chris Parnin, Matt Shipman
The top paragraph:
A new study from North Carolina State University and Microsoft finds that the technical interviews currently used in hiring for many software engineering positions test whether a job candidate has performance anxiety rather than whether the candidate is competent at coding. The interviews may also be used to exclude groups or favor specific job candidates.
This is a summary of a paper, “Does Stress Impact Technical Interview Performance?", which compared whiteboard interviews in public (the usual technical interview setting where you have to explain your process out loud) and private (where they just had to solve the problem). The results were alarming; people did far worse on the private interview. And, in this study, all women who took the public interview failed, while all women who took the private interview passed!
This is good stuff. I’m glad to see this being studied more, because whiteboard interviews are a fucking nightmare. (One “benefit” of COVID, I guess, is that physical whiteboard interviews don’t exist. I bet the same applies to interactive coderpad / Google Doc coding sessions, though.)
How to Write Technical Posts (so people will read them)
Author: Sandy Maguire
The author provides guidelines for writing better, more engaging technical posts:
The value? You’ll make it easier for people to understand what you’re trying to tell them. Which is why you’re writing in the first place, right? The good news is that none of this is magic—just some simple guidelines for structuring your content.
The main principle is that you have to convince your reader that your post is worth reading, both at the start and continually throughout the post. Then, she argues, you have to understand how people read. They do this by skimming for concepts: “They’re looking for what you’re trying to tell them, as opposed to what you’re actually saying.”
Use short sentences. Structure your article with headings and leading sentences that make sense. Make your information easy to find as people are jumping around.
The takeaway advice from this essay is that if you want lots of readers, you must make it easy for them to read.
To that end, pay lots of attention to motivation. Why should people care what you have to say? What value does it give them?
Focus your energy on the beginnings—both of the essay as a whole, and of each paragraph. People who are unconvinced by your essay’s value will skim their way through it, and they will do that by reading only the beginnings of things.
This was helpful! For this site, I’m working on having a clearer, more unified voice. Posts like this teach me a lot.
Shorter articles
When your coworker does great work, tell their manager is a great (as usual!) piece by Julia Evans encouraging people to talk to a coworker’s managers when the coworker does something great. This can be great to highlight work not being recognized or make a promotion case. Evans notes to do this with permission, as the work may not be aligned with the coworker’s goals or something that they want to be known for.
What I like about this is it’s a way everyone can help their coworkers – even if you’re really new and don’t feel that qualified to comment on how effective someone more senior is at their job, you can still point out things like “this person helped me do a project that was really out of my comfort zone!”
Hashing It Out - a deep dive into Python dictionaries poses some deeper-than-surface-level exercises about Python’s dictionaries (hash tables) to experiment with them. Questions include:
- how does the size of a dictionary change as you insert keys? how does this affect insertion time? (A: occasionally, Python will double the size of a dictionary, and this doubling requires the entire data structure to be reallocated and copied.)
- what is the problem with an object whose
__hash__function returns a random number on every call? (A: if the hash value changes, Python will be unable to retrieve the object!)
And other thought provoking ones. Great stuff!