19 Sep 2020

The Difficulties of Imposter Syndrome When You Are the Only Woman in the Room

Lately, I’ve been experiencing imposter syndrome. This is largely due to starting a new job in a new company with incredibly bright and talented individuals who know a lot about things I have never spent much time thinking about. It is probably also due to moving to the other side of the world and existing in a space where, for the first time in my life, I am not fluent in the dominant language. Suddenly I feel like I am at the start of my software engineering journey again, trying to prove that the company made the right choice in hiring me. I feel like an imposter who is likely at any moment to be found out.

And then there is the fact that as a woman in tech I am an imposter. In the eyes of society, I do not fit what a software engineer looks like, dresses like, what they talk and think about outside of work. When people talk about imposter syndrome, they stress the fact that it is not real, that feeling like an imposter is not the same as being an imposter. And while this is true, for women in tech, there is physical evidence every day that we are not “where we belong”. This experience is what I would like to talk about today.

Rationally, I know that I am not an imposter. I was hired by Balena because I passed their technical tests. I interviewed with them and they valued my communication skills and my ability to explain my thinking while I solved technical problems. I went through the same interviewing process as everyone else and at no point did I lie or fabricate any knowledge or experience I had. I was hired because I met the requirements for the role.

The problem is, imposter syndrome is not something that comes from the rational part of your brain. It comes from that nagging emotional subconscious that responds to external stimuli in obscure and unexpected ways. And this emotional part of my brain has been fed a stream of experiences and messages that tell it, over and over again, that I do not fit the image of a software engineer.

A story: one time I was out for lunch with a couple of my co-workers and the CEO of the little tech startup that I was working for. After lunch, we were standing up to pay and we came across the guy who had just bought the restaurant we have been eating at. He was excited to meet his customers and wanted to know a little about us and why we were eating there today. The CEO, Tom, told him that we worked for a tech startup and the man nodded his head enthusiastically and said - “Yes, you look like a software developer”. Now Tom does not write software. He is a law student who started a company and taught himself how to run it. Primarily his work was in sales and the other many thousands of things that are required of a CEO. But never fear, because right after saying this, the man turned to my college Brendon and exclaimed - “Don’t worry, you look like a software developer too”.

I knew the man was being kind and trying to connect with us but I couldn’t help but feel a little angry. What did he think me and Kristy looked like standing next to Tom and Brendon? Were we the secretaries? I wish I had had the foresight to ask him because I am genuinely interested in what he would have said. Unfortunately, as is the case with so many situations like this in life, we had walked out of the restaurant and back to the office before I had time to think of a response.

This is just one of many such experiences for me. I have a handful of stories of people telling me I don’t look like a software engineer, or asking if I’m sure if it’s the right career for me. But these are the explicit examples, and in some ways, they are the easier stimuli to filter out. These people have obvious unconscious biases and they make me worry about how pervasive this is in the industry. They do not make me question my right to be here because I can see that they are ignorant.

The things that creep in are the meetings where my voice is the only one in a certain octave. Where my colleagues talk about the largely masculine things that get up to in their weekends when I spend my time sewing and shopping for vintage clothes. It’s the discussions of games I do not play and the fact that they have knowledge of software and computers before 2011 (in general men in the industry have been tinkering with computers since they were children but women usually start much later in life - did not realised they were into technology until they were exposed accidentally in some other career).

If my day were a movie, it would fail the Bendal test. I never talk to women and when I do, we never talk about the product (I have replaced men with the product here since it seemed like a more appropriate metaphor). The other women in the company are in support roles. They help schedule meetings, send packages, record our contact details. I am not making a value judgement about this work. It is vital to the company and can be a rewarding role with plenty of career progression. Sadly, it also tends to be valued and thus paid much less than the technical work. I don’t agree with this but I also feel that is a topic for another blog post.

The question is - how am I supposed to feel that I belong when this stark fact is in front of me? In this environment, is it surprising at all that I deal with imposter syndrome?

