Tuesday, August 08, 2017

To the awesome women engineers and their allies at Google (& elsewhere) ...

To the women engineers, developers, techies and their allies:

I just want to say that as the world watches the repercussions of the memo that was leaked last week, we stand with you in solidarity as women engineers from around the world who are well aware of what you might be going through - because, we know what it's like to be in your shoes every single day.

We know that you work supremely hard, that you are brilliant in all that you do (not just programming/coding) and that you will weather this current upheaval with grace, compassion, deep thought and conviction in your strengths and abilities as engineers and thought leaders.  No one has any doubts in that regard.

Except a small fraction of society that is deluded, terrified, uncomfortable and mentally/emotionally sequestered.

There are many, both women and men, that create challenging environments for all of us in our different roles and responsibilities.  Some are overt, others are not.

So, let's get back to being engineers - debug this, identify some of the root causes, pick one to target, innovate on it and build the next "hack the culture" tool to transform our workplaces for the better.  No one can do it better than us.

Please continue your great work, focus on the technology and your scientific and engineering strengths.  The rest is just a distraction that you can watch on TV, if you have time :).

May the code be with you.

Friday, June 23, 2017

All of a sudden, I'm getting "Diversity"-hiring pings from random companies...

This is a rant post.

I'm pretty tired and am running low on patience and I really don't want to have attitude-challenged companies ping me relentlessly to recruit women engineers in a desperate attempt to increase their "diversity" profiles.  I do not want competent women engineers (who have got to this level despite all sorts of hurdles) to be put into companies that have no track record or clue about how to treat them and handle them.  Unless they can prove they can.

To all the companies (startups in particular) who have suddenly realized that their "bro-culture" is going to get them into serious trouble following the Uber drama and outcome, and are suddenly desperate to portray a "diverse" attitude:
  • Do not ping CodeChix for "sponsorship" if you cannot prove the following:
    • Active (provable) steps you took since Day 1 of your inception (company formation) that you wanted and cared about competent women engineers.
    • If your company is more than 2 years old and you had at least a couple of women engineers in your team, that they got promoted or compensated on par with all other employees commensurate with qualifications and recorded (untampered) contributions.
    • Written proof from your women engineers that they are actually happy to work with the rest of the team and don't have to put up with a bro-culture on a day-to-day basis. 
    • A standardized set of technical interview questions that all candidates are asked regardless of gender.  And verification that it is used consistently and has been for at least one year.
    • A record of why any candidate was rejected or hired - particularly, women engineers.
Otherwise, I suggest you REBOOT your company (see below).  

And, yes, it's HARD.  Starting and running your own company is HARD.  Life is HARD too.  

Deal with it.  

It is MUCH harder for senior women engineers to find a decent company and colleagues to work with.  Trust me.

How to REBOOT your  bro_culture company:
  • Fire anyone who instigated the bro_culture (founder's decision.  If the founder is complicit, no worries.  The REBOOT will go into an infinite loop of it's own accord for this special use case.)
  • Rename & reform company (preferably with a competent, non-token, female co-founder)
  • Follow guidelines above regarding records and measures - should be part of your handbook
  • Hire your first female engineer - make sure her options are commensurate with her being one of the first hires in your company (Guideline: if you IPO, she and the next 3 generations of her family should not have to worry about money.)
  • Have a % of her workload include interviewing (rigorously) every candidate that you hire. 
  • Target 3 women engineers as part of your employee pool within the first year.  Make sure the women have complementary skills so they work well together and like/respect each other.
  • Evaluate yourselves every year via polling of employees
  • Establish and evaluate accountability measures for all engineering management.  Take a look at the NCWIT site for information - particularly here, here and here.
  • Ping me/CodeChix for sponsorship with the data you gathered and I will see what I can do

Sunday, May 14, 2017

OSCON 2017 talk experience

After many years, I gave a talk at OSCON yesterday on my experiences with starting and running CodeChix over the last 8+ years.  Something I tend not to talk about.  My slides are posted at: https://t.co/GrPupvs18m.

