Getting Past Biases

As I was growing up, certain biases were established that I never thought I would get past:

  • Pink is a girl’s color, and blue is a boy’s color. (Oh, marketing folks… social “norms”…)
  • Lawn mowing is a man’s job. (My dad never had my mom mow the lawn.  It was always a job for my dad and my brothers.  Forget that I was actually interested in it.  He wouldn’t have it.)
  • Internals (of programming languages and systems) are for super smart people who need masters or doctorates to understand.  Specifically men.  (Because in college, they didn’t show a lot about women in tech, so they didn’t really stand out.  Sadly.)

However, as I’ve gotten older, I’ve gotten past a lot of the biases, especially:

  • Even my kids will tell you, colors are colors.  Don’t let the marketing world and their bias of associating colors with genders sway you otherwise.  It’s not the end of the world if either of the boys are drinking from a pink cup.
  • Lawn mowing can be done by anyone.  I had an 80+ year old neighbor start my lawn mower one day because my husband was on the other side of the world for a family trip and I couldn’t stand waiting a week and a half for him to get back… but I also don’t have the strength to start a mower with a pull.  Since that one time and one lawn mower later (EGO! Electric and push button start!), I LOVE lawn mowing.  A moment of Zen…

The one thing that I took awhile to break past was the thought on internals.  I’ve been in tech just over 15 years, and up until recently, this bias had clouded my judgment.  It made me question if I would ever be technical enough to do this.  But… something snapped.

Did you ever find yourself job hunting, look at a job, and know “this one… I need to apply.  This is the right thing at the right time.”?  I had that recently happen.  Now, keep in mind that I left a full-time position at the end of last year so that I could focus on my career and go back to independent consulting.  So some people are going, “wait… going full-time?  Would you really ever consider that again?”  And yes, for the right opportunity, I would.   But… what is the right opportunity?  That remains subjective.

In this case, there was an opening on a team that I had known of and watched over many years.  I saw the position and tried to close the tab and let it go.   There was a mention of internals of a product, and as soon as I saw “internals”, I figured “I don’t know about that…” and would let it go.  However, my mind and my heart had a different plan.  When I woke up the next morning, I knew that I would regret it if I didn’t apply.   If I didn’t give myself the opportunity to try… the opportunity to not be afraid of the mention of internals… the moment to realize that the bias I had all along was so incorrect… if I didn’t do that, I would regret it later.

Am I past the fact that internals may be for super smart people and that women can get into them too?  Yes.  My internal dialog switched from “Internals… removing the magic from behind the curtain… seeing what really makes things happen… keeping it efficient. Go masters and doctorates to have enough understanding for this.” to “Seriously, Sarah?!? You loved Mark Russinovich’s Sysinternals talks.  When it comes to languages and tools, you love to play and see where their capabilities are.  You have super debugging skills and aren’t afraid of jumping into a codebase, knowing that your debugging skills are what makes that magic happen.  Programming languages and the tools we use are not that different from the applications you’ve written in the past – you have to see them as applications themselves rather than thinking they are something completely out of your league.  Also… all the things from data structures in college… that finally makes sense thanks to practical use in the field.  So wake up and know that you can do this!  Apply!  You’ll regret it otherwise.”  So I applied.

And….?  Nothing yet, as it’s still early enough in the job application process.  Also, this is holiday season and end of the fiscal year season for many folks, so it’s a bit of chaos now.  But, if there’s interest, who knows what lies ahead.  And if there isn’t interest, well, at least I applied and got past the bias of thinking that internals were just for folks more degreed and smarter than me.

The point is… when we’re younger, it’s possible to form certain biases. As we get older, if we keep an open mind, we may be able to see where the biases lead us down wrong paths and how to grow past those biases.

My Super Power – Debugging!

Almost every night, my boys want me to read books about Iron Man, Hulk, Spiderman, Thor, and even the Guardians of the Galaxy.  They are all about superheroes and villains and super powers.  This had me thinking about all of the skills that make me who I am and if I had to choose one, what would be my super power.

