Sam Newman's Blog

This year (2023) is the year of platform engineering. Don���t believe me? Here is the esteemed (and it has to be said lovely) Charles Humble totally accurately quoting the ravings of some madman on twitter:

���This is going to be year of platform engineering.��� @samnewman, #WTFIsCloudNative

— Charles Humble (@charleshumble@mastodon.social) (@charleshumble) February 2, 2023

See? The industry is all ablaze about the idea. I mean, even Gartner has come to the party, so it must be a thing, right? If Gartner says something, it must be true. I fully expect we'll see the announcement of PlatformCon 2023 to be held at the Moscone Center, with "Con" taking on many, many, meanings.

But, let���s pump the brakes for a bit. I fear that we���ve come too far from the original intention of a developer platform. We���re in danger of being drowned under an orgy of vendor-driven mis-direction, which will allow existing IT structures to carry on as if nothing ever happened as they can slap a new label on old practices.

The CNCF Landscape displays the funding various companies they feature have received.

A cynic might argue that the (as of time of writing) $66.8 BILLION raised to fund the Cambrian explosion of products around Kubernetes means that a lot of VCs are looking for their payday. And I suspect that much like the early days of attempts to monetise Agile, DevOps and the API Economy, the pickings have been slim. But a new term they can get behind, leaving aside the confusing term ���Cloud Native���? Count them in! Marketing suddenly got a whole lot simpler.

The Kubernetes Awakens Are we not entertained?

The reality is, Kubernetes is everywhere, and just like every successful fungus continues to spread (I kid, I kid!).

Let���s get some things out of the way. Kubernetes, vanilla Kubernetes, not whatever horrific private cloud your company has cobbled together, is not in any way shape or form developer friendly. To be fair, that���s not what it was created to be. But fundamentally, the out of the box experience is fine for infrastructure automation nerds like me, but friendly for the bulk of developers? Hell no.

Kubernetes, again vanilla Kubernetes, not that complex expensive disappointment your CIO purchased, also doesn���t do much. At its heart, its main job is to help schedule containers. It was successful for a number of reasons. Firstly, because it has a pretty good API allowing for extensibility. Secondly, because it was competing against solutions that were by turns too expensive (PCF), confusingly complex (Mesos), or suffering an identity crisis (like Docker Swarm - I can only assume the marketing geniuses at Docker ended up in charge of naming stuff at Google). Thirdly, and most importantly, because a bunch of people got scared by AWS and thought backing the project might stop Amazon becoming the dominant cloud platform for deploying software. On that front, it's been a huge success, right? Right?

Kubernetes was extensible, and allowed an ecosystem to grow around it. It���s easy to use the CNCF landscape as a source of snark (and as you can see, I do) - but it���s a sign of success. It���s also a sign of a bewildering array of options available to anyone considering building a solution on top.

Picture source, licenceWhat could possibly go wrong?

I think I finally started to understand how crazy everything had got after watching this great talk from V K��rbes. After watching this engaging talk, I needed a lie down. The bewildering array of options to solve the same problems can take an expert like V to navigate, was a concern to me back in 2019 when this talk was from. Since then, can anyone say it's got better?

So, now we have a towering edifice, created out of software which is well meaning and apparently simple in isolation, that ends up as a rube Goldberg machine of operational overhead, latency blackholes, and ever increasing budgets. The VCs are rubbing their hands, the rest of us are staring into the abyss - but this time, it's got an API.

The past experience

I was far from the only person worried about the complexity of the Kubernetes ecosystem in the pre-pandemic times, in fact rather than just bitching about it down at the pub, a number of folks actually started talking about it more to try and share better ways of thinking about this space. Developer experience, typically shortened to DevEx or DX, became a hot topic for a while.

Although I do a lot of general vendor bashing (hey, my company has two people - I consider vendor bashing to be very much punching up!), a lot of the talk about DevEx was coming from the vendor space. People building technical developer-focused products, wanting to understand how to make their tooling easy to use and sharing tips with the wider industry.

Daniel Bryant from DataWire in particular was talking about these ideas back then, his talk in 2019 giving a great overview of the challenges we have to deal with.

Remember 2019? Simpler times. Very much pre-pandemic, and back when we thought ���jeez, the whole Kubernetes ecosystem is a bit much, isn���t it?���. Here we are in 2023, and how is that going for us?

Enter The Platform

2023 is here. Developer Experience is dead, long live The Platform.

So now, we���ve arrived at The Platform. Note the capital ���T��� and ���P���. This is it. The time has come. We brought all this stuff, now we have to make it work together.

The reality is, much of the effort around platform engineering is NOT about empowering developers, it���s about hiding the towering pile of crap we���ve assembled and now have to hide from the people we apparently got it for in the first place. It���s like buying a bunch of presents for a child, then having to hide them because they���re too dangerous for them to use, and in reality you really got them for yourself. Did your kid really need that compound hunting bow?

It���s not about the experience. It���s not about enablement. It���s about serving the idol of technology, doubling down on our sunk cost. The Platform Above All Others. It should be here to serve, but instead it ends up bending those who use it to their will.

Topologically Topical

Into this morass, wades Manuel Pais and Matthew Skelton, who outline a vision for modern software delivery organisations in their book Team Topologies. In it, they describe long-lived stream aligned (outcome-oriented) teams who work with high degrees of autonomy. Empowered to get things done, and get software out of the door and into the hands of their customers as quickly as possible.

