Delivering a Technical Course to Busy Developers

At work, I'm experimenting with how to deliver a technical course to my fellow employees in such a way that participants succeed and our team doesn't have to put in too much time on top of our regular duties. Just making them available for self-directed study results in most folks poking in for an hour and never returning. If we can come up with the right delivery model, we can make all the courses we create for other purposes available to our colleagues without adding stress to our already busy schedules.

Many of our courses were designed for students in our work-integrated learning program first. Most material is curated with our own added context and assessment, and courses are intended to be completed in a self-directed manner. For our WIL students, we provide lots of feedback on their work and hold in-person sessions that range from formal tutorials to quizzes to pair programming assignments, all of which require quite a bit of time and attention from our education team.

I chose a Ruby programming course for my first experiment this summer since the majority of our development is with Ruby on Rails. I put together a series of short workshops previewing Ruby to our Dev Degree students and a more in-depth project-based course the same students took later on. The students spent two hours each on five workshops and about 20 hours a week for 3 weeks on the project.

I initially made the new course 8 weeks long, though we added a breather week partway through. Interested learners were asked to get lead buy-in, and were told they'd need to spend some time during work to succeed. I sent students some pre-learning resources both to set expectations of prerequisite knowledge, and to offer help for those who wanted to fill in any gaps. I recruited experienced Ruby developers as mentors who would answer questions, formally review project work, and run weekly tutorials using video conferencing software. Assignments were due each week, but with soft deadlines; getting an assignment in on time meant being paired up automatically for a peer review.

The course started with over 50 confirmed learners. Many have dropped off since, which isn't unexpected. Some realized that they didn't have enough problem-solving-oriented knowledge, and will likely take one of our intro to CS courses when the opportunity arises. Others found the everyday demands of their jobs made it difficult to keep up, and though there are exceptions, it seemed that once someone fell behind, they more often than not just stopped working on the course.

The course didn't end up being too demanding on my time, but it doesn't look like very many students will finish it. We wrap up next week, at which point I'll start to dig into who finished, who didn't, and why. I plan to have some anonymous surveys as well as focus group discussions. It will be really interesting to see whether we can find some tweaks that result in more success stories.

Have you ever tried to deliver a technical course to your colleagues? What did it look like? What structure worked well?

Six Months On, Six Months Off: My Experience of Maternity Leave in Tech

Today, my second child, Henry, turns one. I went on maternity leave for six months when he was born, which means I have also been back for six months. I was a grad student when I had my first baby, so life was pretty different then. Being International Women's Day in addition to Henry's birthday, it feels like a good time to reflect on my experience this time around.

Henry eating a cupcake at his daycare's birthday celebration.

In no particular order, here are some thoughts about my six months off:

• I felt pretty useless the first 6-8 weeks, recovering from a repeat c-section after 50 hours of labour towards a failed VBAC.
• Everything was changing on my team when I left, big time. We had a new team lead who was amazing, but this fact gave me all kinds of feels as I was more or less 'in charge' until then. 
• I kept close tabs on the goings-on of the team while I was away. Slack was part of my regular social media rounds. I even contributed with tangible work here and there when there was something I could help with or that I was really invested in.
• I managed to get a lot of reading done during my leave and that felt really good.
• I missed the office (the actual building in addition to the people there).
• I decided I wanted to pursue technical leadership instead of people management as a career path.
• I didn't have the motivation to go out to play groups or baby classes as I did the first time.
• I didn't socialize much other than visiting with family. (It was great to visit my parents' pool patio for example, even if I rarely actually swam.)
• Making lunch for myself sucked (we get free lunches at work).
• I constantly asked my husband, who works at Shopify as well, what was going on at the office, what was for lunch, whether he brought my any dessert, etc.
• I felt very grateful that I could take so much more time off than my American friends, and have my EI allowance topped up by Shopify the entire time.
• My team sometimes joked that I never really left.

And some thoughts about my first six months back:

• At first, I struggled with rejoining as an individual contributor on a team I had in some ways started and led for a while.
• My husband was on leave for the second half of Henry's first year and he stayed completely disconnected from work by choice.
• It was incredible how fast things had moved while I was away, and I can't imagine how far behind I would have been if I hadn't stayed connected.
• I was happy to be able to jump back in quickly with work I was very familiar with from before my leave.
• The first four months were difficult in terms of scheduling meetings, pumping sessions, and time with students whose schedules were very complicated. Some of my newer colleagues questioned my time management skills / commitment to quality.
• Henry was a terrible sleeper the entire six months I was back at work (we only sleep trained him this past week and before that waking up every two hours was a 'good' night). I was running on near empty and had nothing left to give outside of work.
• I missed carpooling with my husband and eating lunch with him, but also enjoyed the slight increase in schedule flexibility knowing he could pick up our daughter from school. It was also nice to eat with teammates and get to know them.
• I'm finding myself wanting to wean in the near future, despite having nursed my daughter until she decided to stop on her second birthday.
• I had a hard time enjoying Henry during these months, largely due to sleep deprivation and perhaps being away from him most of the weekdays. But that's back on track now that I am sleeping!

So many feels, this whole baby thing! I'm incredibly grateful to have had this experience while working at Shopify, which appears to be one of the best tech companies in this regard.  However, it's easy to see why being on leave for any number of months, let alone a whole a year, can hurt someone's career. Our society definitely needs to continue figuring out how to balance to scales for folks who leave to care for family, and to encourage men to take leave as often as women.

When Feedback Makes You Cry a Little

Feedback really is a gift. But feedback can also be hard, both to give and to get. I moved into a leadership role a little over a year ago, and got my first hard-hitting feedback at the end of 2016.

The fall was a stressful time for our entire team. We were launching something completely new with fewer people than we needed and inherently inflexible deadlines. I was pulled in multiple directions as I tried to build what our team would do more broadly, champion this one huge project, and do a fair bit of individual-contributor work that really did have to be done by me in the circumstances. Everyone else was faced with wearing too many hats, too. We managed to maintain a very high quality through the fall but we were all worried about what was looming in the new year.