The Engineer – Taking Things Apart

I’ve always loved tearing things apart and seeing how they work.  Whether it was with brute force or – later on – with a methodical approach and with tools, I was always curious and inquisitive.  How does this machine work?  Why does it work this way?  What if this were tweaked a little?

The Creative – Assembling Things

Like a double decker couch!  (Ok… or not… )  When it comes to learning how to work with things, I find that I enjoy assembling things as well.  Whether I am using power tools like I did while working on steel-framed houses for Habitat for Humanity or  using Allen wrenches for IKEA assembly adventures, as I assembled things, I found myself analyzing what I was building, where it seemed strong, and where the flaws may be.

The Super Power – Taking Things Apart + Assembling Things = Debugging!

When it comes to my core, my super power definitely lies in debugging.  Whether it was the power of the alert() in JavaScript or the Console.WriteLine() in C# or the cout>> of C++, I used to write a bit of logging out to the screen for immediate gratification to help me debug before we had decent debugging tools.  If I was debugging something over time, I would write log files.  (And yes, I’m one of those weird people who enjoys reading log files.)

As debugging tools appeared in our editors, I found myself being even more efficient in figuring out what was broken and where I went wrong.  Stack traces became less foggy and more sensible.  Error codes became more searchable.  Nowadays, you can find me working with debuggers in IDEs, other editors, and even in the browsers.  From breakpoints to variable inspection, drilling into methods to tracing the call stack, most debuggers offer a lot more support and information that I hardly have to write out to my screens.  I don’t even use console.log() in JavaScript much because web browsers’ developer tools and debuggers have matured in that regard.

Whether I am maintaining my own codebases or learning new ones, I find debugging to be that super power that makes me pick up patterns and understanding as quick as I do.  With a good debugger, I find myself solving a lot of problems a lot quicker than my old school debugging ways.

My super power lies in debugging.  How about you?  What’s your super power?

Rockstars Need Not Apply

My friend Doc posted this on Twitter, and it really grated on me, so much so that I’m compelled to write.

Meet Bill.
Bill’s a rockstar programmer.
He codes fast.
Bill doesn’t need to refactor.
He codes fast.
Bill’s too valuable to take support calls.
He codes fast.
Bill doesn’t pair; it’s inefficient.
He codes fast.

You should hire Bill.

‘Cause we don’t need his kind around here.

In the 15 years I’ve been in the field, I have seen “that person” a few times, and when I do, there usually has to be an intervention or a call to reality.  Somehow, I’ve become the “go to person” for these tough conversations, bringing people back to earth gracefully.    So let me share why these things grate on me.

The Rockstar Programmer

Rockstar, unicorn, ninja… these are all terms I hear when companies are looking for “the ideal candidate”.  I groan at every mention of those.

When I hear these terms, I know they are looking for candidates who have ALL THE SKILLS, can be masters of technologies in short periods of time, and sets expectations high.  They want bigger, faster, stronger.  However, with rockstars come egos, and “the rockstar programmer” is seldomly a team player.  They are the lone wolf who insists they can do it on their own.

Does Not Need to Refactor

Wait… does not need to refactor ever?!?  Typically, the end product isn’t written right the first time.  Missing scope tends to be common.  Having peers review code, there are opportunities to learn how to improve code or possibly take other approaches.  And if he does not need to refactor but his code happens to suck… yay for technical debt. 🙁

Too Valuable to Take Support Calls

The most productive, most valuable pieces of code I’ve written have been from user feedback.  Whether it’s understanding a user’s environment or realizing that a feature we thought was usable was more confusing than usable, there is always room for improvement.  Your users are the ones who are your job security – without users, your product has no reason to exist.  I have had employers think that I was too valuable to speak with end users, but in the end, I opted for opportunities where I could talk with the users and show the employers just why support calls are important.  Maybe it’s because I have done some time in support (and even managed a technical support team) – but I don’t think any developer is too valuable to take support calls and learn about the pain points in their products or services.

Doesn’t Pair as It’s Inefficient