This blog post is not about victimising myself. I love my career and hugely value the wonderful men that I have the benefit of working with every day. I do not want them to change who they are or what they are interested in. They should continue to ride their BMXs and talk about pre-2011 code, while I sew my dresses and obsess over creating the perfect cateye. But I would also love for us to have this discussion openly. I would love for managers to be aware of how imposter syndrome might impact women in the team more than the men. For us to think of ways where we can be extra encouraging, a little more available, and nurturing to those on the team who don’t fit the dominant image of a software engineer. I for one reach out to all new people when they start Balena and ask them how they are doing, let them know that imposter syndrome is normal and that they can hit me up if they have any questions. In particular, I check in with the women in the team and make sure they know that they are doing a good job.

Most of all I would love for us to breakdown the stereotypes in society. Teach girls how to code and encourage more women to enter the industry. With more diversity, this problem will go away, but unfortunately, this takes time and heaps of work. For now, I am trying to embrace being an imposter. For things to change, somebody has to be the first.

29 Oct 2019

Disabling certificate pinning using frida and charles

There is a company operating in my hometown that I really dislike. I won’t name them or go into too much detail about what they do for fear of them going after me (they are that kind of company). Let’s just say that this company has a monopoly over a particular service, and they use this position of power to threaten people into paying them unfair amounts of money.

This company has a phone app which you can use to pay for their service and recently I had a go at sniffing the requests. The app uses certificate pinning which means that you cannot use your own certificate when making requests. After playing around with some tools I managed to disable the pinning so that I could view the requests that they were sending. This revealed some pretty interesting stuff, including a potential security flaw in their payment method (which I will go into later).

I have no plans to abuse what I have found. It just makes me feel good to crack their security (kind of like knowing one of your bully’s embarressing secrets but deciding to keep it to yourself). This method, however, is pretty useful for a bunch of things (such as making an android version of an iOS app, or keeping black-box testing out of your production code) so I thought I’d outline the process I used for others who’d like to learn.

Read more...

What you'll need

Installing the Charles Root Certificate

Once you've downloaded and installed the above tools (except for frida-server - we will explain how to use that later), you will need to install the Charles root certificate on your phone. This is what we will be using to handle the SSL handshake (more of this here).

To do this, open Charles and go to the help section. Scroll down to SSL Proxying > Install Charles Root Certificate on Mobile or Remote Browser. Follow the instructions outlined here to install your unique certificate.

For apps without certificate pinning, this should be all you need to begin sniffing requests. Unfortunately, with our app, the requests fail.

This is where frida comes in.

Setting up Frida on your phone

Frida is a tool that allows you to inject snippets of JavaScript into native apps on Windows, macOS, Linux, iOS, Android, and QNZ. Basically it injects the Google v8 engine into whatever process you have identified, allowing you to hook into functions and change what they do while they are running. If you’ve used Greasemonkey or Tampermonkey for on-the-fly changes to a web page then you may be familiar with this idea.

Setting up frida is pretty easy:

  • First, toggle the developer settings on your phone and make sure Android Debugging is enabled (you can also connect to your phone over the network using the 'adb connect' command if you do not have a USB cable handy)
  • Open a terminal and type adb devices to confirm your device is available:
  • Make sure adb is running as root: adb root
  • Use the adb push command to push frida-server to your phone:
  • Change the permissions of the server using
    adb shell chmod 755 /data/local/tmp/frida
  • Confirm the version of frida-server matches what you installed using adb shell /data/local/tmp/frida --version
  • Once frida is on your phone, you need to downgrade SELinux to "Permissive" using adb shell setenforce 0 & adb shell getenforce:
  • You should now be able to run the frida server using adb shell /data/local/tmp/frida&

Disable SSL Pinning (hopefully)

Floating around the internet is a universal snippet of code for disabling certificate pinning using Frida. Most widely used apps will have implemented pinning within their app, but there is a surprising number that rely on the built-in SSL pinning for android. Our app happens to be one of them.

To reverse pinning, all we need to do is hook into the app and run the following code:

Java.perform(function() {

    var array_list = Java.use("java.util.ArrayList");
    var ApiClient = Java.use('com.android.org.conscrypt.TrustManagerImpl');

    ApiClient.checkTrustedRecursive.implementation = function(a1,a2,a3,a4,a5,a6) {
            var k = array_list.$new();
            return k;
    }

},0);