Late fall, my lead initiated a feedback process for me that included everyone on our team and a bunch of folks that worked with us. I also did a self evaluation. It's a standardized process used with all folks in leadership roles. I got a report back with a summary of scores on the various questions and the written responses, but of course none of the names to go with them.

When I first got the report, my heart just sank. How poorly I had calibrated my self-evaluation is what struck me first - most scores given to me seemed really low. Then I started to read the written stuff and my heart sank even lower.

Nothing written was mean, and in fact, none of it was unfair. It took a day or two of reflection, but the feedback was absolutely right.

I wonder if there are known stages of absorbing feedback, like the stages of grieving. At first I felt shock, then I felt a little upset, and then I felt horrible about how I had made the team's lives harder in some ways. It was difficult to realize how much less self-aware I was in some areas than I imagined.

After reading the report I had a session with one of our internal coaches. I definitely cried a little in that session. We worked through the feedback, me talking through what likely caused it and how I missed realizing what I was doing. It was extremely valuable and I highly recommend doing something similar if you can.

The coach gave me some suggestions for how to address the feedback with my team. At our next standup I brought it up using her advice and cried a little again. The team was so wonderful. It became really clear that the feedback came from a place of us all caring about each other very much. It was a difficult but very important experience.

I was able to put some of the plan for addressing the feedback into action before leaving to have a baby a couple of months later. My biggest takeaway, besides the specifics of the feedback, is that I need to give and ask for feedback more often. It's not always easy, and it might make you cry a little, but it is so so worth it.

GHC16 / What Are Tech Tools Doing That The Best Diversity Initiatives Aren't?

How can software help companies recruit and hire more diversely? Erica Joy Baker, Laura I. Gomez, Stephanie Lampkin, Liz Kofman, and Aline Lerner tackled this question on a panel at Grace Hopper this year. Most came from the perspective of creating the tools or working in tech, and one came as a social scientist studying the problem. It turns out that technology can do a lot, from removing biases to helping employees find good matches in prospective employers.

Here are my live notes from the session, edited slightly since I took them.

- we'd like to have the tech to kill the resume and allow for anonymous processes where everyone is evaluated the same
- what drives behaviour change? show candidates what's really going on in companies
- "I don't believe in unconscious bias training. I believe in results."

- compelling to see results of a fairer, more competitive process
- many challenges in academic research: one group, no change, another group, huge difference (why?); the more data we have, the more we can figure out what's really going on
- early feedback is that demystifying 'the pipeline' idea has been valuable

- technical interviewing it totally broken; interviewing as a process is as effective as putting names on a dartboard and throwing the dart (this is especially true of unstructured interviews, which have no correlation to success outcomes; structured interviews have a tiny amount of correlation)
- competency-based interviewing helps structure interviews as well as check later whether the interview ended up being a good predictor of future performance; issue is that managers don't know what competencies matter, so hand-holding in that regard is needed
- big companies need to have the same vocabulary and awareness of where the issues are

- want companies to dissect what makes a high performing employee, then capture that about a candidate; again, because traditional interviewing sourcing process is broken; need chances to capture data in soft skills, behaviour science, neuroscience...

- hiring processes are antiquated; why haven't we seen much innovation in this space?
- change is hard partly because those responsible for letting folks into the pipeline don't have the skills they're recruiting for; they have the wrong incentives

- anonymizing applicants: is this the same as that Wall Street Journal author's suggestion, which made many women and other feminists upset?
- even when we remove the name, there are other indicators; how you write can identify you, even when what you said doesn't change
- anonymization doesn't take away identity; it lets folks look at us differently

- audience question: should companies be aiming to improve diversity? how will anonymization help them identify those candidates?
- yes, there are companies actively sourcing; mixed evidence on blind identity (may not help companies that were already trying); have to understand the context of the companies, each of which are so complex
- not as simple as sourcing underrepresented groups; need efforts to improve the process and give resources to those that don't have them
- recognize that we do have biases, and give tools to interrupt them

- audience question: has bias affected how much funding your companies have received?
- bias toward funding previously successful founders, even though data shows this isn't a good indicator of success
- needs to be more examples of success because there's a lot of pattern matching going on
- Stephanie: need to set the example as a young gay black woman, farthest from an old white man as you can get
- having a personal brand ended up helping some of the panellists (though not deliberate); e.g doing a lot of writing on the broken hiring process and sharing data

How to Be a Leader, Shopify Style

Self-actualization, that thing at the top of Maslow’s hierarchy of needs: “what a person's full potential is and the realization of that potential.” Shopify cares deeply about growth, and aims to be a company where its people reach the self-actualization level of the pyramid. I think that’s pretty special, and it’s just one of the things that leaders need to manage during their time at Shopify.

For the last few months, I’ve been participating in what we call Lead Level Up. I’m not formally a team lead yet, though I have been in a bit of a leadership role and should become a team lead eventually. A lot of what we learned in the all-day kick-off is general enough to share, so I’m going to highlight the things that resonated with me the most. Most of what follows comes from our CEO and co-founder Tobi’s presentation that day.

An interesting fact is that Tobi and his co-founders/early employees didn’t know how to be managers. It was an entirely new skillset. Tobi admits he was not a natural manager; he found it difficult losing the tight feedback loop you get when programming. He admits he fought often with the others in the early days until they sat down and decided to respect each other by committing to being honest and improving their feedback.

Tobi ultimately believes that he was able to improve his own management skills by learning how to better give effective feedback. Everyone is bad at this at first, and there is no limit on how much better you can get. It can be really difficult to take feedback as the gift it is because your ego is so tightly wrapped in the exchange. When I was an instructor at Carleton, I learned how hard it can be to give good, honest feedback, especially if the other party (students, in my case) don’t entirely trust that you have their best interests at heart. I’m now learning to give feedback with radical candour.