To support this mission, these poly-skilled teams need help. Other types of teams - enablement teams in Team Topologies speak - exist to help these teams get things done. Functions like security, architecture, design, go from being gatekeepers to enablers - their job is to provide support to get things done.

In the book, the authors also make it clear that these teams need enablement in terms of the developer tooling they need too, hence the need for some sort of platform. The book positions a Platform Team as being somehow different to an enablement team, but personally I see the platform team as just another type of enablement team. The mission of the platform team, should you choose to accept it, is about enabling these stream aligned teams to get things done.

Above all though, as great as the content is in the book (and I highly recommend it to anyone in a leadership role in software development), I do wish they hadn���t codified the concept of the platform team. Naming is important - it pushes a direction - "we exist to build a platform". But read the words of the book, and that���s not really the role they should play.

The book goes on to outline a vision for the ideal platform. It should be developed like a consumer-facing product. Think about customer needs. Most controversially of all, they make an argument that the platform should be optional..

Making the platform optional is very challenging for some people. It cost so much, we need to justify the cost. So people have to use it! Otherwise we wasted time and money. And as Matthew and Manuel point out, when something becomes mandatory, interesting thing happens, When you make people use the platform, you stop caring about making it easy to use, because they don���t have a choice. You aren't incentivised to improve the user experience to attract people to the platform, as they have to be there anyway.

Matthew, Manuel, and myself are far from the only people banging the drum for developing an internal developer platform like a consumer-driven product. Another ex-colleague of mine, Evan Bottcher, put forward a compelling vision for what a developer platform should be back in 2018 What I Talk About When I Talk About Platforms:

���A *digital platform* is a foundation of self-service APIs, tools, services, knowledge and support which are arranged as a compelling internal product. Autonomous delivery teams can make use of the platform to deliver product features at a higher pace, with reduced co-ordination.���

- Evan Bottcher

But those of us with no products to sell don���t have the marketing budgets of those who do. Remember that $66.8 billion raised by companies on the CNCF landscape? That money doesn���t just go into building the stuff. Pushing back against the weight of money in this space with this blog post is a bit like trying to stop a tornado with a kazoo. It���s not very effective, but at least I enjoy the funny sounds it makes.

The vision for The Platform has gone from being a vision for a better experience for developers, where the platform exists to serve developers, and has instead come to serve the Kult Of Kubernetes, and it's worshipers.

What's In A Name?

Whenever you come across a team which is named after a specific tool or technology, you have a potential problem. The API Gateway Team. The Enterprise Service Bus Team. And yes, The Platform Team.

The problems occur on two fronts. Firstly, for "technical" single-issue teams like this, they become the bottleneck, the silo. They end up owning key technical infrastructure, in much the same way as a dragon hordes its gold. Making changes to these pieces of key infrastructure to suit the needs of the developers that use them can often be like getting Gollum to share the ring, if Gollum used Jira.

Picture source, licenceMy Precious, etc.

There is a more subtle concern with single-issue teams like this though. It speaks to confused motivations, a lack of focus. Their job becomes about managing the tool. Are they ever going to be in a position to think about alternatives? To realise a better way to solve the problems at hand? These are teams where they have only one tool, one hammer - and all problems better be a nail. Or else.

An old colleague of mine succinctly differentiated the two world views at play. Sriram Narayan described ActivityOriented teams as those driven to carry out a certain activity:

���... activity-oriented teams are prone to optimize for their own activity and not for the bigger picture of delivering useful software. This is a consequence of what they are held responsible for and how they are measured. It is common for a team of only developers to only be measured by their velocity. If they are only tasked with delivering scope, they will not think about whether it is going to solve the problems it was meant to.���- Sriram Narayan

Sriram suggests instead that the solution to this is to instead think in terms of OutcomeOriented teams, where teams are focused on delivering an outcome, rather than slavishly locked into a certain implementation detail.

We want our Platform Team to be about outcomes - but we are hamstringing them from the beginning by calling the Platform Team in the first place, and worse could follow by codifying "Platform Engineering" as a thing.

Naming things is important. For a team inside an organisation, it can change how you are viewed, and what people expect you to be able to offer. For people in the team itself, it's one of the simpler ways you can help set direction - rightly or wrong.

It's for these reasons that I argue we should name the team after the outcomes we wanted them to achieve, rather than in terms of a technical solution they might want to use. Quite aside from the fact that you might need more than one platform (so Platform Team has to become Platforms Team?), often the best way to improve the experience of developers may have nothing to do with a platform in the first place. Better names might be ���Delivery Support��� or even better ���Delivery Enablement���.

A platform might be the best way to reduce the cognitive burden on developers and allow them to get more done, but at best it is a means to an end. But we need to encourage people in charge of this function to be able to think more broadly. Matthew Skelton:

What if the most important part of "platform engineering" is maintaining a high quality wiki with proven, empathic patterns for Stream-aligned teams to follow? ���� #platformengineering #DevOps

— Matthew Skelton #BLM �������� (@matthewpskelton) October 15, 2022

If you're a team who cares about empowering developers, you'll think about offering training, doing outreach, embedding yourself in delivery teams to help them use the tools and also get feedback on if the solutions you are offering are appropriate. All of those things seem like they'd be the responsibility of the Delivery Enablement team, don't they? The Platform Team though? Sorry, I've got a Kubernetes cluster to polish.

