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.
- ALL databases must be at the same migration level before you begin.
- If you have a custom user model, do NOT delete the migration that creates it. You can safely delete subsequent migrations.
- 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"):
- Ensure all databases (local, staging, production, etc.) are at the same migration level.
- Create backups of all your databases.
- Save the code for any data migrations in a temporary file.
- Delete migration files from 0002 upward (assuming 0001 created the custom user) and commit to git
- delete from django_migrations where app='users' and name NOT LIKE '0001%';
- python manage.py makemigrations users
- Recreate any data migrations.
- Verify that migrations run successfully on a clean database.
- python manage.py migrate users --fake # Run locally
- Commit new migrations.
- Push changes to all other systems and on each run: python manage.py migrate users --fake
Procedure for apps in general (e.g. "myapp"):
- Ensure all databases (local, staging, production, etc.) are at the same migration level.
- Create backups of all your databases.
- Save the code for any data migrations in a temporary file.
- Delete migration files for myapp and commit to git.
- delete from django_migrations where app='myapp';
- python manage.py makemigrations myapp
- Recreate any data migrations.
- Verify that migrations run successfully on a clean database
- python manage.py migrate myapp --fake # Run locally
- Commit new migrations.
- Push changes to all other systems and on each run: python manage.py migrate myapp --fake
"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.
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. :)
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.
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.
My slides are available here: https://eggtimer-slides.herokuapp.com/
Slide source: https://github.com/jessamynsmith/eggtime
Eggtimer web application source code: https://github.com/jessamynsmith/eggtime
Eggtimer mobile application source code: https://github.com/jessamynsmith/eggtime
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!
My slides are available here: https://codementor-slides.herokuapp.com/
Slide source: https://github.com/jessamynsmith/codemen
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.
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:
- Select the "15 minutes free" option on your profile -- it really helps get new clients.
- Start out with a relatively low hourly rate and increase it slowly as you get more clients.
- 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.
- 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!
- Stay logged into the site, and watch incoming requests. Often, the quickest person to say "I can help" gets the session.
- 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!
- It's often helpful to ask more questions, either on their request or in chat.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- Forgetting to add a package to requirements
- Forgetting to run the linter
- (rarely, but it does happen) Forgetting to run unit tests
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
python manage.py 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/ac
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.
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.
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.
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.
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:
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
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.
- battery life
- OS upgrades
- availability of hardware
- screen size
- hardware buttons
- better keyboard layouts
- perfect gmail integration
- easier testing of development apps
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:
- the division of functionality across commands is very different from anything else I've seen
- 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:
- A file that has been modified
- A file that has been modified and staged (i.e. will be included in your next commit)
- Committed changes that have not been pushed
- 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 http://vrac.cofares.net/git-one-pag
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.
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!
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.
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.
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.
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.
I started out by installing homebrew, which is simple enough. I tried running brew doctor and got a message about how my XCode was out of date.
I have no idea why you can't just download XCode from Apple's site. I don't use my Apple login often enough to be able to remember it, so I always have to hunt around before I am able to log in. Next up was navigating the App Store, which was non-obvious to me. It took me quite a while to realize I had to click the "Free" button beside the dropdown to start the download. After waiting for the rather lengthy download, I discovered that installing XCode is no longer enough to give you command line tools. You are supposed to be able to install them from inside XCode, but I could not see them under Downloads. In the end, I logged back into Apple's site, at https://developer.apple.com/downloads/
I usually add the following to my .bashrc so my brew installations are found ahead of any system installations:
Finally, I was able to run brew doctor and get on with my project!
On each computer:
1. Buy BG2 from gog.com, download, and install
2. Set compatibility mode on BGMain to Windows XP (Service Pack 3)
3. Run the game and switch to windows mode (alt-enter)
4. Sign up for game ranger: www.gameranger.com
On the host computer:
5. Host a BG2 game on game ranger
6. Wait for friend(s) to join the game on game ranger
7. Assign characters and start the game
8. Go back to full-screen mode (alt-enter)
Note: If my power came unplugged while playing, it would lock up the game. As always, save often!
You may not need game ranger unless both computers are in the same network, but it made hosting a multiplayer game so easy that I definitely recommend it!