A major tool that will help any manager is trust. Trust is more nuanced than a binary relationship. Trust exists between departments, and is fundamental to being highly aligned and loosely coupled (that is, fast-moving teams with high autonomy working toward common goals). When you start seeing a large amount of process being introduced, it’s usually because there is a lack of trust. Process is a prescriptive solution to a problem that isn’t terribly intuitive. It’s a bit like baby-proofing.

After trust is established, the manager’s job is to make their team better every day. If the team is not getting better, it is getting worse. Questions a manager can ask include whether they can remove any ambiguities or dependencies, have they helped someone have a breakthrough, etc. Focus on the high leverage activities that yield the greatest output for your team. Teaching, for example, is high leverage in all its forms. One-on-ones, while important, may generally not have high leverage.

Speaking of one-on-ones, how do you make them effective? Have them at least once a month. Take notes. Find your own style. Use them as a learning opportunity, and a chance to understand the other person. There will be hard situations, and they are only solvable if you have an extremely good read on all involved. Crucially, you must give good, honest feedback. And if you ever hear during a one-on-one that you have made a massive, positive contribution to someone’s life, then you know you’ve made it as a manager.

As mentioned above, managing is an entirely new skillset. Become well-rounded, focus on personal growth, read a lot (e.g. High Output Management and Thinking Fast and Slow). Become the guidance counsellor, the coach, the shrink. Help get yourself and your team to self-actualization, and you’ll do just fine.

Mastering Difficult Conversations

Do you dread bringing up a problem in your relationship because you know your partner will be blinded by emotion? Are your 1:1s at work just happy recaps of your weekend because nobody wants to bring up the hard issues? Sometimes conversations are just plain hard, but it is possible to learn how to have them effectively. I've personally learned a lot from Difficult Conversations: How to Discuss What Matters Most, and have even put some of it into practice already.

The book introduces three conversations that are really taking place in a difficult conversation: what actually happened, how feelings factor into it, and how the participants' identities might be affected. When you're about to embark on a difficult conversation with someone, you should first walk through each of these three conversations to sort out where your story came from as well as the other person's, to "explore your emotional footprint," and to reflect on what's at stake in terms of how you see yourself.

Then, you need to determine what your real purpose in the conversation is. Generally, it's a good idea to come from a place of learning, which means keeping your mind open to the fact that you could have been wrong about how you viewed the situation.

When it's time to talk, you want to start from the "third" story – that is, you need to "describe the problem as the difference between your stories." You have to pretend you're an innocent bystander, and invite the other person to become your partner rather than your adversary in sorting out the problem in front of you.

During the discussion, you have to be an amazing active listener (so much easier said than done!). Acknowledge, paraphrase to check understanding, question...and continually reframe to keep on track. Then, finally, you can get to the problem-solving stage.

A few key takeaways for me:

• Never lay blame; instead, talk about contribution, and try to reframe the conversation to help the other person do the same. Every problem arises because of contributions from both sides, even if the split is 95% to 5%.
   
• Pay special attention to feelings. They are always there, and they can get really complex. Even in a professional situation, it is ok – and important – to discuss how various actions and outcomes make you feel. It can help to sort through feelings before the conversation so you can unpack complex bundles of emotions and better explain your perspective.
   
• Be mindful of your identity, and how it has been affected by the problem you are facing. The reason that the conversation is so difficult might be because you have to face the fact that you may not be acting in alignment with how you see yourself.
   

I've used the ideas in the book already to talk through how a friend might be able to approach their next 1:1 at work. The feelings story was of particular importance in this case, and not something that my friend would have talked about normally.

