geekchick77: (Default)
Remember, you are smart and you already know a lot in life. Having code that doesn't work is a frequent but temporary condition of being a programmer. You have what it takes to figure things out.
It is tough to focus when you are stressed out. It could be the challenge of learning to program, other life stresses, or a combination. When we are stressed, blood shifts out of our frontal cortex (the part of the brain needed for higher reasoning) and into more basic functions.

It takes some skill and practice to get that blood back into our frontal cortex.
I recommend that as soon as you start to get frustrated, get up, go away from the computer, take some deep breaths, and do some jumping jacks or walk around the block. Walking is especially good because the coordination of your left arm with your right leg and vice versa helps to balance the sides of your brain.
After a 5min or so break, come back and carefully read the error message again. Most tools these days give detailed error messages. You can develop the skill to understand those messages, even if they look confusing to begin with.
It also helps to talk through the problem, even if the person you are talking to does not know about programming. It even helps to describe the problem to a pet or a stuffed animal. The very act of talking out loud about what is happening activates different parts of your brain than just thinking about it.
Programming is a skill that is learned through practice. It is not an inborn ability that some have and others do not. Like any skill, some people will advance more quickly and some people will eventually reach a higher level than others, but nearly everyone can become proficient at a basic level. If you keep practicing, you will definitely get better at programming, and someday you may become great. If you look at others and are awed by their skill, ask them about how they learned. Chances are, they have practiced a lot.
geekchick77: (Default)
Wednesday, November 30, I talked about Python Profiling for PyLadies Toronto. I touched on a number of options, with most of the time exploring  cProfile.

My slides are available here:
Slide source:
Profiling examples:

I tend to go with the flow when speaking so the presenter notes may not exactly reflect what I actually said in my talk. If you have questions, let me know!

geekchick77: (Default)
You know that moment where you had working code, and now it has stopped working, and you aren't quite sure what you've changed? You made a lot of good changes since your last commit, and you don't want to throw those away, but you need to find the erroneous change. This is where PyCharm's local history functionality really shines. You can right click (or ctrl-click) on a file or a workspace, and see a timeline of all changes, with a visual diff of each change. This can help you quickly hunt down errors, without throwing away your good changes. It's particularly helpful if you're experimented with many different variations for a specific block of code.

Example screenshot
geekchick77: (Default)
I am working on a large app (hundreds of migrations) and it is becoming unwieldy. There are options for not running migrations when unit testing, but it'd be nice not to need to use them. Plus some of the old migrations reference old code I'd like to be able to delete.

I tried running squashmigrations, but the resulting migration file had errors when I tried to run it on a clean DB.

So, I decided to do the more drastic method of deleting and recreating migrations.

  1. ALL databases must be at the same migration level before you begin.
  2. If you have a custom user model, do NOT delete the migration that creates it. You can safely delete subsequent migrations.
  3. If you have data migrations, you need to maintain those.

Procedure for app that contains the custom user (e.g. if app name is "users"):
  1. Ensure all databases (local, staging, production, etc.) are at the same migration level.
  2. Create backups of all your databases.
  3. Save the code for any data migrations in a temporary file.
  4. Delete migration files from 0002 upward (assuming 0001 created the custom user) and commit to git
  5. delete from django_migrations where app='users' and name NOT LIKE '0001%';
  6. python makemigrations users
  7. Recreate any data migrations.
  8. Verify that migrations run successfully on a clean database.
  9. python migrate users --fake # Run locally
  10. Commit new migrations.
  11. Push changes to all other systems and on each run: python migrate users --fake

Procedure for apps in general (e.g. "myapp"):
  1. Ensure all databases (local, staging, production, etc.) are at the same migration level.
  2. Create backups of all your databases.
  3. Save the code for any data migrations in a temporary file.
  4. Delete migration files for myapp and commit to git.
  5. delete from django_migrations where app='myapp';
  6. python makemigrations myapp
  7. Recreate any data migrations.
  8. Verify that migrations run successfully on a clean database
  9. python migrate myapp --fake # Run locally
  10. Commit new migrations.
  11. Push changes to all other systems and on each run: python migrate myapp --fake
geekchick77: (Default)
I had just started my first programming class. It was 1997 and I was in first year engineering. We were being taught Turbo Pascal. I didn't have my own computer -- I had no money for anything beyond the bare necessities of life in those days. My boyfriend did have a computer, and he went away for a long weekend, leaving me with his computer. When he got back, I showed him the mastermind game I had made while he was away. It had only rudimentary graphics, and all it did was make a code and mark your guesses, but it worked!

"How did you figure out how to do that?"

"I read the help," I answered.

"You learned to program by READING THE HELP??"

Borland had really great help docs :)

Also, I am struck (yet again) by how much I was helped by those who had a more secure position in life than I did. Him sharing his computer with me was a big help in me eventually going into programming.

geekchick77: (Default)
I believe that as educators, we have a profound duty to do the best job possible for all those who might learn from us. We are creating the world through our actions. We influence our learners by our example, and we can both give marginalized people space and help privileged people understand more about experiences outside their own.

When selecting learning materials, and when writing your own, please consider the impact of your choice of examples. Of course you want your examples to be clear and illustrative, but there is more than that. Try to select examples from a variety of human activities. Pick relatively un-gendered activities wherever possible. If you do pick gendered activities, I recommend using the unexpected gender first for the domain at hand. If it's a math book, make your first example cooking. If it's a knitting book, make your first example hockey gear. There is no particular need to gender either cooking or hockey, but most people upon hearing "cooking" will think of a woman before a man, and vice versa when they hear "hockey".

I also recommend examples that are applicable to the largest percentage of the population possible. If you are describing an experience, try to pick one most people can relate to. If you are teaching a class in North America, there is a fairly good chance that most people know something about driving cars, but there is an even better chance that your students know something about finding objects in a cupboard. If you are making online learning materials, cupboards may not be a universal experience. Try not to make assumptions about common experiences, especially emotionally fraught ones like immigration. First Nations people never immigrated to Canada, many African Americans are descended from people brought to No as slaves, etc.