Just as with DevOps (It's The Culture, Stupid!) we're in danger of missing the point all over again.

So What?

When writing the 2nd edition of Building Microservices, I revisited the concept of habitability - a concept which I visit in the context of developer platforms in a talk last year.

Habitability, in the broadest sense, describes how nice (or not) the experience is for the people who have to live in a system. From a building, to a codebase, to the ecosystem of developer tools we deliver for our workforce. In the talk, and in my most recent book, I make the argument that we ignore habitability at our peril. Those of us in a place to shape the lived experiences of our colleagues have a duty of care to ensure that we take their needs to heart.

Delivering a habitable experience requires empathy for the people that will live and work there. Having a clear focus, and vision, for the people who are responsible for this is much more important than any particular technology.

And so, I come back once again, to the name. If we want to have a hope of coming out the other side with a better lived experience for our delivery teams, I urge you to consider making at least one small change inside your own organisation.

No more platform team. Kubernetes, containers, the cloud, the platform - it���s all means to an end. Down with The Platform, up with Developer Enablement.

So, after far too long a hiatus, we���re back on the Magpie Talkshow for a one-off episode where I interview Kafka creator and Confluent CEO, Jay Kreps.

I���ve been doing a small amount of work with Confluent recently, and through this I got the chance to meet Jay, and I thought he���d make a great guest for the show. So in this episode we���re going to learn about Jay���s own journey in the tech industry, as well as diving into the mindset behind Kafka and where you might want to use it.

There are a couple of firsts in this episode. Firstly, it was recorded remotely via video conferencing - I think the audio quality is pretty good, largely thanks to the use of zencaster. I did however have to do more editing than usual but I���m pretty happy with how it turned out. Secondly We���re also going to be sharing a video of our chat over on confluent's website, and I���ll update this post with a link once it���s available.

I do have to apologise for the sporadic nature of the episodes I���m putting out but as is often the case, life get���s in the way. In between our last episode and this one I setup my own company, and left Australia for London, where I am currently based. I still plan to publish the occasional episode from time to time, so please do stay subscribed to the feed. Hopefully if things settle down a bit I may get back to a more regular posting schedule!

Jay and I talked about a number of things on the podcast, but the main one I wanted to highlight is previous guest Ben Stopford���s really interesting posts on using Kafka for sharing data between microservices. There are some fascinating ideas there which I think can solve problems many of us face when creating finer-grained distributed systems.

Anyway, I hope you enjoy the show!

Adrian Cockcroft has been a great supporter of my work around microservices, and I was really grateful he was able to find the time to catch up with me at Yow 2015 late last year.

Few people have done as much to help share the power of the cloud in recent years as Adrian, but he certainly has a career that predates the explosion of Amazon Web Services. In episode 22 of the Magpie Talkshow, he shares is journey so far in the IT industry, from physics to venture capital firm Battery Ventures, with stops at Sun, EBay and Netflix in-between.

We also find time to talk about the future of memory, security & compliance, how awesome Rational Purify is (and how it built Netflix), bad puns, and flying spaghetti monster simulators.

In the episode, Adrian mentions Spigo, the aforementioned spaghetti simulator, which is available over at github. You can also find his talk from YOW! 2015 below.

In the last episode of the podcast, I shared the first of the two part NASA special, when I chatted to Dr Anita Sengupta about her involvement with the recent Curiosity Mars lander. This time, I'm chatting to her colleague Dr. Kamal Oudrhiri, who led the Radio Science team for the same lander.

In our interview, Kamal shares his journey into space sciences, from being inspired as a boy by pictures of voyager, what led him to pick NASA over ESA, and also what drove him to setup his non-profit Grove Of Hope. Focusing on encouraging students to embrace STEAM (Science, Technology, Engineering, Arts and Mathematics), the Grove Of Hope was established in 2004 and it's clear from chatting to Kamal that he hopes to inspire the next generation in the same way that he was inspired all those years ago.

Along the way we also find time to discuss why an off-the-shelf quadcopter might not be a bad place to start for exploring mars, the relatively poor success of Martian missions in general, and what NASA might have planned in the coming years for further landers.

Just as with software releases, rocket launches often get pushed back too. The Insight mission that Kamal discusses during the interview which was due to launch in 2016 has been pushed back to 2018, while at present at least the ambitious Mars 2020 lander appears to be on track, although the drone may no longer feature!

Since we recorded this interview, Kamal and Anita have both been working on the new Cold Atom Laboratory, which is due to be installed on the International Space Station in 2017. This brief video gives a very good overview of the project:

And here is Anita and Kamal's keynote from YOW 2015:

One of the nice things that the YOW conference has done over recent years is strive to bring in interesting keynotes, often from quite left-field areas (at least for a software technology conference!). Last year the organisers outdid themselves when they managed to secure the services of Dr Anita Sengupta and Dr Kamal Oudrhiri who worked on the recent Mars Curiosity Lander for NASA. I was lucky enough to grab both of them just after they spoke in Sydney, and in this episode you'll hear the first of a two part NASA special. That's right, I got to speak to real life rocket scientists! Although as Anita reliably informs me in today's episode, the correct term is 'propulsion engineer' (I don't think "It's not propulsion engineering!" quite has the same ring about it though���).