I have also found the knowledge useful when faced with a difficult conversation started by someone else. Where I might have normally become defensive and frustrated, we were able to resolve our problem somewhat quickly. (Now I just have to make sure I don't do the same dumb thing again.)

I think this book would likely have something useful in it for just about anyone. If you're in a leadership position of any kind, it will be all the more valuable.

My Nonlinear Career Path

I've had a really nonlinear career path. One step forward, two step sideways, new goal, start it all again...

My interest in computers started at a young age. I was lucky that my dad, a government worker, was able to bring home the computers his office was done with. As a result, I have had access to computers, and even had a computer in my own room, from a young age.

I've always loved to create with computers. From writing stories to designing newsletters for my Guiding troupe, I was always making things. Even today, I make digital scrapbook pages!

In high school, I started becoming more and more curious about how things work "behind the screen," so to speak. How do you write code to make a word processor? What's the math behind vector graphics? How does computer hardware, at the lowest level, add two numbers?

I decided I wanted to take computer science in university so I could learn all this and more. I didn't learn how to program in high school; instead, I took drama and music while I still could. But I was pretty sure I'd love the world of code whenever I eventually entered it.

Turns out I was right. I also loved working in the industry during my co-op terms. One of my jobs was at Ross Video, working on software for a video production switcher. The other was at Corel, where I worked on the text engine for Corel DRAW, software I had used for many years in my personal projects.

Nearing the end of my undergrad, the most difficult decision I faced was which of these two companies I would try to work at full-time. I never thought I'd do anything other than go to industry.

I was going to be a software developer.

Until, that is, a professor approached me and convinced me to consider graduate school. The catch? The application for the big scholarship was due in a week. Well then.

Image adapted from Ivory Tower by OfTheDunes

I applied, and I got the scholarship. So I went to grad school for my Masters. I had a great time, and even got my start in outreach, but learned something very important: I didn't care for the low-level, experimental nature of my thesis topic, and wished I did something more applied.

I decided to continue on to my PhD, choosing storytelling in videogames as my thesis topic. I engaged in educational games and computer science education research on the side. I also took the opportunity to gain more teaching experience. I eventually realized that education was my passion and I wanted to teach.

I was going to be a university instructor.

After some contract work, I got a two-year term position as a full time faculty instructor. I made an impact with some innovative course designs and a lot of hard work in outreach and diversity. But when I tried to get a permanent instructor job, I missed it by a hair. Although I was not yet finished my PhD, I didn't really fancy going back to being a full-time student. Instead, I figured: why not go back to industry and be a software developer again?

So off to Shopify I went. I joined the Home team, working on the first page merchants on the Shopify platform see when they log into their admin. I learned both Ruby and Rails, and finally had a chance to try real-world web development.

I quite enjoyed working as a developer, but it was a step sideways from my goal of teaching. However, in the fall, an opportunity arose.

I was going to jump back into education once again!

Starting this past January, I became Manager of External Education Programs. I'm working on some really exciting education projects, including a sponsorship of the Ottawa Network for Education's AppJam. I get to create curriculum, teach, and even create a team of similarly passionate folks here at Shopify.

So while I have taken some steps back in my career, and some other steps sideways, I find myself feeling very fortunate to end up where I am now. So if you ever find yourself on a really windy career path, don't fret: go with the flow, and see where it takes you. You might find yourself ahead of where you expect, even if it you hit your goal at a bit of a strange angle.

Review / Ruby on Rails Tutorial: Learn Web Development with Rails by Michael Hartl

When I started at Shopify in the summer, the only Ruby I knew was from reviewing a children's book, and I didn't know any Rails at all. So I needed to get up to speed, and fast. Michael Hartl's Ruby on Rails Tutorial was my first, and still my favourite, go-to resource.

You can buy a copy of Hartl's tutorial, or read it for free online. If you buy it, you can also get supplementary learning material like solution manuals and screencasts. So far, I've just been working through the online version and skipping the exercises found at the end of each chapter (though I think the exercises are worthwhile, especially if you are not using Rails at work in parallel to learning it).

The coolest thing about this tutorial is the partnership that Hartl set up with Cloud9, a cloud-based development environment. When you're just getting started with something new, it is very helpful to avoid the headaches that inevitably come with setting up your own machine for development. Instead, you can use the tutorial-specific, preconfigured workspace on Cloud9 that leaves out only exactly what Hartl wants to walk you through. It's also really easy to deploy to Heroku from Cloud9, allowing you to easily test your website in production.

The structure of the book is well thought out. You get to make a fully functioning, if simplistic, web app in the first chapter using the automation tools available in Rails.  In the next couple of chapters, some of the key concepts of Rails are introduced and you learn to create static pages.  Chapter 4 delves into some Ruby-specific programming concepts. I'm not sure how well a beginner would be able to program after reading a single chapter, but then again, I'm not sure how good at programming you even have to be to write a small, straightforward Rails app anyway.

After the introductory chapters, the rest of the book is devoted to creating a Twitter-like micro-post website. A lot of the initial focus is on users, which makes sense pedagogically: it allows the learner to focus on the key concepts surrounding information stored in a database with a single model, which makes it a lot less confusing. The downside is that you don't get to the actual micro-posts, the meat of this particular application, until chapter 11. I found myself losing interest by then.

Overall, though, this is a great way to learn Rails, especially if you have some programming background, and probably even without any. The language is clear, direct, simple, and friendly. The examples are carefully designed to introduce as few concepts at a time as possible. Highly recommended.

Connections: Learning Science, Games, and Apprenticeships

I'm working on an education project that isn't ready to announce yet. In so doing, I've been taking another look at learning theory, game-like learning, and apprenticeships. Unsurprisingly, there are many connected ideas.

Close connection / Daniela Hartmann

There's a great book called How People Learn: Brain, Mind, Experience, and School that you can read for free online. The introductory chapter aims to separate speculation from science, summarizing some of the key concepts and practices covered in the rest of the book. Part of this is a research-based list of attributes that good learning environments ought to have:

1. "Schools and classrooms must be learner centered." Consider cultural differences between students, and foster a growth mindset over a fixed mindset.
     
2. "To provide a knowledge-centered classroom environment, attention must be given to what is taught (information, subject matter), why it is taught (understanding), and what competence or mastery looks like." Avoid presenting a large number of disconnected facts, and don't design tests that favour memorization instead of understanding. Doing with understanding is more important than just hands-on doing.
     
3. "Formative assessments—ongoing assessments designed to make students’ thinking visible to both teachers and students—are essential." Use formative assessments to allow students to experiment with and revise their understanding and track their progress.
     
4. "Learning is influenced in fundamental ways by the context in which it takes place." Make the norm of your learning environment one that encourages risk-taking, mistakes, feedback, and revision.

Meanwhile, one of my favourite examples of game-like learning (that is, applying what we know about learning in good games to more traditional forms of education) is NYC public school (grades 6-12) Quest to Learn. Seven principles of learning are outlined in the Q School Design Pack, directly quoted below:

1. It kind of feels like play: Learning experiences are engaging, learner-centered, and organized to support inquiry and creativity.
     
2. Everyone is a participant: A shared culture and practice exists where everyone contributes, which may mean that different students contribute different types of expertise.
     
3. Failure is reframed as iteration: Opportunities exist for students and teachers to learn through failure. All learning experiences should embrace a process of testing and iteration.
     
4. Everything is interconnected: Students can share their work, skill, and knowledge with others across networks, groups, and communities.
     
5. Feedback is immediate and ongoing: Students receive ongoing feedback on their progress against learning and assessment goals.
     
6. Challenge is constant: A “need to know” challenges students to solve a problem whose resources have been placed just out of reach.
     
7. Learning happens by doing: Learning is active and experiential. Students learn by proposing, testing, playing with, and validating theories about the world.

I'm sure you are already seeing the connections. For example, the learner-centred theme appears in both lists, formative assessments to revise thinking is similar to failure reframed as iteration, and context and practical experience are important throughout. Of course, this is no accident: The Institute of Play, the organization behind Quest to Learn and similar schools, have done a lot of careful research into both learning and games. Even without the more obvious game-based approach of Quest to Learn, game-like learning principles are useful to apply to any educational initiative.

Finally, I have also been learning more about apprenticeships, particularly for software developers.  In the introduction of another freely available book, Apprenticeship Patterns, software craftsmanship is defined as a community of practice with a common set of underlying values. Many of the values listed tie again to the ideas described above. For example:

• “An attachment to Carol Dweck’s research, which calls for a ‘growth mindset.’” How People Learn calls for a community in which the growth mindset is the norm.  Failure as iteration shows students that they don't need to 'get it' the first time, but instead work toward mastery.
    
• "A need to always be adapting and changing based on the feedback you get from the world around you." Formative assessment provides opportunity to react to feedback, and in game-like settings feedback is always coming your way.
      
• "A belief that it is better to share what we know than to create scarcity by hoarding it." Game-like learning encourages sharing knowledge broadly.
    
• "A willingness to experiment and be proven wrong." Again related to failure as iteration.
    
• "A strong preference for what Etienne Wenger calls ‘situated learning.’" Communities of practice are one part of Wenger's situated learning theory, which relates to the idea of learning in context and learning by doing.

I'll be delving deeper into a lot of these ideas and seeing how they will apply to the project I'm working on. Perhaps the perspective from the three different angles presented above will help you in your own projects, as well.

Transitioning From Academia to Industry

It seems that 2015 has been a year of change for our family.  My husband got a new job in February, we somewhat suddenly decided to buy a new house down the road over the summer, and I was unsuccessful at getting a permanent teaching position at Carleton.  Rather than becoming a full time student to wrap up my PhD, however, I decided to jump ship to industry.  And so I am currently a developer at Shopify here in Ottawa.

change / Andrea NIgels

When I decided to go to industry, I had my sights on Shopify and only Shopify.  Many of my friends worked there, and I felt like it was the kind of place I could make an impact.  But I was really nervous about interviewing – would they want someone who had been locked away in the ivory tower since her co-op days in undergrad?

Mind you, I have always tried hard to remain 'useful' in the industry sense.  I figured it would keep my teaching relevant if I got the permanent position, and it would help me break back into industry if not.  While I didn't work on any large-scale team projects during my grad school years, I did choose an application-heavy research area and was mindful to maintain good development practices where I could.

Clearly, it worked.  I had interesting projects to talk about during my interviews, code to show on my GitHub, and despite my nerves, I did just fine for the pair programming part.  I showed I had a strong technical base and a boatload of passion.

Once I managed to get hired, I wasn't so nervous about actually starting a few months later.  Which is interesting, since I didn't really know Ruby or Rails, the language and framework I'd be working in.  I suppose I felt confident in my ability to learn new things quickly, and I can't say I was wrong.  I still don't know Rails deeply, but I have been able to learn what I need as I go.  My aforementioned conceptual base along with my enjoyment of the design aspect of programming have made it easier.

And so my transition from academia into industry has been a good one.  It's been nice to keep more regular working hours, and it's been fun learning new technologies.  If I hadn't had 20 months of co-op experience in undergrad, or continued to practice throughout grad school, the switch would have been a lot rougher.  If you're a grad student, strongly consider industry-based internships and make sure to learn the tools of the trade (starting with version control!).  With a strong base and a little confidence, you can make the switch, too!

And as for my PhD, worry not: I am on leave this semester, but I do hope to (slowly) get through it eventually.  You'll have to wait for the "how to work full time while working on your PhD part time" posts a while longer. ;)

Beyond the Code: A Day of Diversity and Inspiration

Monday was a day of inspiration and diverse voices.  It was the second annual Beyond the Code conference in Ottawa, a labour of love for a group of volunteers mostly from Shopify.  As described on the official webpage, "Beyond the Code is a positive, solutions-driven conference for anyone interested in diversifying the technology sector. We’re building a supportive environment for underrepresented groups in tech, to help you build a fulfilling career and feel empowered to make positive changes in your community."

The speaker lineup this year was spectacular, and you can read my lives notes for a bunch of the sessions.

The keynote this year was Hilary Mason, lover of data, cheeseburgers, and apparently Red Bull pancakes.  Mason is a self-confessed optimist: she is a believer in technical progress and in the underlying goodness of humanity.  In her talk, she focused on technology, organizations, and people.  Some of the biggest takeaways for me included that data is exciting, machines are getting more creative, and people aren't fungible.

My job at the conference was to introduce workshop speakers and see if they needed any help.  The one I participated in most was a design thinking workshop lead by Barbara Spanton of Macadamian.  It was a really well organized workshop that had participants work through each stage of design thinking to design a new wallet for their partners.  The prototypes everyone created were really quite good!

All the other speakers I saw were equally as awesome – like Kelly Shearon, who taught us how to better value the "less technical" roles on our teams, Safia Abdalla, who shared her insights on how to effectively teach, and Jen Myers, who shared her wisdom on how to be awesome.  The closing panel of the conference, however, was a perfect way to wrap up the day.

Lead by Cate Huston, the panel featured Omosola Odetunde, Kat Li, Tai Dickerson, Lori Olson, and Marco Rogers.  The coolest thing about it was that it did not cover only women as a diversity issue, but also issues of ethnicity, sexuality, gender, etc.  Cate did a really good job of starting where most panels end, and pushing discussion of the issues further than usual.  For example, instead of the conversation devolving to be all about the pipeline, panellists talked about not just hiring, but retention as well.

Again, you can check out my live notes for the conference, which include quite a bit on most of these talks (only the workshop is missing).  Be sure to watch for next year's Beyond the Code, which I hear might even have a new location.  Hope to see you there!

HLF2015 / Fred Brooks on Software Engineers and Teams

This blog post originates from the Heidelberg Laureate Forum Blog. The 3rd Heidelberg Laureate Forum is dedicated to mathematics and computer sciences, and takes place August 23-28, 2015. Abel, Fields, Turing and Nevanlinna Laureates will join the forum and meet 200 selected international young researchers.

It has been over a week since the end of HLF, and I've been settling back into my life as a software developer at Shopify in Ottawa, Canada.  I often find myself thinking back to what I consider to be an epic conversation with laureate Fred Brooks.  With my husband and fellow blogger, Andrew Carmichael, I interviewed Brooks in what was a joint effort.  Brooks was kind enough to spend over an hour with us.  Since I can't possibly share everything he said in one blog post, I've put together a transcript that you can read online, and I've picked a few tidbits to share here.

Because Andrew and I both work as software developers, we wanted to take a more practical, industry-driven approach to our discussion with Brooks.  For example, we asked early on what makes a programmer great.  At first Brooks simply said "too hard" in his patient southern accent with a smile on his face.  He then explained that being able to visualize complex geometric constructs was a pretty good indicator of whether beginners would be good programmers.  We also discussed the importance of teamwork:

I once worked with a colleague when I was a summer intern… this fellow was extremely difficult to get along with.  He was our supervisor to us two interns, and that was fine, but he could not get along with any other colleagues in the room.  His boss remarked one day to the two of us privately, “You know, if we could put him in a box with two slots, one to put problems in and one to get answers out, it would be great!” [laughter] And he was easily the sharpest person in the room, but I was not surprised to learn three years later that when they had a reduction, he was the first one let go in that group. ... We used to get fractional distillation of the nerds [laughter]. ... Now we’re drawing from a larger population.

We also wondered what companies could do to grow recent graduates into effective professional programmers.  For Brooks, the key is apprenticeships.

Only talk to me about the theory when I’ve encountered the problems.  I’m willing to listen to your war stories, but I need to be able to bring from my own background my own war stories to make what you say to me relevant. 

Therefore I would do rotational mini-projects, and I would do rotation definitely so that...well, you know, the same thing they do with residents in medical school.  Go try surgery, go try pediatrics, go try psychiatry.  It will make you in general a better physician in all respects. 

I’m not interested in making people into better programmers, I’m interested in making people better software engineers.

Once a programmer is ready to join a team, there are many skills to learn.  For example, estimating how long software projects will take is a very difficult task for teams.  When we asked about what could be done about it, Brooks gave us this great quote:

One of my friends who was an electrical engineer on the 360 project said there are promising engineers, and there are old engineers, but there are not promising old engineers [laughter] - they don’t make promises!

Of course, how well a team can produce estimates is not the only indicator of how successful they will be (or perhaps not an indicator at all).  We asked Brooks what he would do if he could spend one day with our teams at work if he had to determine whether we would succeed or fail.

Talk to a lot of people [laughter].  One of the things I’d be looking for is how consistent is their view of the goals.  One is: how highly do they respect each other? One I would be looking for is: do they believe in the goals, or is it something they were assigned and not sure they’re going to be able to do anyway? One is: are they excited about the goals? “Yeah, this is going to a contribution, it’s going to be a great system, and I’d be glad to be part of this team!” 

One question I’d listen for, but my presence would interfere, is when they chat, do they chat about work, or last night’s TV? Which has to do with: are they really excited about what they are doing, or are they just turning the crank? 

Purely subjective.

This is just a taste of our interview.  Our conversation took many different directions, winding through topics like education and Grace Hopper.  We were very grateful, however, to be able to bring all kinds of practical advice and insights to our team at work.  Again, check out the transcription of the interview if you want to see more.

The basics of contributing to open source with GitHub / GHC14

My first session after the plenary opener was about how to use GitHub, presented by John Britton.  I was interested in getting some better insight into effective use of Git, a distributed version control system, so I could eventually move some of my own projects to my (thus far unused) GitHub account.

GitHub Office / Ben Scholzen 

Although I did find the session useful, it unfortunately moved a bit too fast and with demos that were hard to make out on the big screen due to the high resolution of the image.  I tried to keep up while trying things out, but quickly found myself lost.  (Funnily enough, it was when John started demoing Git from the command line that I was really able to get a handle on things.)  I'll share some of trickier bits I was able to figure out during the session along with my own research below.

I admittedly still get confused by Git since I haven't used it for any of my own projects.  The key thing to sort out is the workflow, which is different from version control systems like CVS and SVN:

• The first step in making changes to an existing project is to clone it.  This fetches a repository that you don't yet have locally.
• Next, you can checkout a new branch, giving it a name and activating it (or, if the branch already exists, just switch to it).  There is some useful discussion about the difference between clone and checkout here.
• After making some changes to files or adding new ones, you can use git status to review those changes.
• If there's a new file that you want to be tracked by Git, you need to add it.
• When ready, you can commit your current set of changes to the repository, creating a snapshot of sorts.
• Finally, when you are ready to send your local snapshot to your Git repository, you push.

Another issue that confused me terribly is the idea of a pull request.  GitHub lets you "fork" somebody else's project, which basically means making a branch within your own GitHub account.  You can work on your forked project and make whatever changes you want without affecting the original owner's project or requiring their permission. Then, you can make a pull request.  The name of the action suggests to me that you are requesting to pull changes from somebody else's project, but in fact you are requesting that the owner of a project pull your changes.

If you aren't familiar with branching and merging, this article might be useful.  You might also like Code School's interactive lessons on GitHub to get a feel for the system overall.

One last thing: if you are a student, you must check out this recently announced student pack, which includes access to a free micro account on GitHub (this lets you have private repositories).  Awesome!!

How Beyond the Code Attendees Found Their Spark with Anita's Quilt

Recently, Shopify put on a super cool conference called Beyond the Code.  Hosted at the Ottawa Convention Centre, the event's main goal was to highlight the role of women in technology.  All types of folks were there,  from devs to designers — and the audience was more than half female!

I was lucky enough to run a lunchtime workshop called Find Your Spark with Anita's Quilt.  Some of my fellow Quilters developed this workshop, so I had a good base to start from.  The general layout we used was to sort people into tables as they came in (we used chocolates!), then have them introduce themselves to their table mates, pick and read a story from the Find Your Spark! page, and  talk about the stories using the discussion questions we provided them (now also on the Find Your Spark! page).  After the discussion, we had a few tables share their biggest takeaways (there wasn't enough time to go through all tables let alone all questions).