The language used to describe examples also matters. If you are describing people, try to use neutral terms that are not based on stereotypes of race or gender or economic class. Try not to use objectifying language, like describing the sexual attractiveness of a woman. I think it's generally better to use animals or plants for categorization examples, but if you must use humans, use relatively neutral characteristics like height or shoe size.

Remember, your goal is maximal learning for as many students as possible. :)
geekchick77: (Default)
I recently participated in the Codementor Featured Stars program. I was excited to hear about the program, which gives non-technical founders an opportunity to familiarize themselves with the technology on which their product runs. I was delighted to be mentoring Amanda, as one of my big goals in life is to help bridge the gap for underrepresented groups in tech. Teaching technology to a woman doing a non-technical role in a startup is one of my dream gigs, and the reality did not disappoint!

Every time I start with someone who is totally new to programming, I am reminded of how much there is to learn to make even a simple "hello world" program, let alone a web application. At the beginning, it's all a bunch of disconnected bits of knowledge. It's easier for the learner if they are willing to press ahead into the unknown and experiment, which Amanda did wholeheartedly. She was not afraid to go over her code with me and explain her thinking and accept corrections. This make makes the learning process much smoother, and far more pleasant for me.

I was very impressed with Amanda's diligence as she applied herself to climbing the steep learning curve. She faced the challenge with courage and intelligence, and her improvement was very noticeable session to session. With my guidance, she was able to achieve a functioning Django app with some front-end styling by the end of the one-month program, an impressive feat for a newcomer.

Amanda now has familiarity with basic programming concepts, which will enable her to better communicate with the developers in her company. One of her goals is to be able to make commits to the company's codebase. By the end of the month she was gaining enough familiarity with the tools and frameworks that she could see how she might start making small fixes. She is also setting a good example in her company and in her family, a value she and I share.
Mentoring Amanda was a joy, and we look forward to working together more in future. The Featured Stars program is a unique opportunity which I highly recommend it to both mentors and mentees.
geekchick77: (Default)
Tuesday, February 23, I did a talk for ExploreTech Toronto entitled "eggtimer: a labor of love" about the creation of my open source menstrual tracker app. 

My slides are available here:
Slide source:

Eggtimer web application source code:
Eggtimer mobile application source code:
Please note that eggtimer is one of my older Django apps, and doesn't reflect all of my current best practices for structuring code.

I tend to go with the flow when speaking so the presenter notes may not exactly reflect what I actually said in my talk. If you have questions, let me know!

geekchick77: (Default)
Wednesday, February 17, I did a talk for ExploreTech Toronto entitled "Mentoring for a Better World" about my experiences being a mentor on There may be a video soon, if it turned out well.

My slides are available here:
Slide source:

Video is now up!

I wrote an earlier blog post about becoming a codementor.

I tend to go with the flow when speaking and my presenter notes are terse, so if you have any questions, please feel free to ask.


Oct. 1st, 2015 09:09 am
geekchick77: (Default)
Early this year, I created a profile on I wasn't sure if I would actually get paid, but I figured I had nothing to lose! I had plenty of time, as I was searching for a job, and I like helping people.

I was a bit nervous at first -- "What if I can't figure it out?" -- so I only offered to help with requests well within my expertise. It can be a challenge to get started on a reputation-based site like codementor, and I wasn't getting many responses yet, so I started altering my strategy. What I suggest, based on my experience:
  1. Select the "15 minutes free" option on your profile -- it really helps get new clients.
  2. Start out with a relatively low hourly rate and increase it slowly as you get more clients.
  3. Connect your github, linkedin, stackoverflow, etc. to your codementor profile. Try to answer at least a few questions on stackoverflow, and have a few interesting projects on github. At this point I have many starter and sample apps, most based off session work.
  4. Be willing to chat with people for a few minutes to get a sense of their issue, and only start a paid session if you think you can help. If the issue is very simple, just give the person the answer for free. They are more likely to give you a good review and to come back to you later, and they might even tip you!
  5. Stay logged into the site, and watch incoming requests. Often, the quickest person to say "I can help" gets the session.
  6. When you offer to help, give some of your advice or insight into the problem -- this lets people know you understand and have something to offer. If that is enough for them to solve the issue themselves, great! Again, they are more likely to come back to you in future and to write a good review, plus they might even tip!
  7. It's often helpful to ask more questions, either on their request or in chat.
  8. Sometimes people's requests do not give a good idea of what they actually need. If you begin the session and realize it's not something you can help with, I recommend letting them know immediately, apologize for the misunderstanding, and let them seek someone more qualified.
  9. Offer to help even if you don't know the technologies in question. Be totally up front about your level of expertise, and let them know you can take a look. So often all that's required is a second set of eyes, and there might not be a mentor online with experience in those exact technologies.
  10. Sometimes you won't know the answer or it will take longer than you expected, and that is ok. Check in with the client about timing and whether they want to continue. Interestingly, some of my best reviews are from session where I didn't know the answer off the top of my head. Clients really appreciate watching me go through debugging and other problem solving processes.
  11. Go slower than you think you should, unless the client really wants you to rush. Take the time to explain to people what you are doing and why.
  12. Decide how long you are willing to wait if client doesn't show up for a scheduled session. I generally wait 10-15 minutes if there are other people asking for help, longer if I have nothing else pressing.
  13. Take on long-term mentoring if you can. The rate is less but it's a great opportunity to hone your skills and get some reviews.
It's now been over 6 months, and often people message me with questions before I can even offer to help. I've had days when I was mentoring non-stop from dawn until dusk! I'm very happy to finally be doing work that is useful, appreciated, in line with my ethics and social goals, fun, and well paid. :D
geekchick77: (Default)
I work on a lot of different coding projects, nearly all Python and often but not always Django. I am a huge fan of virtualenvwrapper, but I always find myself editing the activate script to export project-specific variables. It's not hard to do, but it's tedious and definitely repetitive. I also notice there are certain predictable ways I break the build:
  • Forgetting to add a package to requirements
  • Forgetting to run the linter
  • (rarely, but it does happen) Forgetting to run unit tests