Anita the Lead Engineer on the hypersonic parachute system used to slow the lander down on it's Martian decent, and as she outlines in this episode this brought with it a whole host of challenges that hadn't really been faced before. We also find time to talk about science fiction, and how you might be able to get involved in this and future NASA missions!

If you want to know more about Anita and the work she is currently doing, you can follow her on Twitter @doctor_astro (kudos for the Twitter handle by the way!), or follow her over on facebook.

This video from NASA gives a great overview of some of the challenges involved in the lander as a whole, including the amazing parachute:

Since I interviewed both Anita and Kamal, they have both been working on the new Cold Atom Laboratory, which is due to be installed on the International Space Station in 2017. This brief video gives a very good overview of the project:

And here is the video of Anita and Kamal's talk at last year's YOW 2015:

In the next episode, we'll hear from Anita's colleague Kamal Oudrhiri. This will be in two weeks' time - I've been struggling to find a regular rhythm for these podcasts and want to find a sustainable pace. Doing them once a week really hasn't worked out, so I'm hoping once every two weeks will be more manageable.

Picture source, licence

I've been very fortunate to have been in demand of late, for conference talks, tutorials, and other things. The problem is trying to satisfy the many requests I get. Being based in Australia means that travel is a significant time sink for me, increasing the impact on my time, sometimes my health, not to mention the planet! Given that I also have a day job, and other projects I am working on, I have to think very carefully about each and every conference or workshop that I'm invited to, and I probably end up having to turn down two or even three times as many things as I actually say yes to.

Given these constraints, I've been thinking about different ways I can help share my ideas with people without having to be there in person. This blog is part of it, as of course has been my recent book. But I've also been experimenting with my podcast, and last year did my first series of video for O'Reilly. That video course was an trial really - I wanted to see how well received it was before committing to do more. The work required in pulling that sort of material together isn't trivial, although I do plan to do more next year.

One aspect of pre-recorded video training is the inability to have a conversation with the people who are watching. This is a key part of my workshops - I frequently change or adapt what I present based on the direction the conversation is going, and like the input from the attendees themselves. Pre-recorded video eliminates this side of things. This is partly why I was very interested when O'Reilly approached me about trying to do some live, online training.

From Monolith to Microservices, an online training course

The first course I will be presenting will be Monoliths To Microservices. Split over two half-days, I will be covering a bunch of material targeted at the challenges of organisations who are looking to move towards a microservice-based architecture.

The idea that I can create a live training environment without having to get on a plane is pretty appealing. If successful it should mean I can do many more of these for a wider audience than before, at the same time as keeping the costs down for attendees too (these online courses are much cheaper for attendees than my normal workshops).

If you're interested in what the course covers, I have more details available. Alternatively, if you want to sign up for the course, you can do so directly over at O'Reilly. You can also get a free sample of my existing microservice video training too.

So this happened over the weekend:

@samnewman Agree but we are finding it impossible to even get any ladies to interviews at the moment. Know any great female Java devs?

— Nick Hughes (@nick_hugs) August 19, 2016

I subsequently started sharing my thoughts with Nick via twitter, then realised it wasn't a great forum to discuss a topic this complex. I initially offered to share more detailed thoughts with Nick via email, and it ended up being blog post worthy. And here we are.

This blog post is focused on the challenge of hiring women into software development teams. There are many other diversity issues inside IT that vary from country to country, including things like under representation of people from different ethnic backgrounds, sexual orientations, religions, or castes. I am not saying that diversity inside IT should be focused purely on gender, however this is the area I know most about, so it's what I'm sharing. I also think that it is important to start somewhere - the only way to fix a big problem is to break it down into smaller bits and start there. In your own situation you might decide that tackling a different aspect of diversity is a better idea - good for you! In which case some of what I share here might be useful, or might not.

I am also focusing this post on hiring more women, rather than talking more generally about creating a workforce in which they will be happy and successful. There are a bunch of things to consider about creating a safe, welcoming and productive space for women and other historically-disadvantaged groups, but that is a topic for another time.

I also don't want to dwell too much on why improving diversity in your organisations is a good idea, mostly because I hope that to many of you that it just seems like the right thing to do. However I will point out that in an age where we talk about our software developers having more understanding and empathy for their customers, that having a development team which bears little relation to their customer base can't help. You can also, if you want, read up on the many studies out there which show how more diverse teams perform better. I've included links to three such reports at the end of this piece.

But before we start���

I Am Not A Woman - Tip #1: You Should Speak To One

I am not a woman, I haven't lived as a woman or experienced the problems they face in the IT workforce. I haven't even dressed up as a woman for the stage (that time you're thinking of I was actually an androgynous alien from outer space, and we won't speak of it again). This means you should take a lot of what I say here with a pinch of salt. I have shown this post to a real-life woman (my awesome wife, who works in IT and has done a huge amount in the area of improving gender diversity in my previous company, ThoughtWorks) in order to make sure I'm not talking out of my behind.

And this is the first tip. If you are not a woman, go and find one and chat to them about the fact that you want to hire more of them. Even better, find more than one woman to talk to. Even better, find some that work as developers! Talk about what you currently do. Talk about what you're planning to do. Listen to them - take on their advice. Don't do this as a transactional thing, do it as an ongoing part of adapting and refining how you hire.