It was an enjoyable way to spend lunch and meet some new people, but the thing I was most excited for was to hear what the participants actually got out of reading the stories.  I have been working hard to curate a lot of the great content on Anita's Quilt, so of course I wanted to know whether it has been meaningful and even useful to readers.

I was really impressed with the insights that came out of the discussion.  A few key issues were brought up:

• One group noticed the prevalence of the imposter syndrome, that feeling you get that makes you think you don't deserve to be where you are and that everybody's going to find out any day now.
• Another group pointed out that a lot of the stories are about how somebody corrected course when their life got back on track.  Realizing this allows the reader to see how others did in case they ever face the same situation.
• The fear of failure was a big theme.  That lead to discussion on the importance of a support network of friends, family, and mentors/sponsors that can help you lose the fear of failing.
• The last group brought up the issue of the kind of language women tend to use, and how it often portrays less confidence, or attributes success to factors outside of their own good work.

It's almost as though we went through a checklist of common issues facing women in tech!

If all this sounds intriguing to you, or you could just use a really good story to get inspired, be sure to check out the Anita's Quilt Story Campaigns archive,  or follow the Find Your Spark! model to choose a story and think about the discussion questions.  Let me know what you get out of the stories you read!

Reflections on My First Year of Teaching

I did it.  I survived my first year of teaching.  Exams are marked, and grades are submitted.  And while I still have students concerned about their results to meet with, I am finally able to breathe and spend some time reflecting on my experience.