I have had inefficient pairing sessions, so I can understand where people may think it’s inefficient all along.  Like any methodology or practice, I see pairing as a tool that can be useful when understood.  I love considering pairing as a tool for on-boarding new folks – knowledge transfer and having those on the team already gauge where the new person may need more guidance and support.  I also appreciate seeing some teams pair a QA person with a developer to have the QA person help the developer understand thinking like their users and for the developer to help the QA person automate tests.  Is pairing inefficient?  It can be with the wrong pair of people or under the wrong circumstances.  But… it can also be useful.

Bill Codes Fast

<sarcasm>Ready… set… type!  Code as fast as you can.  Make as many bugs as you go.  Forget about readability – it’s all about speed.  Forget about maintainability – again, it’s all about speed.</sarcasm>

Just because someone can code fast doesn’t necessarily mean that it’s working code or the right feature or… hopefully, you get the picture.  Coding fast doesn’t necessarily mean it’s a good thing.

Hire Him… We Don’t Need His Kind Around Here

At what point do we decide that we don’t need his kind around here and have the hard talk that he has career-limiting behavior?  If we have that talk with him and if he’s willing to try to change, would you give him the opportunity to change?

2018… The Year of… Python?!

Over the past few years, I’ve been dealing with things in C# and Java, especially in bringing newcomers to the field and helping those who may be older in the field get some new tools.  I fell into this groove with C# and Java, and yes, I even had a change of heart with Java.  (When I saw Java in the late 90s/early 00s, it was a strong dislike relationship.  Nowadays, I actually like it!)  Little did I realize that this year would be a departure from C# and Java and cycling back to another one of the languages in my toolbelt – Python!

Early 2018 Changes

I left my last employer at the end of 2017, as I could feel the winds of change and knew it was the right time for me to move on.  What I hadn’t anticipated was my direction.  I figured I would stay in the training realm with more C# and .NET-related topics.  However, I picked up a client in the Python space and in the process, dusted off the cobwebs in my Python space as well as ramped up JavaScript yet again with React and Redux.  Wait… Python?!?

My History of Python

I don’t remember what it was that convinced me to look at Python.  I suspect it might have been talking with a colleague decades ago and his mention of the local Python user group.  I do know that once Microsoft entered in the Python space with IronPython, I had to see what it was about.  Python on .NET?  What?! (Ok… part .NET, part Mono….)  The absurdity of Microsoft bringing Python in .NET really appealed to me.  Why?  I’ve been a Microsoft fan all of my life, and then there’s the part of me that likes Linux and the command line as well. So when any of those can be combined, I’m intrigued.  Little did I realize that my playing around with Python as a hobby back then would lead me to present IronPython on Linux at PyCon 2009. (Oh and the team was in my audience… yeah, the IronPython team… and the father of the language… oh, no pressure.  Argh! 🙂 )

Back then, I didn’t want to be the only one playing with this.  I did some user group and conference presentations introducing C# folks to Python.  In 2008-2010, I made my rounds to local user groups and conferences (Cleveland, Columbus, Cincinnati, Sandusky, Dayton, even a Cincinnati financial company’s internal group).  I took a break from Python towards the end of 2010 because book writing took over my life PowerShell distracted me.  However, my inner polyglot shelves languages for later, never really forgetting them.

Return to Python

Since I picked up a client who used Python, I figured I better brush up on my Python again.  This time, while going through my day-to-day work, I also went through some of the Python training over on DataCamp.  (How I love DataCamp’s courses!  I’ll save that for another blog post.)   What I love most about picking up Python again is seeing how quickly I regained my muscle memory/coding memory for the language.  I had to pick up some Python 3 changes, but because a lot of the concepts are similar to what I’ve seen and done in other languages, it’s been syntax adjustment more than anything.

In addition to returning to Python code for some of my consulting work, I also fell for Brian Sherwin and his Drops of Jupyter talk).   Data has always been a love of mine, and poking at the data science realm in Python…. so much fun!