I've been on an automation kick lately, and I decided to see what I could do about these issues.

I make use of piplint to check requirements. Note that the pypi version doesn't work on Python 3, but I have an updated fork installable with:


pip install -e git://

As it turns out, virtualenvwrapper is highly customizable, and all I had to do was edit mkvirtualenv in WORKON_HOME to have it modify my activate scripts. While I was in there, I decided to make a skeleton pre-commit hook for the project:

# This hook is run after a new virtualenv is created and before it is activated.

# Automatically set django settings for the virtualenv
echo "export DJANGO_SETTINGS_MODULE=$1.settings.development" >> "$1/bin/activate"

# Create a pre-commit hook script that can be copied over as desired
echo "#!/bin/sh
set -e
. $WORKON_HOME/$1/bin/activate
piplint -x requirements/*
jshint $1/static/js
python test $1
" >> "$1/bin/pre-commit"

Now every new virtualenv comes with Django settings prepopulated. If it's not a Django project, that unused environment variable isn't going to hurt anything.

You can add more environment variables later by editing ~/.virtualenvs/<VIRTUAL_ENV_NAME>/bin/activate and adding "export <ENV_VAR>=<VALUE>" entries to the end of the file.

I don't automatically move that pre-commit hook because there is no guarantee I have anywhere to put it. Sometimes I make the virtualenv before I initialized a git repo. However, the hard work has been done so once I make a project, I can simply copy over the hook. Note that the git hook must be made executable or it will be ignored.

geekchick77: (Default)
 Why is it ok to have women’s only events when so many men’s only groups have been forced to include women?
(Note: I am going to speak about women here, but these arguments apply to any disadvantaged group.)

Edit: When I say "women's-only space" I mean space for people who self-identify as women. For some of the groups I refer to, it makes sense to include anyone who identifies as anything other than cis-gendered male. It is not common, but there can be good reasons to have more restricted groups, e.g. in a prostate cancer support group may have only prostate cancer survivors or a menstrual discussion group may include only those who menstruate. Those groups may wish to open themselves up to a broader range of participants, and I prefer that to be the group's choice.
For me, it boils down to the purpose of the group, and how much power the group holds. For any group that holds significant social or economic power, particularly a decision-making body, that group should absolutely represent the larger population they serve. Note that power isn’t always as obvious as a national government holding significant power over citizens. Consider a group like boy scouts, which doesn’t hold that much direct power, but forms bonds that last a lifetime, such that a former boy scout with power is more likely to share that power with other former boy scouts. Also consider prestigious golf clubs, which are ostensibly about sport but also provide a location to broker business and political deals. If women are excluded from these organizations, their careers will suffer as a result.

In general, the women's only events I see have at least one of the following intentions: 1) create a safe space for women 2) give women a chance to bond and talk about issues primarily to women, or 3) help women build skills and bridge the gap into male-dominated areas.
1) Safe Space
If you don’t understand why women might feel safer in a space without men present, do a little research on the internet. In general, groups of men and women interact more like groups of all men than like groups of all women. The men tend to take more of the talking time. Frequently, there is at least one man who condescends to, leers at, or hits on at least some of the women. An example of providing a safe space is a women’s-only dance, where women are free from men leering at them, hitting on them, and groping them.
2) Bonding
There is huge value in women getting together as a group to talk about their experiences. There are some issues women are hesitant to bring up in the presence of men, and if those issues are brought up, the conversation is often dominated by men’s questions and critiques. Also, the challenges of living in a patriarchy tend to separate women from one another, leaving them to fight amongst themselves for scraps of power rather than push for more equal distribution of power overall. By bonding together as a group, women can strengthen their connections to each other and themselves. An example would be a women’s support group.
3) Bridging the Gap
Women’s legal access to the institutions of power has been granted primarily within the last 100 years, and their effective access is still unequal. Therefore, there is great value in having women’s only groups that help women build up the skills and confidence required to go into male-dominated areas. I am most familiar with women’s-only coding events, which are a great way for women to learn to code without the usual pressure of being a token in a room of men. Once women gain some comfort in these groups, they often go on to join the tech community as a whole.

There is definitely great need for men's-only groups aimed at creating a safe space in which men can open up and support each other. Men as much as women need a space in which to talk about issues primarily related to their gender, and that can be hard to do with other genders present. I am happy that I am starting to see more such groups popping up.
If you are wondering why a women’s-only gym (for example) isn’t problematic in the same way a men’s-only gym is — if we get to the point where most upper management and government positions are held by women, then it will be problematic. For now, having a women’s-only gym functions primarily as a safe space for women, and if anything keeps women out of the circles of power.
If you are wondering about whether lesbians also objectify other women — in my experience, not that much. There is fairly high political awareness amongst lesbians as a group. Most women are fairly aware of how their attentions are received, and rarely push another woman like a man might. Also, there is less of a perceived power differential, so even if a woman is hitting aggressively on another woman, it might be annoying but it’s less intimidating.
If you are concerned that women’s-only groups reinforce gender segregation and will prevent men and women from learning to get along with one another — most of our society is now integrated and there are MANY opportunities to learn to get along with diverse groups. If anything, having a little break is very helpful as it gives women a chance to recharge and then go back into the world and engage with men.
If you think there should be groups to help men get into professions currently dominated by women — I agree! Go start one!
geekchick77: (Default)
For one of my personal projects, I want to have an editable, syntax-highlighted panel embedded in the page. I was pondering just how I might implement this, when a friend pointed me at ACE, a truly wonderful online code editor. The icing on the cake is that there is a django-ace project, so I didn't even have to put any work into integrating it with my project! What a fantastic job the authors have done!

One of the wonderful features is the wide variety of themes available. I couldn't find an online listing of how these look, so I decided to screenshot them (with some Python code entered).

Here is the list of theme names:
geekchick77: (Default)
So, this weekend has been frustrating. On Friday, I got Django unit tests for my work codebase running in PyCharm. I was very pleased, because visual debugging and in-editor code coverage are fantastic!

So, I get home, update my code, and try to run unit tests... and an import fails with:
AttributeError: 'module' object has no attribute 'Products'
Not a regular import, but a call to __import__() buried deep in the test runner code.

The gory details... )

* OS X is sort-of case-insensitive
* The results of os.getcwd() and the contents of sys.modules are unpredictable with respect to capitalization
* The nose test runner contains some case-sensitive code
geekchick77: (Default)
I took my sweet time joining the smartphone world. I simply couldn't see paying $500 for a pocket computer, and another $100/month to keep it connected. Finally, just over a year ago, a friend informed me it was possible to have a reasonably priced data plan in the U.S., with AT&T, and I decided to give it a try while I was living there.

My first phone was an older Android phone, a second-hand Samsung AT&T Captivate. Yes, it was handy having maps and other info with me on the go, particularly since I'm usually on a bike, but the phone experience was not great. I had heard people talk about how smartphones required a lot of charging, so I thought that it was normal that mine couldn't get through a workday on standby without me charging it. Now, I rather suspect it was a defective battery. Physically, the phone felt a bit clunky, and the data connection was unreliable.

I had some iPhone envy, and when I moved back to Canada, my job supplied me with an iPhone on the Bell network. I don't like Bell overall, but I must say their network was excellent. As expected, the iPhone battery life was excellent. Things looked prettier and of course there are plenty of apps (which, for the most part, I don't use, but I do miss things like RocketMan for TTC). It was back and forth for a while, but in the end I realized I preferred my Android phone.

The first big disappointment was not having gchat. I know that there are theoretically ways to get it to work, but I was never successful. I really missed having that. Also, while setting up my gmail and contacts worked fine, I never was able to search historical emails on the iPhone. If it wasn't in my current inbox, it was gone.

As time went on, I came to really miss the hardware buttons and keyboard layouts on the Android phone. Overall, I think the current Android experience is a lot smoother. You can click a link in an email, take a look, and press the back button to be back in your email. Not having a comma on the main keyboard in iOS drives me insane! It's like they are trying to encourage less literate writing. I also found the keyboards for entering email addresses and URLs to be nicer in Android. There might be something like Swype for iOS, I'm not actually sure. In any case, Swype is pretty cool.

As frustrating as navigation could sometimes be on the Android, it seemed that on iOS it was even worse. Dropping Google maps just added insult to injury. Yes, I know, there is an app now, but it seems to have some issues. I'm sure it'll get there in time, but it was a poor choice to drop it as the default.

The final straw was dropping my iPhone ONCE and having the screen shatter, necessitating an expensive repair. I dropped my Android phone many times, and while it had a few scratches and I knocked the battery out more than once, the screen was intact and it continued to function perfectly. It's not as if the iPhone is a far more lovely tactile and visual experience; if anything, I would say some of the new Android phones are superior. They are thinner, have a bigger screen, and feel sleeker.

One big minus against Android right now is the current impossibility of getting a new Nexus phone. I really wanted one, as one of the huge hassles before was unlocking the phone and upgrading the OS. I can't even really believe that in this day and age, people are expected to get binaries from file sharing sites and run them! (Because I don't really trust these things, I greatly limit the information and actions I take on my phone.) How does anyone who is not highly technical deal with an Android phone? Do they simply never upgrade the OS?

An entertaining aside: while certain simple maintenance tasks are quite difficult and complex, managing your Android OS is far easier. The task manager gives you detailed information on process resource usage. There are multiple apps to monitor battery usage. Installing non-market apps is as simple as a checkbox. If you've ever deployed an app for iOS, you understand why that's so lovely after the agony of provisioning profiles.


iPhone pros:
- battery life
- OS upgrades
- apps
- availability of hardware

Android pros:
- durability
- screen size
- hardware buttons
- better keyboard layouts
- navigation
- gchat
- perfect gmail integration
- easier testing of development apps
geekchick77: (Default)
... But didn't know to ask

Many intelligent, knowledgeable, and well-intentioned people tried very hard to help me make the switch to git, and I am grateful for their efforts. They helped a lot, even if I wasn't always very appreciative at the time! That there was a gap between how they understand/explain things, and what I needed to know, is just one of those things that happens in life.

This post is primarily aimed at those, like me, who had many years of experience in other version control systems and are struggling with the transition to git. It is experiential rather than strictly practical, and goes over my background as well as my process of learning git. It is an opinion piece and I expect some will disagree rather vehemently with my point of view. It is possible that some of my explanations of how git works are not entirely technically correct, as I am still far from an expert on the subject. If you see something, let me know and I will correct it.

Before git, I had used SVN, CVS, MKS, and a little RCS. I had years of using both CVS and SVN, and knew how to use them well and without much pain (though if you'd asked me, I wouldn't have said I understood either one). The switch from CVS to SVN wasn't completely smooth, but it didn't take too long. The main thing I remember getting caught by was SVN remembering files when you moved them, something I wasn't used to having to worry about.

I will admit, I was a little annoyed with git before I ever used it. I don't enjoy interacting with zealots of any stripe. I want to hear "hey, this thing is great, here are some of the advantages," not "if you aren't using this you're doing it wrong." I tried to read so many pages about making the transition that threw in some comment like "this might be hard if SVN has broken your brain." This is alienating and just not helpful. I think git champions would get much happier (and more!) converts if they focused on conveying the necessary knowledge with less superciliousness.

Another important data point is that I was using SVN within Eclipse, which took almost all the pain out of branching and merging. Occasionally there would be a particularly bad situation and I'd have to get into three-way merges on the command line, but it was rare. For my normal, day-to-day case, I didn't have to put much thought or effort into version control.

I knew that distributed version control was the new way, and I was going to have to switch, and I understand there are some very good reasons to use git or hg. I was, however, entirely comfortable with the situation I had, and in no hurry. And then, my workplace announced the decision had been made, we were switching to DVCS and it was going to be git, not hg.

The Egit team has obviously been working very hard, and the plugin is much better now than it was when I first tried it. However, it still doesn't feel like using other version control in Eclipse (if there is a way to have the nice editable diff viewer, I haven't found it). I would much prefer to stay in my IDE, but I looked at everything available for OS X at the time, including various GUI tools (gitx, gity, etc.) and the command line. I ended up using PHPStorm mostly because it was the only thing I could find with decent git integration, and I fell in love with it (but that's a topic for another post :) ). All the JetBrains IDEs are excellent and integrate with git very nicely. If you prefer a standalone GUI client, I understand there are now far better git GUIs than when I was looking.

One of the earliest difficulties I encountered was not being able to keep track of what commands I needed to achieve the results I wanted. I ascribe this to two things:
  1. the division of functionality across commands is very different from anything else I've seen
  2. in many cases, names of commands are not obviously logically connected to their function

My (slightly facetious) advice for those first learning git:

  • If you know another version control system, do your best to forget the names of commands and the association of functionality with commands

  • If you know English (which you probably do, if you are reading this :) do your best to forget what the words used for commands mean in English

  • If you don't know what command to use for a common operation, the answer is probably checkout or add, so look at them first!

Silliness aside, I really do think that part of my great difficulty in picking up git was trying to map functionality onto commands based on the verb of the command. Things went much better once I started treating the commands as (almost) random tokens that had to be assigned a meaning. I also had to accept that the division of functionality across commands was very different than what I was used to. There are some obscure commands for things that didn't have a separate command in SVN, and some commands are overloaded with multiple useful functions. I am given to understand that if you know git internals, the commands make sense, but frankly, I don't want to need to know that sort of thing to use a version control system. I found it a lot easier to not try to make sense of it and do my best to just accept it.

Which leads me to my next point! With git, you can't just ignore how it works, and you may not be able to pick it up on the fly. I know some people for whom it came really naturally, but I was not one of them. As much as I wanted to go back to my peaceful little world where version control took up a minimal part of my time and mental space, it was not to be. I do think that once you know git, using it doesn't take more time, but it is significantly more complex than something like SVN so I don't think you can avoid the mental space requirement.

Complexities that caught me up:

  • doing anything takes multiple commands

  • changes actually have 4 states, not 3

  • many entities, including commits, point at trees and are not independent objects

At first I found it very frustrating that it seemed to take 3 commands to achieve 1 useful result. Many of my common use cases were tedious (e.g., commit all my modified files) in order to allow for special cases I rarely used. I think most people using git from the command line have a whole lot of customization to make this work nicely. In my case, I mostly use tools that take care of the details. Do yourself a favour and get tab completion for git! I don't know why you don't get it by default with the install, and I cannot believe I didn't realize this was an option for the first many months I was using git.

I heard a lot about how wonderful git is because you can have local commits that aren't pushed. This feature didn't seem that great until I used it, and I still worry a little about code being lost because it wasn't pushed. At the same time, it is pretty sweet to be on an airplane and still be able to make atomic commits as you work. What I didn't hear about as much, at least at the beginning, is that there are actually four distinct states [EDIT: there may be more, these are the ones I know], not three:

  1. A file that has been modified

  2. A file that has been modified and staged (i.e. will be included in your next commit)

  3. Committed changes that have not been pushed

  4. Pushed changes

It was the second case that caught me up a lot at first. It is a bit mysterious how files become staged or unstaged as you merge/rebase/resolve conflicts/etc. "git status" is super helpful here, and things went better once I started using it all the time rather than trying to keep track of file state in my head. I do appreciate the helpful messages it provides, now that I know enough to understand them!

And now, the single biggest pain point I had in starting to use git: commits are not independent entities! They point at a tree that contains knowledge of their ancestry. You cannot just take a commit and put it on an arbitrary branch, even if the code changes do not conflict. This was a major stumbling block for me. I was used to keeping a mental model of whether changes were non-conflicting, and I expected that if a commit did not conflict, I could move it across branches at will. In git, however, each commit knows where it came from. Because I did not understand this, at first I found branch management in git unbearably painful, far worse than my experience in SVN.

The cause of the problem seems to boil down to the following situation:

  • There was a main branch, with a branch created for each release.

  • Local branches were created for features.

  • The nature of my work was that I did not know at the time I started it if it would make it into a given release.

  • I was typically the only person working in this part of the code, so I knew if there were conflicting changes on different branches.

  • I was in the habit of making branches from the latest version on main, if there were no conflicting changes.

This caused merry havoc in git. I routinely ended up with sets of changes that I knew did not conflict, but could not be merged or rebased or even cherry-picked from my branch into the release branch. Several times, I ended up re-making the changes by hand (an obviously terrible solution!) It is possible there was some way of recovering, but we had some pretty knowledgeable folks and none of them could find a way to resolve my situation using git commands. I was already starting to deduce that in some way, git commits knew what had come before. There used to be a fantastic page about the git object model, but is now defunct. You may find the git book enlightening.

Before I had this moment of enlightenment, I routinely trashed my local repository such that nobody could figure out how to make it workable again, and I'd end up re-cloning. This happened so often, and cloning our large repo was so slow, I made a clean clone I never touched, and copied it into my workspace each time I needed to start afresh. I think it's not a bad thing to do when you are first learning. Just remember to git pull after you copy it to workspace and before you do anything else!

As you might have guessed by now, I didn't get a lot of coding done for the first few months I was using git. I seemed to spend all my time struggling with the version control. I think much of that was me just not getting how to interact with it in a way it liked. I have heard people say that git supports any workflow, but it most certainly did not support the one I used. I realize now that I actually had an excellent subconscious knowledge of SVN, such that I was able to use it and very rarely fall into one of its pitfalls. Learning a whole new way of working, so that I could equally well avoid git's pitfalls, took significant time. I still wish I had a way of knowing what will happen when I push (if you know, please comment!) [EDIT: "git diff HEAD..origin/master" does the trick and could probably be made prettier with a little work]. My solution has been to push and then go look in GitHub, which makes me a little sad.

I think I'd have made the adjustment more smoothly if I'd done some training sooner. As mentioned before, I had found it hard to read many resources due to the tone. Also, I'd never needed training to use version control effectively before, and so I resisted. Luckily for me, I finally stopped being stubborn and took the training course with Matthew McCullough. It was excellent: he was very clear and friendly and not condescending at all. By the time I took the course, I had learned a fair bit the hard way; I just wish I'd done the course sooner and saved myself all that grief.

It has now been over a year since I started using git, and it no longer causes me much pain. I can't say I love it, but I've made my peace with it and can work productively again. I am still uncomfortable with the degree to which it lets you rewrite history; I feel this defeats some of the purpose of version control. The design of the command line UI still does not impress me, but the messages given while doing commands are very helpful once you know enough to understand them. Stash is brilliant and I use it all the time - it's much better than the patching I used to do. I do like having little branches for each feature. I even occasionally make use of the ability to stage only some of my changes, though I generally feel one shouldn't need to do that often.

GitHub is great and allows for a really nice workflow. I love how easy it is to fork any project and play with it, and it's always fun to see people have forked your projects and possibly even submitted pull requests! GitHub is also pretty good for workplace teams, and I like not needing another tool for viewing diffs and doing code review. I recently had to decide on source control for a new company project, and while I looked around I chose GitHub in the end. I'm not sure I'd pick git on its own, but GitHub definitely tips the balance.

Partly, git was a hard sell to me because I didn't feel the pain of SVN and many of the listed advantages of DVCS were not important to me. There are some definite wins, though, and hopefully those coming after me will find the wins sooner and with less pain than I did.
geekchick77: (Default)
I entered university in 1997 and graduated with a degree in computer engineering in 2002. I read "Unlocking the Clubhouse" while in my fourth year of university, as I was burning out, and it was transformative. It renewed my energy and enthusiasm for my degree, helped me understand the forces that were discouraging me, and reminded me why it is important to persist. Since then, I had occasionally read blogs or articles about women in tech, and had personally known a few other women in the field. I knew there were other women out there, and I had personal connections with a small number of them, but I had no sense of being part of a community of women in tech.

While I was establishing my career, I more or less kept quiet on gender issues. I would occasionally talk to sympathetic colleagues, but I was afraid to rock the boat. I didn't want to be labelled a feminist or a troublemaker. And, to be perfectly honest, I do not regret this decision. I think it would have been unwise for me to make myself so vulnerable before I had established myself. It is my fervent hope that those of us who have "made it" (I now have 10 solid years as a software developer) can make it better for those who follow, but I still would not encourage a woman just entering her career to raise a big fuss. Trust your gut, and do only as much as you are comfortable doing.

This started to change, a little, when I was invited to WisCon, the feminist science fiction convention. For the first time since my childhood, I was connecting with a community of feminists. It was amazing. At the time, I don't know that I even considered myself a feminist, but it became clear that in an important sense, I had found my tribe. I realize that I was, most definitely, a feminist. I vowed to return to WisCon every year, if at all possible.

At WisCon 2011, I was at a panel and another woman in the audience asked a question about picking your battles, to what degree and how you should do so. She mentioned that she was in a male-dominated field. Each of the panelists gave a lovely and inspiring answer, all of which boiled down to, “don't pick your battles, stand up for what you believe in!” I reflected on their backgrounds, and realized not one of those women was in a heavily male-dominated field. It's not that their answers were wrong, per se, but they were not relevant. There are far, far too many battles in my daily life for me to take them all on. I am not going to respond to every mildly sexist comment or joke. I am not going to try to educate every coworker. It is simply too much. I would burn out in a matter of months.

After the panel, I went over to talk to the questioner. I was brimming with empathy and ready to discuss all my best strategies for surviving this industry. I had no idea, at the time, that I was speaking to Valerie Aurora, a linux kernel coder (a much higher echelon of geekdom than my own) and an expert on issues of women in tech. We went for lunch, and talked, and when I realized who she was I was subtly mortified that I had thought to help her. She already knew pretty much all I knew, and all I had to offer was my solidarity and support. When I look back on it now, I realize that sometimes, solidarity is the most powerful gift of all: just knowing that you are not alone in what you face, and that what you are doing matters to others.

I stayed in touch with her, and she kept me informed as she started The Ada Initiative. Her support and advice was instrumental in me aiming higher in my career and in my becoming more vocal in the face of sexism. She also connected me with a group of geek feminists I had no idea existed. It has meant so much to me to find a group of people facing the same realities I face. It's possible I would have written my IRC talkbackbot if I had not met her and found this community, but I would never have thought to blog about it. All of the people I reached and the recognition I received are due in no small part to Valerie's inspiration and encouragement.

I saw the tweets about AdaCamp DC 2012, but never thought to apply. I work in closed-source software, and I haven't participated in any open-source projects. I don't think of myself as a woman in “open stuff”. However, she encouraged me to apply, and so I did, and was accepted. I somehow had the dates wrong (I thought it was in the fall) and only realized my mistake a few weeks before the event. I was crushed to realize that I probably would not be able to go on such short notice.

Then, I was offered my dream job, and my current employer generously allowed me to leave well before my two weeks was up, so attending AdaCamp was once again a possibility. I dithered agonizingly, trying to weigh the cost, the time, the fact that I had to move across the continent immediately upon my return, against my overwhelming desire to attend. In the end, I decided to go for it, and I am so glad I did. (Thank you to my hosts, who made my last-minute attendance possible!)

I felt like the first day was a little stilted, and the energy didn't really get going until the second day, but it's hard to say how much of that was my exhaustion from being on a red-eye and going straight to the conference venue. I had to miss a little of the introduction, but I've been to a few unconferences before so I had a good idea what to expect. I suggested three sessions, one on my talkbackbot (in case anyone wanted to learn about it), one about how to deal with the assertion “women just aren't interested” in tech, and one on boundaries.

As often happens, the sessions were excellent but I think my favourite part was the random conversations. There was an in-depth lunch conversation about being a good student and how differently that affects your status depending on what country you grow up in. There was a long conversation about ways in which women don't support other women, and why that might be.

An absolute highlight was the session in which we constructed a timeline of the significant positive and negative experiences we had had in relation to technology, organized by age of occurrence and tagged with year. It was fascinating to see the cluster of experiences in the late teens and early 20s, and also to note the big gap in negative childhood experiences. I wondered if perhaps women who had significant negative experiences in the 5-15 range simply didn't make it into tech at all, regardless of whatever interest or aptitude they may have had.

We had a productive session on hiring. From the perspective of employers: how to make job posts that will encourage diverse applicants, where to make posts so that women and minorities will see them, what aspects of benefits and culture to develop and emphasize. From the perspective of applicants: how to find good companies, how to network, and most of all, how not to sell yourself short. We also briefly discussed some of the worst of recent job posts, e.g. “bro down and crush some code”, “PHP stud wanted”, and all the calls for ninjas and rock stars. We started joking about opposite and equally ridiculous job posts, e.g. “PHPrincess needed”, “Coding queens wanted”. We lamented that “maven” has been taken by a specific technology, as it would be a great word to use in a general sense to imply subtly female competence. We were laughing so hard at the job posting ideas someone from a neighboring session had to ask us to be a little quieter so they could hear each other.

Another interesting session was about technical and non-technical women supporting each other. To have a group of women with different interests and aptitudes talking about how we can all make the world better for each other was incredibly moving for me. As one women so aptly summed it up, it was great to have a positive female experience. To realize how we can help and support each other, whether that takes the form of the techies teaching the less technical, or whether it involves us taking on the technical tasks so that the less technical can focus on contributing their strengths in writing, curating, etc.

The sessions on burnout and boundaries were very powerful. I was reminded of the times I have been responsible for a range of managerial tasks (simply because I'm responsible) without the recognition or pay those duties would normally entail. I knew intellectually that women commonly end up in these situations, but hearing woman after woman talk about experiences so like mine definitely took that knowing to a new level. It's not right or fair to take advantage of people in this way, and we need to start drawing our lines in the sand. It is understandable that a business will try to get as much as it can while paying as little as possible, but that doesn't mean we have to agree to it. We explored our own complicity in these situations. We looked at the fears that drive us to be always reliable, always responsible, never letting anyone down. We discussed how our fear of saying no allows others to take advantage of us. Some of us, who have done more experimentation with setting boundaries, were (I hope) able to inspire those in painful situations to start sticking up for themselves. One particularly inspiring story was a woman who has decided to limit herself to 40 hours a week, and she has found that not only does she still have her job, but she is achieving all her work goals. It is true that setting boundaries will result in a certain degree of backlash, particularly at first, but most people will accept it. For those who don't, we brainstormed strategies like talking to them directly, talking to a manager about the issue, and providing data on the relationship between productivity and time worked.

One of the more profound comments I heard was that nobody else is ever going to tell you that you've worked enough; it's up to you to decide to go home. That is not 100% true (I have had a manager who was excellent on that front) but it is broadly true. Others will more or less take as much advantage of you as you allow.

One idea that kept coming up in session after session was how much women sell themselves short. We have to be so competent before we consider ourselves technical. We might use a technology for years and still not think to put it on our resume. We are too self-deprecating to imagine that people whose work interests us would want to talk to us about what they are doing.

One regret is that I did not make it to any of the sessions on LGBT issues. I will have to content myself with notes and blog posts, at least until the next AdaCamp!

The conference was very well organized. One thing I particularly liked were the 4 role cards for those acting as facilitator, gatekeeper, time-keeper, and note-taker in each session. The 15-minute gap between sessions was brilliant: it gave one a chance to finish conversations, find a new session, and change rooms without feeling rushed. The food was amazing, absolutely the best conference food I've ever had. There were plenty of options for vegetarians, and it was delicious. It was a nice idea to have small group dinners at restaurants off-site, as it allowed people to get to know each other better.

In short, AdaCamp was fantastic and I am so glad I made it. Major kudos to The Ada Initiative for putting it on, and thank you to everyone who volunteered so the rest of us could enjoy the conference. I <3 you all!
geekchick77: (Default)
Yesterday I came across several articles about facial recognition software failing on non-Caucasian faces. The articles are several years old, at this point, but they got me thinking. The first is about a Nikon Camera that “helpfully” asked “Did someone blink?” when taking photographs of smiling east Asian people. The second is a HP web-cam failing to track a dark-skinned face. The third was about the Microsoft Kinect having issues recognizing some dark-skinned gamers.

I am not familiar with the specifics of the technology behind these devices. However, I doubt anyone set out to create substandard software. Certainly, in my years as a software engineer, I have never seen anyone diabolically plotting to exclude whole classes of users. What I have seen is cluelessness and lack of empathy. Engineers often have trouble imagining using a system as someone other than themselves, whether that someone is less technical, from a different culture, or simply looks different.

In each of these cases, it seems very likely to me that the system has some kind of basic AI, perhaps a neural network, and was trained using inadequate sample data. When it was tested, it was no doubt done using similar sets of data. It is quite possible that during the entire development process, it did not occur to a single person to question whether the software would work adequately for darker skin or different facial features.

People often ask me why I care about the lack of diversity in software development. I do care, deeply, and for me much of comes from a sense of justice. It seems terribly unfair that people are discouraged from pursuing a field they are interested in and care about. Even if the inherent injustice does not bother you, though, here is a reason to care:

We are making worse software because there isn’t anyone to question the basic assumptions of predominantly young, white, male software developers.

I think that computer people as a whole tend to be invested in rationality and logic to the point that it is difficult to recognize our own humanity. We are affected by social conditioning and cultural values just like anyone else. If we are going to progress toward the meritocracy we say we value, we need to become aware of our blind spots. Ultimately, I hope we will see a broader range of people in software development. In the meantime, we can try to be more thoughtful and create excellent software that works for ALL our users.
geekchick77: (Default)
Not too long ago, I partitioned my mac so I could put Windows 7 on one partition for gaming. I was dismayed to discover that simply installing Windows took over 20G. I've done some digging to figure out where all my space is going, using WinDirStat. One big space eater was hibernate, which I have since disabled using this how-to guide. Furthermore, even though I have 8G of RAM on this machine, Windows was setting aside a huge pagefile.sys. If you have a lot of memory, as I do, you can disable or limit virtual memory.
geekchick77: (Default)
Last year, at WisCon 35, I was at a panel where an audience member asked a question about picking your battles when it comes to discussions about feminism. The answers from the panel were well-meaning, but I couldn’t help but feel they did not understand the questioner’s reality. I reflected on each panelist’s bio, and realized they all worked in female-dominated careers. It is a very different experience being the only woman in the room or perhaps the only woman in your company.

That moment got me thinking, and I realized that in all the wonderful WisCon panels I have gone to over the years, I could not recall any that were focused on women in technology, or women in male-dominated careers in general. It can be difficult and frightening to start connecting with the feminist community. Many of us get through our early career by being “one of the guys”: laughing at the jokes, not making a fuss. There is a real (and I think, reasonable) fear of retaliation or blackballing if one addresses the frequent sexism in technical workplaces.

As a woman in a heavily male-dominated career, you can end up feeling very isolated and alone. When you do encounter other women in the field, they may not be the allies you expected. You may suspect you are being marginalized in your career, but have trouble putting your finger on exactly how. Even worse, it may be extremely clear that some of your coworkers and bosses are not treating you fairly.

The good news is that you are not alone. There are many feminists working in technology, and some who have moved beyond their jobs as engineers to devote themselves to encouraging women in technology. At WisCon 36, I am moderating a panel for women in male-dominated careers. It will be a space for networking, sharing tips, strategies and resources, and talking about challenges.

The panelists have put together the following list of resources, which I will updating with suggestions we receive during the panel.

Unlocking the Clubhouse, by Jane Margolis and Allan Fisher
I am not exaggerating when I say this book kept me in university. I was experiencing everything they talk about: the sense of inferiority, the loss of interest, the withdrawal. Reading this book renewed my commitment to my chosen career path. - Jessamyn

Women Don’t Ask and Ask For It, by Linda Babcock and Sara Laschever
(suggested by Jessamyn and Carolyn) If I could give every young woman a single book to help her start a career, it would be one of these. Asking for what you want isn’t easy and will not always work, but it is one of the most worthwhile job (and life!) skills you can have.

How to Suppress Women's Writing, By Joanna Russ
While not about technology at all, I was amazed at how parallel the experiences of women writers are to women engineers. Highly recommended. - Jessamyn

Mad Women: The Other Side of Life on Madison Avenue in the '60s and Beyond
, by Jane Maas
I just finished this book, on a recommendation from a friend. Mostly amusing, but it does have some interesting subtext about competitiveness, sponsorship, and how these come into play for successful working women 50 years ago. - Carolyn

Love is the Killer App
, by Tim Sanders
Suggested by an audience member as a resource for those not wanting to conform to the traditionally cold and distant workplace.

A resource to learn about companies and compare your salary and benefits. Asking for what you want at work is hard, doubly hard for women, and knowing the facts is a big help.

Imposter Syndrome
If you frequently doubt your competence, despite significant achievements and positive feedback, you are not alone! Many geek women experience Imposter Syndrome, consistently feeling they are not as good as others believe them to be, and it is only a matter of time until they are found out. Once you understand what is going on, you can take measures to create a more realistic sense of your competence.

LISA '11 Boston: Women in Tech Panel

The Large Installation System Administration conference in 2011 had a panel on women in technology, which sparked this excellent blog post about challenges and how to make a space friendly.

GeekFeminism Wiki
This is a wonderful resource, with a wide variety of guest blog posts, 101 pages, and tips for women in tech and people who want to encourage diversity in their workplaces. It also has event listings and timeline of incidents at tech events.

The Ada Initiative

TAI is dedicated to supporting women in technology. They help organizations and events become more welcoming to women, provide resources for technical people, and also run AdaCamp, a conference on women in open technology and culture.

Anita Borg Institute

ABI is devoted to increasing women’s impact on the world of technology and increasing the positive impact of technology on women’s lives around the world. A list of their many programs can be found on their website. One initiative, the Grace Hopper conference, is a showcase for women’s research and career interests in technology. Carolyn noticed this excellent ABI blog post on why there are so few women in CS.

There are a number of resources specifically for those interested in learning to code and/or become involved in open source work.

Open Hatch - Helps people find and get involved with open source projects

wiscondb - Our very own WisCon scheduling software!

PyLadies - International network of women Python programmers

DjangoGirls tutorial - Highly recommend resource for learning Django

Ladies Learning Code - Toronto-based group helping women learn to code

CodingBat - Online beginning coding exercises with visual feedback (very cool!)

Dr. Chuck - Python courses and resources, including the very popular Programming for Everybody

Codecademy - Great online resource for learning to code

PythonTutor - New resource for learning Python!

Expect more awesome resources to be added to this list post-panel. :-)

I am very excited about tonight’s panel, and I hope to see you there!  I love that WisCon has so much information about people who are imagining a more diverse future, and I look forward to more inclusion of those dedicated to building the technology that will help take us there.
Page generated Apr. 19th, 2019 12:49 am
Powered by Dreamwidth Studios