Picture source, licence

Shut Up And Listen

Oh, and by 'talk to a woman' I really mean do a very small amount of talking, and lots of listening.

Do you work at a startup, and right now it's all male? Why not make it a priority to find a female advisor for your company who can help? Perhaps you have a local girl geek group you can chat to. Maybe you can afford to hire in a firm that specialises in this sort of thing.

Also, if you do reach out to a woman in the industry to talk about this stuff, and they say 'That's the last thing I want to talk about!' don't be surprised. I know a lot of women in IT who get pissed off that this is all they get asked about when they'd much rather talk about functional programming, infrastructure automation, or whatever. I don't blame them, and neither should you. If that's the case, go find someone else and stop bothering them - women in IT have enough shit to deal with without men assuming they have to always be a spokesperson for their gender.

Ultimately, each of us has our own set of biases, agendas, and built-in assumptions. Get people into your network who can help you challenge your assumptions.

MOVE THIS UP:
why study after study has shown that highly diverse teams outperform less diverse teams (see this Deloitte Study, or this report from Talent Innovation, or this (PDF) paper from the American Sociological Review).

Tip #2: Hiring Women Might Be Harder Than Hiring Men���

You can do it. But you need to put the work in. You'll need to recruit in different ways, change how you advertise jobs, do more research, build different networks. If you don't care enough to do different things to build a more diverse team, then stop reading now and go back to your mono-culture, and be prepared to be outperformed by competitors who do care about this. Also don't be surprised when your employees decide to leave and go join some other, happier workforce. Trying new things will definitely mean more work, and may require more investment, and you need to be prepared for this. But this is often the case for any worthwhile change.

Or, you can just sit around and complain that this is really hard. Then you can just blame someone else for the problem:

This is complete and absolute garbage. https://t.co/EJ6uiffe7s pic.twitter.com/qZOvD8M1m2

— EricaJoy (@EricaJoy) July 14, 2016

This "it's a pipeline problem" idea is something I see often trotted out by people to try and justify why they aren't able to create more diverse teams. That this particular example comes from a large, well known company's head of diversity, a company with such a woeful representation of women in technical roles, is pretty sad, but unsurprising. Don't be like them.

These sort of claims often fall apart when you ask them 'So, what did you change?' and find out that just thinking about it but not doing anything new isn't a recipe for success. Stop claiming industry-wide issues are a reason why you can't make a local change. How do you think the problems of the industry get fixed? By bloody doing something about it. You should also read this excellent post by Rachel Thomas - "If you think women in tech is just a pipeline problem, you haven���t been paying attention".

Tip #3: ���But It Gets Easier

A few years ago I was chatting to a chef in a London restaurant. I was interested in the fact that although the cuisine was what would be classed as modern English, his entire kitchen brigade was Italian, and mostly communicated in Italian.

"It's simple" he said. "I hired Marco, and he was great. When we needed someone else, he recommended them. And here we are!"

Hiring In Your Own Network Can Be Problematic

Any recruiter will tell you that the best way to hire is via referrals, via people you know. This means that if you have good networks, you can bring great hires in. This is problematic though if you have limited networks. Male developers tend to know lots of other male developers. Female developers are more likely to know other women. So, the more women you have inside your organisation, the better your hiring networks will be.

Another thing to consider here is the experience of a woman coming in for an interview. If she sees no other women in the organisation, is she likely to feel at home there? As Kellan Elliot-McCrea, ex-CTO of Etsy says: "Simply saying that you value diversity internally isn���t enough ��� there���s just no reason for an outside observer to believe you if they come and see a scarcity of women in the organization." On the other hand, if a potential hire sees a more diverse workforce, and the potential co-workers who are interviewing her include female developers, that's definitely going to help her consider joining your company.

Tip #4: Check Your Job Spec


Picture source, licence

Is this the image you want for your company?

Calling all Rockstars, Ninjas and Brogrammers! Yes, you know who you are. I know plenty of male developers who would not associate themselves with those descriptions, so perhaps keep them out of your job adverts?

While we're at it, its pretty easy to keep gender specific pronouns out of your adverts (they rather than she/he for example). These are simple steps that help an applicant feel like they could actually work for you, and that you'd welcome them. Let's look at this gem from a (now changed) post over at Expensify:

@Pinboard Expensify is inclusive: you can be a bro, a family man, a guy's guy, a frat boy, or a dude. pic.twitter.com/zP1lh5n6Yi

— Asher Langton (@AsherLangton) July 14, 2016

Ouch. Stuff like this sends messages, and while I can't comment in the specific case of Expensify, use of gender specific language in communication like this can often be indicative of how the company thinks about who might join them. Even non gender specific words can still resonate very differently with men vs women, and make them feel differently about whether or not the job might be right for them.

It doesn't stop there though, it's also how you phrase the job description. Research has shown that in general men will apply for a role if they meet a subset of the criteria, whereas women are more likely to only apply if they meet all criteria. So make sure that your job descriptions are worded to attract a broad array of candidates.

Tip #5: Check what you're offering


Picture source, licence

Being child and family friendly will help attract more talent from more diverse groups