We can do this using frida-cli. Go ahead and open another terminal and attach to your process:

frida -U process-name

Make sure you use the -U command to specify that you want to attach to the USB device and not your computer

You can find the process name using frida-ps

You should now be inside the frida REPL. Go ahead and copy the above code into the REPL. If everything goes well…nothing should happen.</p>

Now head back over to Charles. Hopefully you will now be able to sniff requests!

If not, I’m sorry but you’re out of luck. The app probably has pinning built into it and you are going to have to some more drastic things to disable it. Perhaps another post for another time?

And what was that security risk, you ask?

They seem to be setting the price on the client side :s

13 Oct 2019

Tips From a Self-Taught Dev

Over five years ago, working as an archivist as the University of Canterbury, my manager linked me to the coding-tutorial website codecademy with a vague comment of “you might like this”. I still remember the homepage – a sign-up form with an embedded terminal next to it and a message employing me to write my first line of code: print ‘hello world’. Quickly I typed those three words, hit enter, and watched the terminal dutifully spit out my message:

hello world

I was hooked.

Read more...

In the months that followed it became increasingly clear to me that I wanted to make software my job. Whenever I worked with code – whether that making my way through a tutorial, building a little project, or hacking things my team used – I lost all awareness of time. Hours passed by like minutes, lunch breaks were missed, I found it hard to go home at the end of the day, sure that the solution to whatever problem I was working on was right around the corner. My job no longer felt like work. I loved what I was doing.

Over the next few years I managed to morph my archive job into a technical role but it wasn’t until 2017 that I was able to make the leap from an English grad with some technical skills to a real-life bona fide software engineer. Often I think about those times, about the things I wish I had known that would have speed up the process of becoming a dev. Overtime I have curated and polished this list into something resembling tips for self-taught developers. I hope that these will be useful for other people looking to make the same journey.

Use the same tools as devs

If you’ve spent anytime around developers you will know that we love talking about tools. Like a painter knows their paint brushes, and a chef knows their knives, so too does a developer know their code editor, version control software, and database manager. Understanding these tools and how to discuss things about them goes a long way in an interview.

Obviously if you are not a developer you might not know what tools developers even use so I will be more specific with my recommendations:

  • Learn how to use git to store code locally and remotely on a hosting service such as github or bitbucket

    For the most part, all you need to know to get started is how to add, commit, and push code to a repository. But if possible I would also recommend learning how to resolve merge conflicts (when two people edit the same line of code and a decision has to be made about what changes should be kept). If necessary, checkout your code in two different places and resolve conflicts you have deliberately created so you can see how the merge conflict works.

    When you are self-taught, Github is like a business card for you, since you don't have work experience to backup your skills. Store your best work on there and direct people to it. That way they can see that you can code.

  • Use a code editor such as VS Code with debugging, syntax highlighting, and git support. Better yet, try out a number of different editors and find which you prefer. Not only will it make writing code so much easier, it will also give you something to talk about in your interviews. For bonus points, try out vim and add some basic customisation

  • Learn how to use the terminal for basic tasks such as changing directory, searching for files, and renaming or moving files. As a developer, the terminal is one of your most powerful tools and at times the only access you may have to a machine. I highly recommend this website.

  • Play around with the developer settings and tools on your phone and web browser. Setup developer accounts on Facebook and Twitter and see what they will let you do. Part of being a developer is poking around. Don't worry if you don't get anywhere with it. It's about familiarising yourself with data and how it is structured, as well as the tools that are available to manipulate it.

The language you pick doesn't matter too much

A common question I get from people thinking about transitioning into software is “what language should I learn?”. C, JavaScript, Java, Python, Ruby - there are so many languages to choose from so I understand the question. It seems that if you pick the wrong one you might be relegated to one area of software development and miss-out working on something you really love.