Also… Microsoft has been growing in the Python space since the last time I did talks on Python.  So now I can include the likes of Python Tools for Visual Studio (PTVS), Visual Studio Code, and Azure Notebooks in my Python presentations.  Yes – Microsoft is in the Python space!  Anaconda now ships with Visual Studio Code.  And Visual Studio Code has LiveShare, so you could remote pair program in Visual Studio Code on multiple platforms – or even have someone LiveShare in Visual Studio Code in Linux while someone else is in Visual Studio in Windows.

So what lies ahead?

Apparently, 2018 is my year of Python so far, and I’m curious to see where it leads.  I didn’t plan on going this route, other than looking into data science more.  I was excited to see Python in SQL Server 2017 – again, this is an absurdity thing for me that makes me more curious.  I end up playing with the technologies, learning how I can work with them and others can, and then turn them into presentations.  Working with Python for a client brought Python back into the presentation topics.  With Python growing in the Microsoft space and with it huge in the data science realm (which is growing as well), I don’t think Python will be leaving my topics for awhile.  I already have some local user groups reaching out to me to deliver my Python for C# Developers talk (1st presented in Hong Kong this year), and if this is something you’re interested in seeing, let me know!  (Yes, I am interested in doing remote presentations and not just in-person.)

Internationally Speaking!

2018 marks 10 years (and a little of change, counting my 1999 stuff) of speaking in the tech community on a variety of technologies:

  • Linux Administration (Samba)
  • Squeak
  • Python (and IronPython)
  • SQL
  • Silverlight
  • Cross-Platform Development with C# and Mono
  • PowerShell (for IT administration and for developers)
  • HTML 5

I have spoken on other technical topics as well:

  • ATDD
  • Test-Driven Development
  • General Debugging Tips & Tricks
  • User Experience for Developers
  • Responsive Web Design

I have also spoken on other topics:

  • The History of Women in Tech
  • Servant Leadership
  • Mentoring
  • Social Media and Marketing Tech Events
  • Google Analytics
  • Women & Diversity in Tech

I have done some major talks:

And now I can add the badge of international speaking!

Sadukie presenting The C# Dev's Intro to Python at the Microsoft Developers HK Meetup

Sadukie presenting The C# Dev’s Intro to Python at the Microsoft Developers HK Meetup – photo courtesy of Kevin Dutkiewicz

Why did it take so long?

There are many reasons why I haven’t submitted to speak internationally:

  • My primary audience is within my region.  I rarely need to leave here.
  • I was honestly afraid because of language barriers.  English is my primary language, though I have some basic understanding of Spanish.  I don’t really have a secondary spoken language. I worried about having to deal with that.

So… why now?!

We were travelling to Hong Kong to visit family (and yes, #ancestraltrip for those following along on Twitter).  I was curious about the technical communities over there, and since I know a little about Hong Kong’s background, I suspected that there may not be as big of a language barrier as I originally suspected.

When I reached out to their group, they offered to have me speak, and it seemed like a great opportunity that I couldn’t pass up.

How’d it go?

It was a wonderful experience speaking with the Microsoft Developers HK Meetup on “The C# Dev’s Intro to Python”! Their community is a great group of folks – islanders and main land folks.  They’re enthusiastic and really enjoy learning more.  It was great to see their energy and feel very welcome.  Special thanks to Stephen Tung (cheers for bringing VLT!), Thomas Weiss (especially for meeting me in person at the MVP Summit – great to have a familiar face to meet again), and Bart Verkoeijen (getting me directions and set up at the venue)!  These organizers were very welcoming, and my husband and I enjoyed going out with these guys and Michael (one of the group members) for pizza afterward!

For those who want to learn about what I presented:


Code for presentation:

Azure Notebook for presentation:

Will I do it again?

Absolutely!  I would love to come back to Hong Kong to present, and I could be up to other locations as well, especially if I already am travelling that way.  The tough part about international speaking is the cost (especially if visas and airfare are involved).  So if I can coordinate multiple events, that makes it a bit easier to swallow.