Women are more likely to have childcare responsibilities than men (at least this is the case according to recent data here in Australia, and I suspect you'll see similar things elsewhere). Therefore jobs which afford some form of flexible working are more likely to be viewed well by women who need to do things like pick up children from school. And of course flexible working that helps a working mum is going to help a working dad too!

Having sensible, generous paid maternity and paternity leave can help as well - not just in terms of helping recruit women, but also in helping retain them (see this recent Business Insider piece). In some countries the rights of workers to paid maternity and paternity leave is poor to non-existent (hello, USA!). One way for your company to stand out amongst the crowd, and be more attractive to a potential female candidate, is to have a generous maternity and paternity policy.

Tip #6: Grow Your Network

As mentioned earlier, hiring from inside your network is a very efficient way of finding awesome new people to join your company. But if your network is the same network of friends, colleagues, user groups and conferences that you've had for ages, how will you find interesting new people from different backgrounds and minority (in IT terms at least) groups? So go to new user groups, and perhaps think about sponsoring them. Chat to new people. Follow new people on Twitter. Watch new talks, read new things.

Picture source

Consider attending, or even sponsoring, conferences with a good track record of encouraging diverse speakers at attendees

Go to new conferences, and perhaps pick those conferences that do a good job of ensuring a diverse range of speakers and attendees. I spoke to Aino Corry recently regarding how she and others help the GOTO and YOW! conferences do just that (disclosure: I've spoken at both YOW! and GOTO, and have been a track host on several occasions at GOTO conferences). Maybe consider sponsoring conferences like this too! It can get you visibility at an event where you will meet new people who might be interested in joining you.

Etsy's Hacker Grants program has helped bring more women into the industry, and helped them hire a lot of them too!

You can also invest in other sorts of programs to help reach new people. Etsy launched their Etsy Hacker Grants to provide scholarships to women engineers enrolling in Hacker School, and ThoughtWorks have experimented with more than one program aimed at bringing women back to IT after periods outside the industry

Tip #7: Set Targets

Knowing that what you have now isn't good enough is one thing, actually making sure you'll do something about it is another. Targets, especially targets that leadership care about and focus on (see next tip), are a great way of keeping your company on track and making sure you'll actually do something about it.

Having concrete goals focuses the mind. Otherwise, when things are difficult, don't be surprised if your hiring team falls back into the same old set of processes they have always used. Saying you'll try really hard to do something new rarely works, as it's just too tempting to fall back into your old, easy behaviours, and do just enough to get by.

Setting hiring targets for people for different from under-represented groups can sometimes get push back because of concerns that somehow this leads to lowering the bar, and that you'll end up with a company full 'diversity hires' that only got the job to meet some quota. In practice, this rarely happens. Why would a company hire someone who can't do the job? As Kellan Elliott-McCrea puts it: "Lowering standards is counter-productive ��� the idea that ���it���s hard to hire women engineers therefore we won���t hold them to such a high standard��� is noxious. It reinforces the impression that women aren���t good at engineering, which is obviously a downward spiral."

Picture source, licence

Setting quotas for graduate recruitment was hugely successful at ThoughtWorks

Given the rate at which women leave IT, finding more experienced technical women can be difficult, especially if you don't have the networks. Hiring women earlier in their careers, and creating a great working experience for them can be one way of arresting this brain drain. It was partly for this reason that in 2011 ThoughtWorks decided to institute a policy of 50/50 hiring for men and women in graduate roles. This quota (let us call it what it is!) came along at the same time as a period of strong growth for the company globally, during which there was a goal to increase the number of graduates being hired each year.

Having both a gender quota in a growing company can lead to tension. If I want to hire 20 graduates, that means I need to find 10 women and 10 men. If I find hiring women really hard, I could decide to let the quota slip in order to find the number of people I need as quickly as possible. This has often been a challenge at ThoughtWorks as the company leadership were unwilling to let either the gender quota or the overall hiring targets go. The only solution was to invest more in finding female candidates. They did this by building new relationships, investing in different types of events, and all the other things I've talked about previously.

Over time, this idea of 50/50 hiring has been hugely successful in ThoughtWorks' impressive change in the gender mix in technical roles. Many of the women who were hired as graduates are now playing leadership roles inside ThoughtWorks and elsewhere in the industry.

Tip #8: Change Comes From Up Top

The larger the organisation, the more important it is for clear direction to come from the top. Much of ThoughtWorks' success in terms of improving the gender diversity of its workforce was down to the fact that the then CEO and founder were both very clear in setting out what they thought was right, and putting plans into action to make things happen. A strong leader will call out things that aren't good, and do the right things to make change happen. If you want a great example of a leader making a clear statement about how a organisation should behave, and what is acceptable, I ca't' think of a better example than the statement by Chief of the Army Lieutenant General David Morrison in the wake of some pretty serious issues inside the Australian army.

Being extremely clear and crisp in your communication, as General David Morrison was in this particular situation, is key. But it needs to be followed up with action too. Changing the gender mix of any organisation in a meaningful way is not a quick task, and can take many years. This needs to be an ongoing focus area for the senior leadership in your company.

Tip #9: Keep Data, And Keep Tracking

Decide on what is important to you, and what to track. Numbers are a great way of seeing how you are doing, and how you are tracking towards your goals. Reporting on a simple gender mix may not be enough though. You'll probably want gender breakdown by role and by seniority. Some companies just report top-line gender mix, and will often say things like '% of women in a technical role' without saying what a 'technical role' is (Google, I'm looking at you!).

Track your progress! Google's own numbers

These numbers should be shared openly inside your organisation, talked about, and explained.

Even better, publish your data externally. You can do this with a yearly diversity report, as Facebook, Google, and Apple now do. Or you could just share your data with someone like Tracy Chou who makes gender diversity stats visible for a number of organisations, and whose data is frequently used by many across the industry.

Parting Thoughts & Further Reading

We keep seeing big companies share their terrible diversity stats, and they seem to collectively throw up their hands and say 'It's really hard!'. I think that's a total cop-out. Many companies, like Etsy and ThoughtWorks, are showing that change is possible.

Just because Facebook, Google and Twitter seem to suck at this, doesn't mean you have to as well. Try something new, speak to people, go be better, and create a much better, more welcoming, more productive and successful company while you're at it.

And now for some further reading:

Three Studies on why more diverse teams out perform less diverse teams:

"Our findings quantify, for the first time, the ���diversity dividend��� that inclusive leadership reaps from a diverse workforce: greater market share and a competitive edge in accessing new markets. " - from The Centre For Talent Innovation'sInnovation, Diversity and Market Growth
"An Australian study identified an 80% improvement in business performance when levels of diversity and inclusion were high." - From Deloitte's "Waiter, is that inclusion in my soup?"
"For every 1 per cent rise in the rate of gender diversity and ethnic diversity in a workforce there is a 3 and 9 per cent rise in sales revenue, respectively" - from The Official Journal Of The American Sociological Association, Volume 74, Number 2


If you think women in tech is just a pipeline problem, you haven���t been paying attention
"��� the rate at which new moms left Google fell by 50% when in 2007 it increased paid maternity leave from 12 weeks to 18 weeks" - Business Insider on "The science behind why paid parental leave is good for everyone"
"If we find another man, we say 'we like you and we really want to hire you, but we need to hire a woman first'." - More on ThoughtWorks' Graduate hiring policy
Etsy is another company that has done a great job of focusing on hiring more women engineers, and this piece gives a great overview of some of the things they did.

Finally I'd like to thank my wife, Lindy Stephens, for checking my content, tone, spelling, and ideas. The good stuff is hers, the mistakes all mine.

Welcome back to the Magpie Talkshow Podcast! It's been too long (almost exactly 3 months) since I got the last episode out, and despite having a healthy backlog of interviews recorded I've been unable to find the time to get them out. Since then, a number of things have happened including me moving on from ThoughtWorks, where I have worked for over 12 years. I���ll be sharing more about why I made that decision and what comes next over on my blog at some point soon.

In this, the 19th episode of the podcast, I chat to Aino Corry. Aino, believe it or not, develops developers! We caught up at the Yow conference late last year, just one of a number of conferences in which she plays a key part. We chatted about a number of things including what being a meta-developer means, how to run conferences, diversity in IT, and the importance of retrospectives.

You can follow Aino on twitter @apaipi, and find more details about her work over on Meta Developer or via Linked In.

Update: This post has hit Hacker News - you might want to follow the comments over there.

I have been playing around with the very nice Visual Studio Code editor recently. For those who don't know, it's a free source code editor from Microsoft which works cross-platform. The reason I was giving it a look is that it has pretty good support for editing Go, a language I am trying to find the time to learn. I was also keen to see what the New Microsoft could offer a non-microsofty like myself.

I like what I've seen so far, but something interesting came up today. I realised that unlike Sublime, Visual Studio Code wasn't doing any spell checking out of the box. No problem I thought, I bet there is an extension for that. And guess what, there is:

The Spelling and Grammar Checker for Visual Studio Code

Visual Studio gives you a nice browsing interface to find likely packages, and even get a sense of how popular they are. The clear winner here is . You can also see in the above screen shot that you get a link to details about the extension. As I was still pretty new to the ecosystem, I was sort of interested as to what information you got about extensions, and whether or not I'd found the spell check plugin for Visual Studio Code, or just a plugin. Clicking through���

The Spelling and Grammar Checker for Visual Studio Code

Initially, things are promising. A lot of installs (compared to other extensions) and a bunch of 5 star reviews:

After The Deadline - a Spell Checker for Wordpress (and other things)

But then, at the top of the description, I found this message greeting me:

Notice: This extension uses the teacher node module which calls the After The Deadline service to check for spelling and grammatical errors. Document text is sent to the service over unencrypted HTTP. Do not use this extension with sensitive or private documents.

So to be clear, this is saying that any text opened in Visual Studio Code with this extension loaded would be sent in plain text to some service I've never heard of. The mind boggles at how terrible this is as an idea for an editor designed for source code editing. I wasn't the only person who thought so:

@samnewman @troyhunt yep. nope. the author of that spellchecker might be the nicest person ever but there is no justification for that. ever

— Laura Bell (@lady_nerd) May 30, 2016

Is This Really True?

My first reaction was "Surely I've misunderstood something, right?". So I enabled the extension and opened up a non-sensitive file, one of my in-progress blog posts. I then downloaded wireshark to take a look. It took a while to sift it out - it's been a LONG time since I used wireshark (so long ago that back then it had still been called Ethereal), and there is a rather large amount of traffic generated from my machine for things like Sonos and Dropbox and the like, but eventually I tracked down what was being sent. Sure enough I could see all the text being sent, unencrypted, over HTTP to the 'After The Deadline' service. So, at least the documentation was accurate, and that this absolutely insane thing was happening.

What's Going On Here?

As per the documentation, the extension is just making use of a node plugin called teacher, which is just a thin node API (last updated over 4 years ago) to help call a service called After The Deadline. This piqued my interest - who were the people behind this service? Could they be trusted?

After The Deadline - a Spell Checker for Wordpress (and other things)

Their website immediately made me think of some of the pretty bad stock product website from 2008, but I was surprised to see that the company behind the service is Automattic, the company behind Wordpress, amongst other things. This started to make a bit more sense. In the context of a blog post, which is something designed to be shared publicly, the fact that this information is being sent to another party isn't too much of a problem. But in the context of the sorts of things we open up in a source code editor, this is utterly insane.

It's About Trust, Right?

Partly, the problem here is that this traffic is being sent unencrypted. We'll get to that in a moment. But even if this service did use HTTPS (and I can see no good reason why it can't), by using this plugin I am explicitly trusting that not only with the service I send my data to not do anything silly with the information they receive, but that they will ensure it is properly managed and not left lying around to be swept up by some malicious attacker. And again, the amount of sensitive information this could include could be staggering. Source code can be bad enough, but think of the number of times you've put sensitive things like AWS keys or passwords into text files. Now think what happens if they fall into the wrong hands.