Initially, Nithya Ruff had proposed a talk about community building (she's on my board) and I had chatted quite a bit with her about various non-technical aspects of running and building CodeChix and having a full time job at the same time.  So, when she suggested that it would be a good idea to share my experiences, I agreed to be a co-presenter with her on the talk.  For this talk, I took PTO days from work since VMware was not involved in any way.

After several rounds of editing of slides and feedback from Nithya and Kelsey, I decided to talk a little bit about my career background and then focus on CodeChix' impact over the last 8 years or so.

It was great being able to talk to a small audience about OFconnect, CodeChix Technical Curriculums and DevPulseCon.

I had to rush through the latter part of my presentation due to time limitations.  There is so much to cover and even though I tried to be succinct, it takes time to explain the subtle differences between industry vs open source mindsets, the differences in the target audiences where I have one sector of very dedicated, driven women engineers who really care about engineering and another sector that is only interested in a job, not really interested in being particularly driven - just a secondary job to pay the bills while the husband does the primary job.  Tailoring programs to meet both audiences is hard especially since my natural instinct gravitates towards the former.  But, I have to meet the needs of both audiences despite my personal biases.

Not to mention the little side story about the behemoth company which touts undying support of open source on their website and wouldn't let 2 of their women engineers contribute to OFconnect.

I was glad I got to put one image slide of a glacier into the presentation after climbing an offshoot of Vatnaj√∂kull in Skaftafell national park in Iceland.   The landscape navigation for our careers as women engineers is very similar to navigating/climbing glaciers, I think.

I mentioned to the audience about the three main categories of hurdles for open source contributions by women engineers - Technical (not really an issue),  Logistical (just needs more practice) and Cultural (biggest hurdle and gnarly).  Also, about building a "trusted net" to rely on for support/deflection and how hard that is.  And why.

Overall, I think the audience was receptive - except for the one guy whose eyes kept closing every few minutes.  Our talk was right before lunch - his blood sugar might have plummeted.

Hopefully, I will get to present the rest of the material that I have (part of draft 1) at a developer-centric conference someday soon.

Especially the part where I debunk some of the touted "solutions" and "recommendations" by clueless institutions in ivory towers who believe more in dictating untested bullshit and extracting lots of money on that premise.  Unconscious bias training my foot - how about CONSCIOUS bias training?  No wonder the proverbial needle hasn't moved in the positive direction over the last several years.

Time for companies and boards to do some root-cause analysis and have the hutzpah to be able to handle the hard work instead of focusing on the easy, low hanging fruit and patting themselves (and each other) on the back.

Peace.  Nose-to-the-grindstone from next week for several months towards the next release of our product.

May the code be with you.

Oh yeah - had some awesome ramen at Daruma Ramen in Austin about two blocks from the convention center.  Try it if you're in the vicinity.  Miso (with chicken), fried pork dumplings and green tea.  And they had a pretty mean purple sweet potato ice cream which I couldn't eat much of because of my nasty cold (thanks to my long flight back from Rekjavik right before the conference).

Saturday, January 21, 2017

Open source legal implications, licenses and their impact...

When you join a tech company, you usually end up signing some sort of employment agreement contract which, if you read carefully (you MUST read this thoroughly), probably states all sorts of restrictions on what you can or cannot do/own and the rights of the hiring company to own your work, whether it is during working hours or in your spare time including ideas you might have in the shower or anywhere else.  In many cases, this extends to open source contributions that you might make which might be unrelated to anything you do at work.

As we grapple with a rapidly changing software and hardware industry where the open source juggernaut slowly, but steadily, steam rolls over proprietary software, we are faced with difficult and contentious issues of what "belongs" to the company (a proprietary, closed mindset) and what "belongs" to the employee that they can contribute towards during their spare time.  Especially for contributions which are unrelated to the employee's day job.

So, it's imperative a developer/contributor understands the variety of open source licenses that exist, what they imply and how one should use them.

The choice of the open source license for a new project can directly or indirectly affect how it grows, how many contributors and maintainers it has, how it is used, whether people can make money using it commercially or not and, eventually, whether the project is sustainable.

Here are a few things to think about regarding licenses as you enter the world of open source:

  1. Talk to the open source office at your company and ask them for clear guidelines on what is your intellectual property and what is the company's.  If you don't have an open source office, locate the legal department and ask someone in that team.  If they don't know, talk to the legal department about your concerns and see if you can get some sort of guidance from them.
  2. Read and re-read your employment agreement to understand what the implications are for your ideas and contributions to open source.  Does the company own any contribution you make regardless of whether it's related to work or not?  Is it restricted to software, hardware, both?  What about blogs, presentations at external conferences where you are not sponsored by your company, published articles in journals or technical magazines?
  3. Read, re-read and completely understand what the different types of open source licenses are - start with this site https://opensource.org/licenses/category.  Also, look at https://creativecommons.org/licenses/.
  4. If you create open source software or hardware, ensure that you are clearly stating what license is used for contributions to that project.  If you're unsure about what license to use, ask around, go to open source-centric meetups and talk to speakers to increase your knowledge and get help online.  Also, see https://www.gnu.org/licenses/license-recommendations.html.
  5. If you contribute to existing open source software or hardware, ensure that you understand what license is used for your contributions and if you are allowed to share it, own it and use it as you and others intend.
Your choice of license (whether you started the project or are contributing to an existing one) can have a significant impact on the culture of the project.  MIT, Apache and BSD licenses are extremely open and allow contributors to share and contribute freely.  Projects that use these licenses might not, however, have stringent rules and oversight to vet the quality of the contributions since anyone can contribute - whether they have an appropriate background or not.  This could also lead to many new contributors asking for help and maintainers being overwhelmed (and, therefore, quitting).  If you go the GPL route, the various versions have varying implications and your contributor/maintainer profile and personality might be quite different. What if it's more litigious - is this what you want for your project?  Do you want your project to be commercially distributable with acknowledgement to the origins and contributions back to the original project?  

I tend to use the MIT or BSD licenses for projects - CodeChix Technical Curriculums contain a series of technical curriculums spanning mobile, security, NLP and Big Data under the MIT license.  We used the Apache license for the OFconnect SDN controller project.

But, that may not be the case all the time, depending on what makes sense and how I would want to structure the impact of the project and what I call the "target market" - as in what types of developers do I want to attract to the project.  I'm still thinking about this a fair bit and pondering pros/cons and what would be most beneficial for my "target market" - women engineers in industry who typically have very little "free" time and energy.

Monday, January 16, 2017

On open source - scratching the surface

At CodeChix, we have always been strong proponents of open source in all it's forms - software, hardware, design, photography etc. It's a fundamental requirement for all programs that we run (tech talks, hands-on workshops and hacking sessions) and our conference, DevPulseCon only accepts talks and workshops targeting open source projects.

Over the years, it's been an eye-opening experience for me that there are so many companies that tout open source support on their websites and marketing verbiage and, yet, when you look closely or instigate an open source project that might "compete" with a proprietary product at said company, all "open source goodwill" goes out of the window in a flash.

This happened to me when I was building the CodeChix team to work on the Open Networking Foundation's OpenFlow Controller international competition consisting of 4 fantastic women engineers from 3 different companies. One of the companies, a behemoth of networking software and hardware which proclaimed huge support for open source on their website etc., denied two of their women engineers (CodeChix members) on the team from working on this competition project. Their argument was it was a "competing" effort to their proprietary controllers and they would not allow these two women engineers to participate in this effort that was being run by CodeChix. Naturally, I pointed out the discrepancy between what they were touting on their website and what they were telling me. Which resulted in complete silence and I suspect my queries were relegated to the proverbial bitbucket.

So, I pinged the ONF Executive Director, Dan Pitt, about it and mentioned this dilemma - I couldn't build a team without these two engineers - they would be doing all the work in their spare time (nights and weekends) just like the rest of the team and I really needed them in order to meet all the submission criteria for the competition.

After several email threads with the ONF, myself and the legal department at the offending networking company, it was finally agreed that as long as CodeChix would open source all the work (of course, that was the whole point after all from my perspective), said networking company would be "OK" with the two women engineers working on this project. The whole process took about a month and half to get resolved. With a lot of angst and stress and juggling on my part. And the team took a big hit since we couldn't really be fully productive until both these team members had the green light to join and start their work.

The moral of the story being, never give up. And call out the industry when they try to ignore their own policies. I'm not saying this will always work - it helps to have a heavyweight organization to back your efforts. But open source is the future - for the women engineers who are truly dedicated, brilliant, persistent and resilient. It's not for everyone, I think. It requires a very different mindset and attitude from what traditional proprietary product development entails as far as processes, accountability, collaboration and effectiveness. In some cases, it's much more difficult to make a mark in open source and get recognition for it. It's not like you have a manager/boss who's watching you or assigning you tasks. You are your own boss and that can be a good thing or a burden - depends on your personality and motivation.

But, if it is in your DNA to run things, open source is a potential path to success as you choose to define it - whether it's for contributing to solving hard problems, improving the world or teaching/learning.

Saturday, November 07, 2015

Coder[xx] - a resounding splash in a rather still and brackish pond...

It's been about two weeks since the inaugural CodeChix hyper-technical conference (Coder[xx]).  And I'm still recovering from it.  To all the nay-sayers (both companies and individuals) who thought this is something that is not needed given the plethora of existing (mostly male) conferences - take a look, learn and rethink.  The data is very clear that this is an absolute need and so is the enthusiasm and response.

What an absolute pleasure to see such a huge demand from women engineers in industry (and a few students from SoCal and Sonoma) all over the bay area as well as some global travelers who happened to be in the bay area and joined us.   We were sold out and pulled off a conference full of technical content spanning programming languages, tools, technologies, maker-ism and a panel session on how to get ahead which was packed and electric.  All in 6 weeks.  With no prior experience in this sort of thing.  With almost no funding.

I set the tone of the conference in the beginning by welcoming everyone to a safe space, one that is open to women and all who identify as women (of which there were several attendees) and the supportive men who were there to help us succeed and to share their knowledge with us.  And that we were all there to learn, share and learn about each other and what we work on.

I also made myself abundantly clear on my take on recruiting at the conference - not allowed in any way, shape or form.  Including a promise of immediate, impolite and very firm ousting should I see this happen or hear of it happening.

It was, I thought, exactly the right size at almost a 100 headcount for what I had envisioned and made it easier for everyone to have a chance to actually meet/chat with a number of new people and establish connections.

Mary Lou Jepsen's keynote was absolutely fantastic and everyone who was able to find standing space (yes, we only had one large room so people had to stand) was inspired and she was mobbed for several hours afterwards answering questions and responding to a crowd of eager women surrounding her until I rescued her :).

The panel discussion on growing in your career took an absolutely candid look at the state of things as they stand from different perspectives (industry, some academia and freelancing) and hearing from an interested and engaged audience that started participating within the first 5 minutes or so.
No recording or social media allowed - this was a safe space panel and I wanted to have everyone speak freely with no chance of retaliation of any sort.  At least, that was my hope.

I couldn't have done it without the fantastic volunteers - both the core, dedicated team who helped with getting the conference organized and presented in 6 weeks to the day volunteers who stepped up to handle any minor hiccups and were there when we needed them !

Our surveys show an overwhelmingly positive response to our hyper-technical conference and we have already been bombarded with questions about when the next one will be.

Some of the survey comments:

" I think the conference was amazing! Hats off to the panel discussion!"

"i am so glad i decided to go to this event, although i didn't get to meet anyone new (introvert thing), i walked out feeling so humbled, and yet so inspired! both the codechix team and all the speakers are just amazing! a big thank you! i am looking forward to coder[xx] 2016 already!"

"Good talks and qualified, dedicated and passionate speakers, strong keynote Candid discussions, open career advice Good turnout for Sunday and possibilities of networking within engineers Helpful and dedicated organizers and volunteers Professional demeanor of speakers ,attendees , organizers and volunteers Overall very smoothly run conference- no major confusion or hoopla"

At present, we're trying to get all the videos wrapped up and posted on our CodeChix YouTube channel...

Stay tuned for 2016 events and the next hyper-technical conference from CodeChix - we've set the trailhead and cleared some of the route for others to follow...

For the first time running a conference (the first of it's kind),  the feedback is clear - women engineers need this, want this, will flock to it and this could be the catalyst for much-needed change.

The question remains - will the companies, who are mired in their introverted, ethnocentric outlook and bottom-lines, look up from their myopic viewpoints and see this?  And, will they support it?

We'll see how this plays out over time...

Monday, October 19, 2015

On Code Reviews - Part 1 of 3

I've been pondering writing about this topic for a while and never really had the time to corral my thoughts and write it up.

Until I flew to GHC and had time at the airport and on the plane :).

This is not an exhaustive coverage of code reviews and is meant as a basic understanding and guideline for engineers.

It amazes me how many engineers (both young and old) still don't know much about code reviews and I have encountered some who have been working for several decades and have never had to do a code review (begs the question what sort of architecture/design/implementation have they produced?).

Some, usually the latter category, are vehemently opposed to having their code "poked" at by others and believe that they are entitled to writing/designing whatever they choose regardless of what others might think.  Generally, one tends to avoid working with such engineers, but, they do seem to pop up rather alarmingly frequently.

So, in short, code reviews are essential and all good software (and hardware interface engineers, if applicable) perform them religiously.

NOTE: A basic requirement for code reviews is to "Check your ego at the door".  Your work is going to be reviewed/dissected and comments will arise that will not be easy to digest.  This is a good thing.
A code review is not about you, it's about the code/product quality.  And you won't be the only one  - everyone has to go through it.  So, deal with it graciously, be thankful that you have good reviewers and that you are, eventually, going to become a better engineer because of it.

What is a code review?

A code review is quite literally a reading/understanding and critical thinking process that is applied to programs/code that either needs to be shipped as part of a product or used internally by developers to build products.   Written and/or oral feedback is given to the author on whatever is being reviewed so that s/he can incorporate the feedback and improve things before checking in the code into mainline or a branch.

By no means is this an exact method for eliminating all errors in a given piece of software, but, it is reasonably effective (if used properly) at identifying errors, potential errors and, eventually, providing quantitative and qualitative feedback to the author about her/his technical approach and implementation.

The review might also include architecture/design of the component that is being reviewed as a background for the reviewers, particularly if the code is a critical path in the product and/or interfaces with other critical paths in the product.

There are a whole host of other definitions for a code review, but, this is the one that makes most sense to me.

Why do we need code reviews?

Code reviews are and have been one of the few ways of mitigating programming and design risk associated with a product - early in the development cycle.  Usually, it is a human process to understand and evaluate architecture, design and programming paradigms as well as algorithms in order to visually and conceptually understand how a given piece of a product works and is implemented.

In the end, code reviews help a developer/engineer become a better developer/engineer and, also, establishes technical standards within a group of developers/engineers, resulting in a better product in the end.  It also provides a way for a team to understand and evaluate code that they might not otherwise know, should a bug in that piece of software appear in the field, and the original author may not be available to triage and fix it.

Apart from that, code reviews help developers identify integration issues well before the code is checked in and this alleviates the burden on QA/QE and, eventually, results in a better product in the end (again).  The entire goal is to create a more robust, well-architected and well-designed product that has few bugs in the field and happier customers.

Leading to more money so you can afford that ridiculous mortgage and send your kids to a decent school...  (I see this among all my married w/ kids friends).

Coming next...... Types of code reviews and pointers on how to conduct them effectively