[image via WikiMedia]

Over the two semesters of my first year of teaching, I taught five courses, mostly for the first time.  I had more than 1000 students and around 30 TAs.  I answered countless emails and forum posts.  I assigned 32 assignments.  I gave three midterms and 7 quizzes.  I made hundreds of slides, sometimes based off of existing content, and sometimes my own.

Needless to say, a large part of this job is management — of both time and people.

It was challenging at times, there is no doubt about that.  I had to relearn a lot of the material I was teaching.  This lead to many evenings spent on preparation, especially during second semester when I had three courses I hadn't taught before.  There were times I didn't get as far as I wanted, and fumbled in class.  There were times I wanted to crawl in a hole and stay there.  But I took comfort in knowing that I would never have to teach three courses for the first time ever again.

My students were generally forgiving.  Actually, my students were amazing.  They participated in class and thanked me for my engaging teaching style.  They sent me really nice comments in email.

Sure, not all students loved me.  My style didn't suit all of them, or maybe my slip-ups frustrated them.  Understandable.  Some probably didn't want to put in the effort to get the results they wanted.  I wish I could have inspired those ones.  Maybe some I did.

The thing that makes me feel the most energized of all is thinking about how to improve for next year.  I know I need to take a different approach to teaching my arts and social science students Python.  I know I need to switch up some of the examples for my Processing class and come up with more small examples. I need to adjust how I use the animation libraries with Racket and have some ideas for how to improve the course content overall.  There's lots of talk on what to do with our second first-year programming course, and I've had fun thinking about whether we should do it in C/C++ with Think Like a Programmer.  And of course there are a million little things to get better at that I can't possibly list here.