The HTTP-only support is also nuts. This means that even if I do trust Automattic to look after my potentially private and sensitive information, I'm opening myself up to people pretending to be After The Deadline. Given the use of a very old node plugin in this tool chain, I did wonder if perhaps After The Deadline did support HTTPS, but that the extension's reliance on the teacher plugin may have limited the ability to use a slightly more sensible protocol. Poking around, it becomes pretty clear that After The Deadline is a freely available service, which Automattic have decided to run for you. You are free to run your own copy of the stack if you want, which you could then decide to protect with HTTPS. From the docs it wasn't clear if Automattic support HTTPS on the version they host, but I couldn't find anything in the FAQ or documentation to imply that they did.

Update: Thanks to a comment over on Hacker News from zerocrates, it seems that After The Deadline does in fact support HTTPS in addition to HTTP (although I think my point about this not being clear in the docs still stands). Another commenter points out a recently opened issue against the teacher module is asking for HTTPS support.

What Should Happen?

Just so we're clear, a sensible solution, for a spell checker that needs to run over sensitive information, is that it should run locally (ideally using a system & user dictionary), without any remote calls needed. It seems odd that I have to spell that out (pardon the pun) but the fact that this extension exists at all seems to be a good enough reason to have to call this out. And it turns out that popularity doesn't always steer us in the right direction - the second spell checking extension that shows up and has a fraction of the installs (88 vs 20K), is a good old fashioned checker that uses a local dictionary. Go instead.