While some languages do align well with different kinds of development (mobile developers tend to use Java and game designers often use C++) this doesn’t necessarily mean you need to learn this language to work in this area. Many places will happily take on a developer with experience in a different language from the one they use so long as they show a thirst to learn. You can also start by learning JavaScript and Python and move onto Java later when you are more confident. Most developers have fluency in a few languages and knowing a little of one can help you understand the limitations and benefits of another. What’s more, since most languages use similar building blocks and concepts, you knowledge of one language will almost certainly help you pick up your second.

My advice to new developers is always to pick a loosely-typed, syntax-light language like Python or Ruby first. From there, you could move into Java or C++ if you are interested in working in mobile or hardware/games. Of course, by all means jump into any other language that interests you. What’s important to realise is that languages are merely tools that engineers use - they do not define us. Being able to pick up and learn new languages and tools will make you much more successful as a dev than any specific language you know.

Get to know other devs

The best thing you can do as a self-taught dev is to get to know other devs working in the industry. They will not only provide you a looking glass into the world of the dev (what tools they use, what their day looks like, what kinds of businesses and products exist) but if you’re lucky they may mentor you, or in future, even give you a job.

When I was learning to code, I spent a lot of time on my own nutting out problems that could have been solved in minutes if I had asked an experienced dev. In some ways I’m glad for the resilience this gave me and the deep understanding of the tools, but I also feel I could have learned so much faster if I had been less afraid to ask for help.

Luckily one of my close friends lived with a developer who I would talk from time to time. He took an active interest in my learning and would often give me little tidbits of knowledge that helped me along the way. In particular our conversations helped me to build the language of a dev. I began to find help online more successfully since I now knew the terminology that other devs used. Eventually, he recruited me into the company he worked for and we worked alongside each other for years. Getting to know him was definitely the best thing that happened for my career.

If you don’t know any devs, then search for a meetup in your local area. There’s usually a number of groups in each city covering a range of different interests. People are always happy for new-comers, even if they have no experience in the subject. If you follow what interest you then you and bring passion and enthusiasm to what you do, then the people you meet will be more than happy to help you along the way.

Embrace the confusion

Learning a new language, framework, or tool is often extremely difficult and confusing and when you are doing it without support of a structured programme or teacher it can be hard to know whether you’ll ever understand. From my experience, what makes a person successful is the ability to sit in that feeling of confusion for as long as they need to figure things out.

I used to work with a woman who was incredibly smart. She easily had the ability to pick up the tools and languages that I had taught myself. But she was used to being the top of the class and every time she tried something new she expected to be good at it straight away. If she didn’t understand it she would become flustered, fearing - I think - that she would reveal an underlying secret that she was not good enough. We all know what that’s like, and I think self-taught devs are always going to deal with impostor syndrome from time to time.

But remember: this stuff is hard. It takes very intelligent people years to master it and many of those who seem like they can do it with ease have been learning since they were children. Feeling confused by something is not proof that you are stupid but that you are challenging yourself. And how do we get better at things? By never being afraid to take on our next challenge.

So embrace the confusion. Tell yourself that you are brave. Remind yourself of times when you found the things you now know difficult to understand. Because the confusion will never go. You will always be taking on new challenges if you want to work in software.

And there you have it, my four tips to becoming a self-taught dev. There will probably be more things I will think of in future but for now I think that these cover the basics pretty well. I wish you luck on your journey and hope that you will write a similar post for other self-taught devs one day.

23 Oct 2017

First Post

So I thought it was time to start a blog. I’m learning so much in my day-to-day job that it seems silly not to share it with the world.

Some things about me…

  • I am a self-taught programmer with a degree in English literature. Like many woman in the industry I didn't realise I liked coding until after I had graduated. Sometimes this makes me feel like I've fallen behind my fellow coders and other times I feel like I gained a lot from studying what I did. Perhaps a post for another day?
  • When I'm not coding, you can find me rock climbing, tramping, or reading and writing science fiction.
  • This year I founded a science fiction magazine called Sponge which publishes short fiction from NZ and Pacific writers.
  • I work for a startup called Mish Guru, helping to build their Snapchat management and analytics platform. We work in an open-plan workspace in town and have colleagues all over the world.
  • I have two adorable burmese cats named Vienna and Ash.
  • I am terrible at updating blogs!!

Let’s hope I can fix that last one.

Over and out!