Book Review: Girls Who Code


Girls Who Code is an organisation aimed at helping women get into tech.

The founder Reshma Saujani wrote a book by the same name. The book’s recommended age is 8-12. It’s a comprehensive guide for learning to code.

While well-intentioned as it is, I don’t think this is a very book as means for learning to code. For a book that is intended for children – it is too long and overwritten.

From a feminist perspective, isn’t a STEM book targeted at women a little ironic?

One of the main points in discourse around women in tech is that tech is gender neutral – tech isn’t an inherently boyish activity.

I find it a little amusing then, that this book fundamentally uses gender roles to sell itself.

I don’t think it’s wrong to do it. If there really is a cultural norm of ‘girls don’t do tech’ and this book gives permission for a girl to be interested in tech, then that’s a good thing.

Also, the book is filled with profiles of important women in tech – and that’s great. Probably my favourite part of the book.

A disclaimer

I haven’t read the whole book. I got a good few pages in before I gave up, and just quickly skimmed the rest. The book is too wordy.

My review

This book is way too large and cumbersome.

It’s 160 pages long, and each page is filled with with text.

If the goal is to encourage young girls into tech – this isn’t the right way to do it. It’s not the right way to encourage any young person into tech.

It might impress parents, and other adults – with its comprehensiveness – but a child is going to find it overwhelming, and unfun.

I think being comprehensive is good. But this book uses too many words to do it.

An introduction to computer science book for children should be first and foremost interesting and fun, and easy.

One hundred and sixty pages of fairly dense reading, doesn’t really sound like fun.

Another thing this book suffers from, is bad design. The book uses a lot of cute handwriting style comments and arrows – I guess in an attempt to make it seem more friendly.


I think it’s just bad design.

A coding book should just aim to communicate as effectively as possible. Using recognisable and tidy layouts is the best way do to this.

This isn’t to say that a coding book shouldn’t be fun. Infact – I tend to prefer reading tutorials that have a more informal tone – but I’m going to find if it said ‘Righto lads, here’s how to create a for loop’ off putting.

The taco creation algorithm they used to demonstrate for loops was interesting, as was the bead creation algorithm. The profiles and timelines throughout the book are good.

What does make a good coding book for children?

It’s easy enough for me to criticise – but what would a good coding book for children look like?

It would be far shorter, for one. I think the way I would go about it – is I would create a first introductory book intended to be as fun and easy as possible, and then if the child showed continued interested in it – then they could purchase a second more indepth book.

I would aim to use as few words as possible. Each page, basically containing one simple concept.

I would intersperse simple quizzes through the book, testing the child’s knowledge. Quizzes are effective tool for maintaining engagement, as the child is given a sense achievement and progress when they answer the question correctly.

I’d intersperse cartoon pictures throughout the book to keep it interesting.

So that’s it. Seeing this book, makes me think I should I considering writing my own one.

Alpha geek syndrome in IT culture.

I think IT culture can suffer from an ‘alpha geek’ syndrome – where total commitment to code and technology is valued above all else.

This post at Super Coders IT (an IT recruitment firm, which I have to be fair, I think they have a great website and blog posts) expresses this, in the form of a list activities that demonstrate a developer has passion:

  • Spends lots of personal time at home reading software development related books, blogs and websites
  • Spends lots of personal time at home writing code and developing personal software projects
  • Has made substantial contributions to open source projects
  • Has created their own software product which is available for download on the web
  • Has written articles for online publications/magazines
  • Coding since childhood/high school
  • Participates in programming competitions
  • Writes a blog
  • Has an account on Stack Overflow which shows a history of participation

It’s not uncommon for employers to ask if a candidate works on projects outside of work – seeing this as a sign of being a good programmer.

The problem with this is it ignores the other human elements of the programmer. It assumes that good programmers are another species, closer to a computer than a human, who derive pleasure from all things technology related. This blog post here articulates well a similar opinion that I’m expressing here.

I’m a single, thirty year old. I have a plenty of free time.

I could dedicate my weekends to contributing to an open source project, or answering questions on Stack Overflow – but do you know what I prefer doing?

  • Writing this blog.
  • Running and exercise.
  • Learning ceroc.
  • Playing board games.
  • Socialising
  • Taking photos for my Humans of Newtown Facebook page.

If I were a married man with children, I’d have even less free time – I would certainly be prioritising spending time with my children over writing/reading code.

Some people do live and breathe code, I appreciate that. These coders probably are likely to better coders, having more familiarity with the framework or library.

At the same time – the human aspects of being a coder shouldn’t be understated. When you first walk in to the office on a Monday morning, and you ask your colleague what they got up to on the weekend, what do you want to hear? ‘I learned a new web framework, and fixed some bugs for this open source project I’m contributing to’ or ‘I went surfing and then played board games some friends.’ Which contributes to a more congenial work atmosphere?

My intention here isn’t to disparage either person.  IT attracts a quite a wide range of people, and there are plenty of people who would prefer talking about something technical, than about social interactions. At the same time, others would much rather talk about the movie you saw on the weekend, than more code. The point of workplace socialising is primarily for relaxation and to build relationships after all, rather than spreading technical knowledge.

It would however, be a mistake to think that super-nerds are the only people that an IT firm should value, for two reasons.

Firstly – the firm risks missing out on perfectly capable developers, simply because they value spending their spare time on other things, rather than code.

Secondly – the firm’s culture becomes ‘alpha nerd’ focused, and this could lead a hyper-competitive and workaholic type atmosphere.

This might be beneficial for the company in the short term, or perhaps even necessary for a bleeding edge technology company or start up, but I would be very cautious taking a company’s culture that way. In the long run it could lead to interpersonal conflicts and uncooperative behaviour.

At the end of the day, I guess company cultures vary from firm to firm, and people who live and breathe code might feel more comfortable at firms who have a culture that values that. But I would suggest that it would be a mistake to think that all good developers don’t have interests outside of code.