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:

Slides: https://www.slideshare.net/sadukie/intro-to-python-for-c-developers

Code for presentation: https://github.com/sadukie/IntroToPyForCSharpDevs

Azure Notebook for presentation:
https://notebooks.azure.com/cletechconsulting/libraries/introtopyforcsharpdevs

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.

 

Visual Basic 6.0 Programmer's Guide, along with PHP and Perl books on sadukie's bookshelf

My VB.NET Story

In my MVP Summit recap, I mentioned that I want to help contribute to the docs on docs.microsoft.com, including Visual Basic.  Many people know that I’ve focused on C# the most in the .NET stack, followed by PowerShell.  VB.NET didn’t get as much focus career-wise for me, as I had a rocky start with it and really fell for C#.  However, I will forever have a soft spot for Visual Basic.  But why?  This is my story.

Continue reading

MVP Summit 2018 Recap

Last week, I was out at the Microsoft MVP Summit in Redmond, Washington.  As many people know, I’ve been a Microsoft fan all of my life, so going out to the main campus is like a pilgrimage to me.  I made sure to wear some of my MVP gear on the flight out, as it’s a good way to find other MVPs.  While there were none flying from my starting spot, I met up with a bunch of MVPs – Azure, Outlook, Visual Studio – in Detroit.

Sadukie wearing her MVP hoodie and MVP jacket on the plane

Continue reading

Speaking Topics for 2018

Last year, I added data science to my talks.  This year, I’m planning on growing more of my technical skills – learning React, Vue, and Node.js.  In terms of talks, servant leadership has joined the family of topics, and it’s a topic I’m excited to present.   These are just some of the topics I am presenting in 2018.

Data Science with Python, R, and SQL Server

In 2017, I had a goal to start looking into data science topics and see what’s in store.  By the end of 2017, I started talking about how you can use Python and R on SQL Server to bring the computations to the data, rather than bringing the data to the computing.  With regards to adventures in 2018, I plan on continuing looking into data science topics and continue talking about Python and R and how they can be used on SQL Server.

The next talk for this is:

  • The Polyglot Data Scientist – Adventures with R, Python, and SQL – CodeMash – 1/12
  • The Polyglot Data Scientist – Adventures with R, Python, and SQL – Cleveland .NET User Group – 1/25

Mentoring

Mentoring was a topic that came up a couple years back and continues to come up.  Whether it’s from the perspective of being a mentor and how to become a better mentor or from the perspective of being a mentee and how to find and engage mentors, I have talks that address various angles of mentoring.  My career wouldn’t be this successful if I tried to go this alone – I have wonderful mentors in various aspects (tech, business, and life) who have guided me along the way.  In my past roles, I’ve had the privilege to mentor over 200 career shifters who have wanted to go into development or who have been in development a short time.  I also am in the process of formalizing mentoring programs for those who want to do formal mentoring programs at their companies but aren’t sure how to implement it or how to administer it.

My upcoming talks include:

  • Bringing Up Future Techies – NEOISF – 1/17
  • Making the Most of the Mentoring Relationship – Developer on Fire Remote Conference – 1/22-1/24

Leadership

New to my topics in 2018, I am presenting a talk on servant leadership.  Growing up with a father who showcased servant leadership, as well as reading his cousin’s book on servant leadership, this is something that runs in my family and comes naturally to me.  I have had numerous leadership experiences as well as a few formal roles, and all of my experiences plus the guidance I learned early on come to life in this talk.  When I present on servant leadership, I present it from a tech’s perspective, working in the trenches with my tech support team,  coaching my junior developers, and alongside my fellow tech educators.  I include stories of things I’ve done that would cause people to raise eyebrows and yet realize why it’s okay – and sometimes necessary – to make decisions that may seem absurd but have underlying reasons.

For those who want to see it in action, it’s currently lined up at:

  • Becoming a Servant Leader, Leading from the Trenches – CodeMash – 1/11

Other Topics