Most of all, this past year has confirmed that teaching is what I was meant to do, and I am so thrilled to be able to come back and do it again for another year.

Motherhood, Tech, and Leaning In With Marissa Mayer

Recently, I happened to start looking at some of the stories featured on the new Lean In website and came across Marissa Mayer's.  For all the interest and controversy she's drummed up in the news lately, I quite liked hearing her perspective on joining Yahoo! when expecting a baby.

Fortune Most Powerful Women Dinner With Marissa Mayer / Fortune Live Media

Although she'd received offers like that of Yahoo!'s before, this time was different.  The company was a perfect fit for her experience.  But as she says, "...it wasn’t a foregone conclusion that I would or could make it work when I got that first phone call. At the time, I was pregnant, and I was thrilled."

Motherhood is an oft-discussed topic for women in tech (and probably women everywhere).  It can be difficult to be a pregnant woman among many men who don't necessarily understand what comes with that.  Equally daunting is the prospect of taking time off for maternity leave when you'd be one of the few to do that in your company or perhaps in your position.  (If there were more women in the field, it wouldn't seem like an uncommon occurrence.)

Mayer had been looking forward to a six-month maternity leave with Google, way longer than most Americans can even dream of.  By taking the CEO job, she would cut her leave down to almost nothing.  "The responsibilities were too big, and time was of the essence—it just wouldn’t be fair to the company, the employees, the board, or the shareholders for me to be in the role, but out for an extended period of time."

Did she find that motherhood has hurt her ability to be CEO?

I’ve come to realize that being a mother makes me a better executive, because motherhood forces prioritization. Being a mom gives you so much more clarity on what is important. I’m very close to my own mother; she has always been my most important role model. I’m grateful to her and to my father for a lifetime of their love, attention, teaching and sacrifice. Over the past five short months, my appreciation has grown for all parents, especially those balancing work obligations, because I know they have that same clarity of dedication and purpose.

Clearly, it's not an issue.  Granted, she has much money at her disposal to help keep her personal priorities.  However, families around the world have been figuring out many different ways to make it work for many years.  Money might make some things easier but it's not the only answer.

So can we stop bringing in the pregnancy and motherhood issue into discussions of women in tech (and other) companies? It's not like we ever do the same thing for men with young families.

Got What it Takes to Be a Technical Co-founder? Here's an Opportunity for You!

Two recent Y Combinator graduates contacted me recently in an effort to recruit a female technical co-founder for their startup.  Although any awesome engineers would be welcome in their company, they believe that women are likely to better understand what other women would want in their fashion-focused product.  This is such a great example of why we need more women in tech — why should only men design products intended for women?

Here's a blurb about their company and info about who they are looking for.  If you think you've got what it takes to be a technical co-founder, I hope you'll give this opportunity consideration!

Join team StyleUp! A Winter 2013 Y Combinator-backed company, StyleUp is a Pandora for fashion. We are influencing the way people shop and get dressed every day and are looking to expand our engineering team. We are looking for part-time as well as full-time candidates. Tasks include (but are certainly not limited to) creating new product features, responding to customer feedback, and working closely with the StyleUp CEO, Kendall, a former Conde Nast fashion editor and MIT Sloan MBA '13, to shape the product vision and road map.
At 20% month-over-month user growth, the StyleUp system needs monitoring and performance improvement to ensure the best service and experience for our users. This involves writing code up and down the stack -- from database query tuning to front-end javascript algorithms. Having a performance-first mindset to all new features is a must.

If you are scrappy and creative, love working with fun people and get stuff done fast, we want to talk to you! Please send your resume to kendall@thestyleup.com.

A little about the technology stack:

• Python/Django stack with a MySQL database
• Front end using Bootstrap for CSS; jQuery/jQuery UI
• Hosted on Amazon EC2; deployment in Fabric and Boto (EC2)

What We're Not Doing to Tackle the Women in Tech Issue

Venture Beat recently ran an article about tackling tech's gender problem the right way (according to them, by teaching women to code). Part of the article discusses how initiatives like Hackbright Academy (a 10 week all-female programming boot camp), while positive, are not a long term fix.

 

A little light reading about women in computing! / coleypauline

From the article:

So while we wait to tackle the root of the gendered-tech problem (education of girls beginning before they enter school), decades are passing and tech is becoming more gender biased, not less. In a sense, Hackbright and its ilk are letting motivated, smart women cut the line, perhaps helping to take a few years off the depressingly long curve of qualified women engineers over time.

But the quick fix isn’t the ultimate solution. As Fernandez himself pointed out in a recent blog post, the learn-to-code movement is meeting a very immediate need and fixing a sudden engineer shortage, but it’s not creating a stable, nurturing culture of thoughtful, experienced programmers.

What is the ultimate solution? I don't know, but I often find myself frustrated by the fact that, in many cases, we know something about what works, but don't implement it.

As just one example, the National Center for Women & Information Technology has a wonderful set of resources that both gives insight into the issue and offers solutions.  Two of my favourite techniques that can be used in undergraduate classes are pair programming and peer-led team learning.  These are proven to help retain women and also benefit men.  So why do I see these approaches used so seldomly in formal school settings?

I'm pretty sure that a major part of my life's work is going to be continuing to tackling this issue in high schools and universities.  Bonus if it's connected to a paying job!  If we're lucky, I and everyone else working on this won't have to be at it for too long before there is no longer an issue.  Here's hoping!

Proof Overtime Is Bad

I am against overtime. I do as little of it as possible. And now I have proof that this philosophy actually makes sense!

The Sleeping Geek Kitten - Angers - / Nathonline-Beta

Before any potential future employers find this and take my resume off the pile, let me explain.  Knowing how long I can work before getting tired is important to me. If I go too long, then I'm likely to just make things worse.  Plus, if I know I only have a set amount of time to get things done, I can focus better - there is no later.  The standard 8 or 9 hour day seems to work perfectly well for me.

That's not to say that I'm not willing to put in some extra time around a deadline, of course.  I have stayed late a few times during my co-op terms and I've worked into the evening on school stuff more than once (though I've only ever done one all-nighter, and it wasn't even strictly necessary).  I just ensure this is very much the exception and not the norm.

So, back to this proof I mentioned.  The IGDA has a great article on why perpetual crunch modes just don't work.  Most other industries started figuring this out 100 years ago (hence why the 40 hour work week is fairly standard).  Research literally proves that after a certain number of hours worked in a single week, output goes down when compared to a more regular work week.  Working more just doesn't pay.

High tech can be a brutal field when it comes to overtime expectations.  My strategy? Don't make working longer a precedent.  If you do, then that amount of work will be expected of you.  But, of course, the more you work long hours, the less you'll do over time, making you want to work longer to make up for it, making you accomplish less... and so it goes...

Go Lean, Go Agile: Are We There Yet? (GHC12)

The concept of agile development has always fascinated me, particularly because I haven't had the opportunity yet to work on an agile team. (This despite having done five 4-month co-op terms during my undergrad.)  So, the panel presentation on lean and agile development at GHC12 was definitely on my list.

The panellists included Mario Moreira (an Agile and Configuration Management industry expert), Rae Wang (Senior Program Manager at Microsoft currently working in Exchange Online), Jill Wetzler (lead software developer and scrum master at salesforce.com), and Janet Swedal (Senior Director in the Technology organization for Thomson Reuters).  Their experience and insight was amazing.

The big theme for the talk was the challenges of adopting agile in your team.  Sometimes teams really have no choice but to go agile given the frequency of releases to customers and opportunities for feedback.  But it's not easy to implement the change; it requires an all-in buy-in from team members to the executives, for example.

The speakers explained some of the benefits of going agile: agile development encourages incremental / iterative development, adaptive planning, rapid and flexible response to change, etc… The collaboration and communication the methodology encourages is seen by some as the number one benefit.  In fact, research has shown that the communication differences between men and women all but disappear in agile teams.

An interesting issue brought up through audience questioning was that of technical debt. How do you ensure that bugs are fixed and code gets refactored when needed?  The speakers suggest taking a methodological approach: have a refactoring strategy at the beginning of a project, and turn this work into a technical story.  Refactoring and bug fixing can also be part of the 'done' criteria of a particular story.  You can also take an entire sprint to work on bugs, or rotate resources to fix bugs.  You have to make it a priority before you end up with a mountain of debt.

I know a few people who have worked on agile teams.  I found this presentation very interesting because I could see why some of the problems they were complaining about might be showing up.  For instance, one team didn't appear to be taking technical debt seriously enough.  I also wondered if all the teams I know about were actually well suited to being agile (another common thread of discussion in the presentation).  It seems that the way they divide work might be contributing to lower quality output for the sake of being agile, and it's not clear whether they work in a particularly iterative way.

But all this is mostly speculation, since I am not entirely familiar with the methodology yet.  When I get a chance, I look forward to reading up more on agile, and potentially trying to use it in my own thesis work as well as any team projects I am involved with in the future.