2015 Scholarship Recipients Archives

November 10, 2015 By Lisa Ghisolf Leave a Comment

Why Speak? Tips for the Unsure

This entry is in the series 2015 Scholarship Recipients

Speaking at a conference can be a harrowing prospect: Dozens, if not hundreds of faces listening to your every word, your possible stumbles. Will they disagree with you? Do you even know what you’re talking about (imposter syndrome, anyone?)?

As a career move, speaking is a great way to establish your expertise and garner networking opportunities. But how do you get started? How do you overcome the negatives?

Although we had a Speak day at WriteSpeakCode, I feel like the start is actually in blogging. Here, you can test out ideas and work out where you have a true voice.

On both Write and Speak days we did five-minute topic brainstorming – coming up with at least 10 topics, with no editing. It’s here where I feel like other relevant topics, like digital nomading, come to light. And it’s these unique perspectives that seem to call me most, though finding their venue may be tougher. But it’s inspired me to keep a list of topics to draw on in Evernote, so inspiration doesn’t have to strike when I need a new idea done, now.

Passion for your topic and clearly delineated benefits to the attendee were stressed as musts for any proposal you submit. Giving a topic your own personal spin wins out, as does talking about a situation you’ve overcome.

And finally, what do you know? More than you think. Some WSC attendees stressed how they’ve learned from newbies as much as from pros in their respective tech spaces, and a fresh perspective keeps us grounded. Regardless of your skill level, there’s always someone who will need to learn what you know, and appreciate your perspective.

Many conferences are starting to designate themselves as safe spaces, so real dialogue is achieved. One WSC panelist noted that she saw a female programmer taking questions after a conference talk, and she was only asked about what she was wearing – not the topic of her talk.

A few conferences are designating watchers to shut down negative and debasing talk, even going so far as to eject participants for egregious behavior. WBC panelists stressed shutting down this talk with a statement that you are keeping to the topic, or simply not allowing questions, is the speaker’s prerogative.

This is an issue without a clear solution, but clearly one that needs to be addressed. And I must say in the speaking gigs I’ve had, I’ve not met with doubters or negative talk, but I’ll be sure to have a statement ready should this become an issue.

The takeaway that has stayed with me most, is that the audience wants the best from you. Few attend a talk to see the speaker fall: They want to pick up your perspective or knowledge, and walk away better for it. I always try to imagine them cheering me on, and focus on the smiling faces in the crowd.

As for questions that are tough to answer, I usually defer them to look into – as so many are often deeper conversations that require more than an off-the-cuff answer. But this can be an opportunity for networking and deepening your connection to an attendee, or even an inroad to a new topic of interest.

And as WSC speaker Neha Batra put it, just get out there and do it. Because you have nothing to lose by doing so, and nothing to gain by not giving it a shot.

Putting Your Impostor Syndrome to the Test

This entry is in the series 2015 Scholarship Recipients

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.

knew

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?

The elephant in the room: Impostor Syndrome

This entry is in the series 2015 Scholarship Recipients

Many of us suffer from it, but it is rarely brought up, or even given a name. The quick definition is, a psychological phenomenon in which people are unable to internalize their accomplishments. And for women especially, we tend to take this to heart, by staying in bad situations too long (remember that awful job, anyone?) or working too hard. Then it becomes a self-fulfilling prophecy filled with stress and eventual burnout.

Thankfully, Neha Batra has an action plan to rethink and recenter this conversation, rather than the usual platitudes. Because, at the end of the day, we all have something to say. We’re all experts. Recognizing this and owning it will take you much farther than never trying at all.

First, recognize the language you use with yourself. Thinking you’re lucky or just “fell into this,” isn’t really the self-talk you need. Next, separate facts from feelings – what would make it a good thing if it happened? Would it be good for your career, your client prospects?

Analyze the facts of your situation: What makes you qualified to do this talk, or to apply this job? Make a list of your accomplishments, the programming languages you know, the experiences that have brought you here. And, rewire; keep in mind, what’s the worst that could happen? I’ve heard it again and again (and again today) that your audience wants the best from you, they want to see you succeed. More often than not, you have something to share that others can benefit from, at any skill level. Is your perspective on an issue unique? Think about giving back to the community and those who are before you. Newbies can learn from pros, and vice versa.

Probably most important, do it. Put yourself out there, and try it. All the work to this point doesn’t mean much if you don’t step up and take the chance.

Finally, reflect once it’s over Were you right? What can you walk with with, for the future? And don’t forget to celebrate: You’ve accomplished something for yourself, and for your audience. And that’s reality.