Alternatively of course, we could wait for another party to help us here:

We might see the NSA powered spell checkers soon. It could even tell you how suspicious an email would look like. https://t.co/HTiRvl4o5u

— Thomas Graf (@tgraf__) May 30, 2016

Automattic should give serious thought to supporting their freely available service over HTTPS too. Even though I can't see any situation where I'd want to use this service in this specific context, for the Wordpress ecosystem having this service served over a sensible, and in this day and age easy to implement protocol, would be a very good idea. Update: As pointed out above, it seems that After The Deadline can support HTTPS.

I'm sure that Sean McBreen, who wrote this plugin, has no malicious intent. He spent his own time creating this extension, and gave back to the community. He did a great job implementing and documenting an extension that I think is unfortunately misguided in this particular context. I'm going to try and track down Sean to see if he has any views on this (the marketplace for extensions doesn't seem to give you an obvious way to find or contact authors, which seems an oversight). To be fair to him, he's been extremely clear in the documentation as to what happens under the hood, but I'm still surprised that the use of an external (and un-trustable) service in the context of code is sensible. I'm just as surprised by the number of 5 star reviewers (and the 20K+ installs) listed on the marketplace - perhaps the reviewers have a different view of security to me.

My advice, in the strongest possible terms, is to not use this extension, unless the only things you will ever open with Visual Studio Code are things that you don't mind being viewed by completely unknown people. Oh, and always read the fine print before installing extensions in the future. I know I will���

In this week's episode I chat to Kathleen Fisher, a professor at Tufts University. I caught up with Kathleen during the first stop of the three city YOW 2015 conference late last year, where she was delivering the opening keynote on the topic of formal methods.

Back in my own university I struggled with the topic of formal verification of software. The amount of work required to formally, mathematically prove a given implementation actually did what you hoped, always seemed to be an order of magnitude too great. But Kathleen's incredibly entertaining and informative keynote (included below) showed me how much the topic has come on.

In our interview, we talk about her work in this area, including about how formally verified systems can greatly help improve the security of systems, from off the shelf quadcoptoers to full-sized unmanned helicopters. She also explains how even systems with small amounts of formally proved software can still be useful, and why it's important to know if your in-car entertainment system is backed by a fully fledged linux OS, especially if someone has a dodgy encoding of some classical music lying around!

You can find out more about Kathleen's work over at her Tufts homepage, or view her latest talk. Finally, here is her talk from YOW - highly recommended: