I guess I’ll start off with a bad-ass introduction for myself.

Ahem. Hi everyone! My name is Emma Grasmeder and am a recipient of the Write Speak Code LBTQA Scholarship for 2015. Although I’m now the lead data scientist at Solebrity, my background is primarily microeconomics, which I studied at the PhD level while a research fellow at the Center for the Study of Neuroeconomics at George Mason University. I’m also the Director of Language Study Groups for Women Who Code DC. (I’m @emma_Gras on Twitter)

I thought I was gona sit down and write about the Write Speak Code conference, or about being a trans woman there or in tech in general, but instead I wrote this. We’re going to start with basic coding tips and end up turning our lives around using Test Driven Development. Ready? Doesn’t matter; let’s go. (Of course you’re ready)

Mastery of programming depends on having a variety of problem-solving skills to draw upon when the program doesn’t work as expected. Something as trivial as a mis-placed symbol might cause the program to behave very differently. We call these “bugs” because they are tiny in comparison to the damage they can cause. They creep into our code unnoticed, and it’s only much later when we’re running the program on some new data that their presence is detected. Sometimes, fixing one bug only reveals another, and we get the distinct impression that the bug is on the move. The only reassurance we have is that bugs are spontaneous and not the fault of the programmer. Flippancy aside, debugging code is hard because there are so many ways for it to be faulty. Our understanding of the input data, the algorithm, or even the programming language, may be at fault…

Since most code errors result from the programmer making incorrect assumptions, the first thing to do when you detect a bug is to check your assumptions. Localize the problem by adding print statements to the program, showing the value of important variables, and showing how far the program has progressed.

Once you have localized the problem to a particular function, or to a line of code, you need to work out what is going wrong… Check your understanding of the code by reading some documentation, and examining other code samples that purport to do the same thing that you are trying to do. Try explaining your code to someone else, in case they can see where things are going wrong.

– Natural Language Processing with Python, by Steven Bird, Ewan Klein, and Edward Loper

Bugs in your code are either typos or problems with your assumptions. That’s it.

And you find both by testing. Some programmers test casually (with print(), for example), and other programmers let tests drive their entire development process. Test Driven Developers require more time for the simple tasks, but find their efforts rewarded when working on the complex tasks. It’s a choice you have to make (but seriously, make the right choice and #testYourDamnCode).

This is test-free programming works: you provide inputs and you get outputs.

f(Unknown Quality Inputs) = Seemingly Understood Outputs

This is how testing your code works: you provide inputs and demand outputs.

f(Good Input) = Known Output; else yell_at_me("Unexpected failure)
f(Bad Input A) = Exception A; else yell_at_me("Exception A should have happened")
f(Bad Input B) = Exception B; else yell_at_me("Exception B should have happened")

(Usually it’s done with assert statements.)

If an input doesn’t map to the expected output, you check your tests and your functions, informed by your understanding of the language. What inputs am I giving? What is the function supposed to do? What outputs should I get?

If you know your inputs are right but your outputs aren’t always what you’re testing for, then your function doesn’t do what you assume it does.

You’ll need to ask yourself, “is the function too complex?” You know it’s passed the right input, but something happens, somewhere. Maybe you need to break the function into smaller units. We teach our students at Women Who Code DC’s python night to shoot for 3-5 line functions. Every function should accomplish a single, testable thing.

If those bite-sized functions still don’t convert Input into Output as you expect, you should probably check your understanding of the language. Either your input doesn’t behave like you think it does (that integer isn’t iteratable!) or you’re not using it in the right way (“but I thought "HelloWorld".split() would split a string object by *characters* if no “\n” were present…“)

Testing allows you to refactor your code with more confidence after your boss tells you to add/remove features from your software. If you change a thing in the wrong way, your tests will yell at you because you broke them. It’s nice to have a piece of software that tells you when you can feel confident about your code again.

Moreover, testing your code will force you to write better code. Simply knowing that you have a program (or team of programs) dedicated to calling you on any bullshit, you write will probably not write as much bullshit.

-record scratch-

While I’m on the topic of Bullshit, let’s talk about Impostor Syndrome. Impostor Syndrome is a bug in your source code. Everything it’s telling you is (say it with me) bull shit!

But we all know that putting code to the test keeps it honest and as a result, we end up with better results. And so my suggestion is that we continually put Impostor Syndrome to the test.

I think Impostor Syndrome is the result of years and years of untested and unreviewed thought-code, getting modules added on top of other modules with sorely few reality checks as time goes on.

I’m going to use my experience in grad school as an example of the faulty assumptions Impostor Syndrome needs to continue operating.

Background:
Two weeks after I returned from my job as an au pair in Austria, I started at my first computer scientist position. About a month later, I was accepted into an economics Ph.D. program. This was all very exciting considering I’d never written a computer program on my own or even taken an economics class. I just have a B.A. in Religious Studies, after all.

Day 1, being surrounded by to-be and would-be economists while I didn’t even know how to pronounce Keynesian economics produced in me the most intense Impostor Syndrome I can imagine. And I sustained it at such high levels for the duration of my stay in academia!

Let’s look at some dialog between me and my Impostor Syndrome:
I kept my scholarship through my entire first year!

“Everyone’s going to find out that you don’t know anything about economics.”

I passed the microeconomics computational exam, even though half the class didn’t!

“You got lucky that most of the test was on the math, and not as much on the economics. It’s still just a matter of time.”

Ugh. Shit. That final exam cost me my scholarship.

“You knew this was inevitable…”

and then let’s look at what Impostor Syndrome was actually saying in those attacks:

“Everyone’s going to find out that you don’t know anything…”

Assumptions:
1. You don’t know anything about this topic
2. Your not knowing anything at the onset of this topic makes you inferior
3. Everyone else can see all the details about your situation and will judge you negatively
4. Everyone else feels confident in their own situation
5. Everyone’s opinion of your abilities is somehow relevant

“You got lucky the task was compatible with your skills.”

Assumptions:
1. Your skills, acquired in the past (through years of studying math), aren’t worth anything
2. Your tangential skills didn’t contribute to your accomplishment.
3. The other people who passed the test with you weren’t comparably lucky
4. The folks who wrote the test were unable to write a test that economists can pass but mathematicians can’t

“You knew your failure was inevitable.”

Assumptions:
1. Failure was inevitable
2. Losing a scholarship is the same thing as failing
(Note: 10-20 other people lost their scholarship because of that test)
3. The other people who lost their scholarships even though they had economics degrees are still more legit than you

As you can see, lots of pretty bold, not-empirically-sound statements here. Putting each assumption through a quick, mental unit test quickly shows me that I don’t actually believe anything I said to myself. My more objective self can look at what I’m letting myself believe and I can see that it’s… bullshit!

Unfortunately, I can be in the midst of all that and still say to myself: “I know making it 3 years in a Ph.D. program before dropping out, initially having no background in the subject is an accomplishment, not a failure,” but I still feel like a failure.

I guess I’d say that the unit tests all pass, but I’m not checking all the cases in my functional tests.

Here’s the hard part: most of the software that’s getting messed up from the Impostor Syndrome code is closed off. Most likely, it’s from external libraries that we generally need to keep in order to keep living like a normal person; things we’ve used since childhood. Things we can’t really access.

I’ve learned that when dealing with input and an unpredicted error comes up, there’s usually no time to stop all production and debug it. Instead, we can store the messed up record for examination later. So when Impostor Syndrome is telling you something, you might not recognize it at first. As soon as you realize that it doesn’t pass the sniff test, just like any bad records that come in through your data pipeline, flag it, put it in “limbo,” and move on. Impostor Syndrome won’t hit you at a convenient time, so don’t wait around for a good time to address the insecurities all at once. Just allow yourself to fuck up. You probably can’t tell the difference between an actual fuck-up and Impostor Syndrome telling you bullshit anyway. This will let you deliver continuously, producing a delightful product that improves over time: you.

If we don’t examine and test our processes all the time, if we don’t just get the product out there now (yes, even before it’s perfect), when will we? Our testing keeps us improving, we’re developing continuously so we’re gona stay on the right track if we just focus on the objective metrics.
I know I’ve spent way too long in stealth mode, waiting for the my product (me) to be perfect. Realistically, it never will be and it already is. Get yourself out there.

We are the Stakeholders, the Owner, the Leader, the Experts in our own lives, and it’s time you launched.
What are you going to deliver today?