There are other topics that I have talks for and am still interested in speaking on.  These topics include:

  • User Experience (UX) for Developers – why it matters and what we as developers can look for and do to make things easier all around
  • Social Media and Personal Branding – how we can take little steps to help stand out in the sea of developers
  • History of Women in Tech – can do a general talk or can tailor this to specific areas of interest (particular tech communities such as a particular language or user group)
  • The Importance of Professional Development and how to find opportunities – affordable ways to grow your skills and the importance of staying relevant in the field
  • Acceptance Test Driven Development / Behavior Driven Development – understanding the concepts and how to apply it in various languages (C#, Java, Ruby, Python, and soon to add JavaScript)
  • Growing and Supporting a Tech Community – geared for those who may not have much of a tech community and how to start it and get it going.  This includes talking about networking and how to promote your community.

Conclusion

If you are interested in any of these or would like to have me present these at a user group or conference, please reach out to me either via email, Twitter, or in the comments here.  I enjoy talking with others, sharing knowledge and learning from others’ stories as well.  Looking forward to meeting others and sharing more knowledge in 2018!

The Fear of Not Appearing Technical

Inspired by the greatest Sarah that I’ve met this year who has introduced me to #SarahConf…. this thread really hits home:

Sarah mentions the fear of being less technical, and it’s something I’ve felt as well.

Topics Early On

When I first started speaking, I focused on technical stuff:

  • Samba with SWAT (1999)
  • Squeak (1999)
  • IronPython on Linux
  • Data Types in SQL Server 2008
  • Silverlight
  • Python

And that was just in my first years speaking.  (And yes, I spoke in 1999 and 2008 was when I got started again.  Notice – they were technical talks.)  Looking at my files, it looks like I had one non-tech talk in that first year – on social media for geeks.

In 2009, that changed a bit as I did my social networking talk at Kalamazoo X, but I felt like things balanced out as I did IronPython on Linux at PyCon.  So a soft skills talk and a serious languages talk (one that I – to this day – look back and wonder how I survived without dying of stage fright and fear since the language team and father of the language were in my audience.  Holy nervousness!)… most of my talks though early on were more leaning on the tech side.

More Recently – Adding UX for Devs, Mentoring, and Leadership!

Adding UX to the mix, I worried that I would appear soft and non-technical.  Even though I care about the tech side, I also know that UX isn’t well-understood among devs.  I think coming from non-technical parents and having been in a customer-facing role, I have more luck understanding users and translating their needs to techies.  So UX is a natural affinity for me.

I’ve recently been speaking on mentoring, and in 2018, my servant leadership talk will be debuting at CodeMash!  While these are departures from technical content as well, these are still more skills that I feel solid in and that I also feel like others could learn a lot from me, my experiences, and my perspective.  This is part of why I talk!

But Wait… I’m Technical, Too!

The main reason why I decided to do talks on data science, R, and Python is to remind people that I’m technical too.  I’m not just a soft skills person, and I am terrified of being painted as weak in tech because I don’t speak as much on the technical side.  I’ve been interested in data all my life – if you hear me talk of mentoring, you hear my story of my internship right out of high school, which shows an early love of data and how much I light up with that guidance.  That curiosity and enthusiasm came out more in the past year and change, which inspired more talks.  So I inevitably add technical talks to my repetoire so that I can remind people – I’m still technical, too!

So yes… this fear of appearing less technical… it’s real.

Earning vs Learning

Once again, Cory House has a blog-inspiring question:

Earlier in my Career

Much earlier in my career, I would take pay cuts to learn technologies.  I thought that was the way to do things.  Once I felt comfortable enough with a technology, I wanted to know enough to apply it but not enough to deep dive and harvest the returns as long as possible.  I knew early on that if I sat still too long, I would feel like I wasn’t learning as much and growing stale while technology evolved around me.  I would rather have taken a pay cut and learn new technologies than harvest returns and stay put.

Current Point in my Career

Having been in technology for about 15 years, knowing what I know, knowing that I have an immense skillset with an aptitude to learn new technologies fairly easily, I find that I am not as quick to take a pay cut for new technologies.  I learn new technologies as side projects so that if I want to work with them professionally, it’s an easier slide and less chance of a pay cut.  Now, if I had to learn a new technology for a gig (which I’ve done A LOT in my career), I am fine with that.  However, my employers and clients pay a certain rate for me, knowing that they’ll get a certain quality out of me.  If I feel like I cannot deliver the quality while learning new technology, I might lower the rate, but it depends on the impact overall.

Constantly Learning

Regardless of the earning part, I am always learning.  I am one who cannot stay put, sitting still, getting idle.  I need to always stay busy – whether it’s work or play.  So for me, if I have down time, I am playing with new technology, learning how things work.   What can I say? I find technology fun, and learning how to learn technologies early on has set me up for a good career path. 🙂

These are my experiences.  Yours may vary.  I’d love to hear your thoughts, so please leave a comment below!