Coders by Clive Thompson – Review – Part 1

I encourage every programmer to read Coders by Clive Thompson. This book captures how coders were first introduced to technology, then into a vast range of occupations, and how we got to where we are now.

I had to split this review into 2 parts because there is a lot I wanted to emphasize.

10X programmers

"This belief in the unicorn programmer isn’t just a piece of pop culture. Indeed, in the real world of software, it’s so well known that the concept has a name: the “10X” coder. As the moniker suggests, it describes a programmer who is provably better, multiple times so, than the average code monkey." (pg. 150-151)

I have many thoughts about the sought-after programmer that fits the title of a “unicorn”. For one, I don’t believe it’s fair to demote everyone to the term “code monkey” if you don’t fit this criteria. It’s an insult to all the different knowledge coders have gained through their experiences on their own journey.

I learned of the term “10X” coder for the first time when reading this book. Coincidentally, it was the around the same time this Twitter post came out where someone encouraged startups to hire as many “10X” coders as they can. The post suggested ways to point out these needed developers by identifying those who “hate meetings”, are “poor mentors” and other traits that may be seen as negative to a company’s culture.

I completely disagree with this person’s opinion. This is a bias view on the fact that start-ups must hire such lone wolf coders to make their company a success. Of course, their success is measured by how much software the “10X” will produce for them. But perhaps their methods may do more harm than good? Why would you want someone to work for you that doesn’t like working with others?

The belief of companies needing to hire only those considered “10X programmers” leaves a lot to be said about the company itself. A company’s main goal is to see themselves thrive, to continue to exist with their idea that somehow outlives those other rivals by only hiring the best of the best in technology that know their craft. Of course, focusing primarily on what the developers can do leaves out the question if they are a good fit to working with others as well. It’s the developers I’ve known that aren’t considered “10X” that witness the flaws of these so called “shining devs”. Condescending and god-like arrogance makes them incapable to work with others. “Brilliant jerks” are just as likely, if not more, to leave technical debt in their wake with the workload they do.

It’s a typical scenario to accept a “young, white dude” to express such ridiculous attitude in an office setting. A woman wouldn’t get away with that type of behavior, considering we would be considered hard to work with just for debating with self-entitled developers. (I want to make clear that I don’t think all programmers that do display a high knowledge of their craft are arrogant, but it concerns me that even if they are, employers won’t always consider that a problem.)

'GitHub is your résumé' (pg. 170)

“Even the world of open source becomes rather less of a mediocracy the closer one looks. After all, it’s predicted on a coder having tons of free time to crank away on volunteer labor. This works remarkably well for full time-rich young people but less so for anyone with lots of coding talent but more real-world responsibilities.” (pg. 170)

I don’t believe it’s fair to think that a coder should have a full GitHub profile to show-off to potential employers. Many of the people I follow on GitHub are working full-time so it doesn’t surprise me to see their contributions more stagnant, especially during the work week.

In my last job, I felt burnt out often from staring at a screen for about 8 hours a day, and then be expected to carry myself to my desk at home to type out more code to prove I was still a programmer in my off time.

You don’t need to know everything

Dennis Crowley created an app called Dodgeball to connect groups of friends together (inspired by the Marauder’s Map from Harry Potter). When it caught the interest of Google, his code was reviewed by many engineers. They were less than impressed with what they were seeing under the hood.

After questioning Crowley about his app, it was made clear that he didn’t have the knowledge that they have, and that was okay. Because it’s not all aptitude that makes a great app, it was Crowley’s idea that made it a possibility and it wasn’t something any Google developer could surpass him with.

When one of Google’s developers gave him an algorithm question, he replied:

“’I clearly have no idea,...I don’t know what you’re talking about. I’ve never taken a programming course!’” (pg. 183)

Crowley’s honesty to the Google interviewer’s shows that you don’t need to know every algorithm or have the penchant to solve engineering puzzles to be able to make a head-turning program. There is always going to be someone better than you, you need to accept that and enjoy just building something.

The first programmers were women

When coding jobs started out in the 50‘s and 60’s, men did not have the advantage of experience over women in this career since it was such a new field. The only testing done for potential programmers was an aptitude test which women regularly passed. They were paid to learn programming from the company that hired them. This was a big deal considering other highly paid career fields such as law or engineering hardly accepted women.

Things unfortunately began to change when companies were realizing how much they needed to emphasize the importance of coders in their business. Putting such a strong emphasis on programming led to deciding who should be hired for such a task.

Some companies required a degree to be even considered a programmer in their company. Women were, needless to say, lacking in the higher education department and their roles were beginning to be replaced by those with the specific requirements, men.

“’As it became a profession…it became an avenue that woman were pretty much shut out if-in general.’” (pg. 195)

“As sociologists have long noted, when a field suddenly becomes increasingly well paid and prominent, men who previously spurned it rush in: We’ll take this over now, ladies, thank you very much.” (pg. 195)

To relate to the correlation of women in higher education: Since 1984, women have never peaked any higher in pursuing bachelors in Computer Science. A factor in this resulted from when they were first introduced to the concept of programming at a young age. Parents tend to expect their son(s) to receive a computer to hack away on, while the daughter(s) were not given such exposure. Another was the culture the women experienced while studying the field.

While studying CS in college, I felt consciously aware that I was one of the few people (and usually the only women coincidentally) who wasn’t programming since I was 10. I certainly was nervous to ask about basic programming in class with some men snickering in the back of the classroom. It was not uncommon for them to not even engage in what the professor was saying, claiming they knew the topic already.

Dark side of machine learning

Incorporating real-world data for machine learning comes with cons of its own. Robyn Speer, the cofounder and chief science officer of Luminoso, analyzed online restaurant reviews using an algorithm applied with “word embeddings” to associate certain words with others. Like a country would be associated with the words of its cities. She noticed that when using her algorithm, Mexican restaurants were receiving a lower rank. Turns out, they were given negative connotation because the word Mexican was considered a negative word from information on the internet. This was also happening for pronouns. "He" was connected to programmer or boss and "she" with librarian and receptionist. If our real-world information is so ingrained with hate and prejudice, why use this data? Wouldn’t it make sense to manually program the machine to consider that it makes no difference if a person is a he, she, they, so they could all have the same association with being a chef, secretary, programmer, lawyer, etc? Yes, it would not reflect the same opinions from the “real” data, but at least the machine wouldn’t be having this prejudice opinion when using the data to automate in practice in the real world.

COMPAS is an example of when relying on machine learning can make things go from bad to worse. The firm Northpointe created a system to aid overloaded judges to determine if a defendant will reoffend in the future. The system labeled black defendants more likely to reoffend than those who were white, not considering the person has made changes in their life to clean up their act based on preexisting data. This is why those creating the software need to not only care about speed, efficiency, clean code, but also who and what the software is affecting. Engineers need to have empathy, awareness, and the knowledge to realize that their creation might be doing more harm than good when it’s used.

“When are the machines going to rise up and kill us?” (pg. 298)

Nick Bostrom, who is a philosopher leading the Future of Humanity Institute at the University of Oxford, is one of the many who believes as technology evolves, it will inherently be the bane of our existence. He is constantly trying to figure out what will kill off humanity first. He believes that it’s AI that will eventually be our doom.

“’Before the prospect of an intelligence explosion, we humans are like small children playing with a bomb,’ Bostrom writes. ‘We have little idea when the detonation will occur, though if we hold the device to our ear we can hear a faint ticking sound.’” (pg. 300)

Read part 2