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.

Read more

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.

Read more

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)

Read more

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!

Read more

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...

Read more

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.

Read more

Bit by Bit: A Young Woman's Guide to Entering and Succeeding in High Tech Careers

A new book all about high tech careers for women has finally found its way onto Amazon! I was interviewed for this book (Bit by Bit: A Young Woman's Guide to Entering and Succeeding in High Tech Careers), along with many other awesome women (some of whom I know).

I haven't had the chance to read my copy yet, but I will post a review when I do.  In the meantime, if you or someone you know has even considered getting into high tech, I recommend picking it up yourself.  In addition to the interviews, the book explains a few of the various job roles that are out there.  It will also give you the top ten reason you should consider a career in tech, and what skills you need to get there.

Read more

Startup Weekend... In Book Form!

I've wondered before if I'd like being an entrepreneur.  I've come up with a few ideas that could get me started.  I have even entered a social-good version of a business case competition (and walked away a finalist).  But I want to know more before making the plunge.  So I got a copy of the book Startup Weekend: How to Take a Company from Concept to Creation in 54 Hours.

What's in the Book

The book's introduction walks the reader through the history of Startup Weekend, emphasizing the need for trust among peers.  Without trust, a startup is impossible, given the risks involved.

The first real chapter discusses action-based networking, and why traditional networking events (complete with standing around sipping wine) aren't terribly useful.  You need to work together with people you don't normally meet to get the most useful contacts.

Next, the book covers how to effectively pitch your idea and recruit your team members.  In 60 seconds, you need to say who you are, the problem you want to solve, your proposed solution, and what help you will need.

The third chapter is about experiential education, and is where the bulk of what you actually do at a Startup Weekend is described.  The emphasis on "learning by doing" really entices the reader to want to attend the event in person.

The last two chapters are about the startup business model and the startup ecosystem.  They briefly touch on some of the key mistakes that entrepreneurs make, and the steps an entrepreneur can take from deciding to make the startup leap to getting funding to, if they're lucky, IPO and Fortune 500.

My Take

Looking back at what the book actually covers, I have to think I must have got a lot out of it.  But, to be honest, I didn't get what I was hoping for.

The book's prose had a style that said a lot of general things without details.  Part of the reason for this is the inclusion of the many little stories woven throughout.  I do like that the stories give specific examples of the kinds of startups people were working on, and they did help build excitement about attending the weekend event.  But they also caused what specific advice there was to get lost easily in the text.

Something the book would have greatly benefited from is a concrete summary list of the information contained in each chapter.  Something that the reader could easily refer back to as they attempted their own startup.

In the end, the book is not terribly useful as a reference guide on startups.  It does drum up excitement about attending a Startup Weekend, and it does touch on some of the elements of entrepreneurship without going into detail.

Maybe that was its purpose, in which case it succeeds in its mission.  But still, I leave wishing for more.  I am not sure I am any closer to my answer of whether I want to be an entrepreneur.

Read more

Lecturing for a First Year Programming Class

I gave a guest lecture at Carleton last week. It was for the first programming class that both computer science and non-major students take, taught using Processing.  I seized the opportunity to use some of my somewhat less conventional techniques and "lecture" as little as I could.

50 minutes at a time by I, Timmy

I was lucky to be basing my lecture off of a very solid set of notes.  The professor who put these together taught me my very first programming class back in 2002.  (I still have a printed and bound copy of his notes from that class.)  In my guest lecture, I covered the first part of Chapter 8: Shared Data.

This is how I prepared for the class:

• First I glanced over the notes and then started to type up the source code described within.
• While I wrote out the code, I thought about what might be the best order to present it during class, and in what chunks.  (My order did differ from the order in the notes, which makes sense - written and oral communication are not the same thing.)  I saved individual files as I went along so that each file showed a bit more progress.
• I went through the notes again and kept a detailed outline of what I wanted to explain and what I wanted to get the class to do.
• I used my outline to create some simple slides (mostly images to help explain concepts) and some printouts I wanted to make for a couple of demonstrations.
• Finally, I made a much briefer version of the outline that I could refer to during the actual class so I didn't get lost (especially useful given how sparse my slides are).

This is actually the first time I used this exact method to prepare, but I think it really helped me get familiar with the content and figure out the best way to present it. I will definitely do it again.

Here are some of the interesting techniques I used that made my lecture a lot more like a tutorial:

• I explained a concept to students and then asked them to implement it in the code (I had them download a file with an initial bit of code to start with, and offered the individual progressive files in case they could not finish the task).
• I had students read code and explain to me what was going on.
• I had students hold signs and point to each other to emphasize how variables can refer to the same data and the implications of doing so.  I gave new signs or had them destroy the current ones to illustrate changing the data.
• I asked the class many questions and sometimes lead them to ask a question they would be able to answer by playing with code rather than hearing it from me.

I was very happy with how the class turned out.  It was risky doing it this way given that I had not been their instructor since the beginning of the term.  This was also a smaller class with about 30 people present, so I'm not sure how well these things will work with a larger group (I believe it could work, but I have not yet had the opportunity to try).

What kinds of techniques do you use in first year programming lectures?

Read more

Life as a Professor

Systers just started a 'best of' blog that highlights useful conversations that have happened on the popular mailing list for technical women.  The first post, Life as a Professor, is all about what being a professor is like, particularly in the work-life balance sense.

 

Balancing lady by orangebrompton

I find the responses either depressing or encouraging. One thing's for sure: it's not a 9-5 job. As one person said,"It’s a huge part of your life even when you aren’t in the classroom or lab." Whether that's good or bad depends on the individual (after all, I'm always thinking about teaching, learning, and outreach, so if you love what you do you may not want to leave it completely at work).

For me, the words of wisdom in that post solidify that I would be much happier as an instructor without the added pressure of running a research lab.  Plus, if I don't want to be a professor, I can skip that whole post-doc phase, which suits me just fine.

Do check out the post if you are at all considering an academic career.

Read more

You Will Fail to Have a Great Career — Unless...

Larry Smith told the TEDxUW (University of Waterloo) audience that they will fail to have a great career.  After all, there are ever so many excuses that crop up to justify why you can't follow your passion.  Alas, there is no such thing as a "good" career according to Larry, so if you try to settle for one, you'll just end up with one of those terrible, soul-sucking jobs.  Unless...

(video link)

Unless.

Read more

What if you want a PhD but don't plan to do research after?

I was thinking the other day about the different reasons a person might want to get a PhD, and I wondered if those who weren't necessarily intending to be researchers when they were done would be valued as highly during their grad school years as those who did.

 

Academic by tim ellis 

I suppose the most common reason to get a PhD is because you want to do research, either as a professor in an academic setting or at a research lab (industry or otherwise).  After all, this is what the actual PhD work teaches you more than anything else: how to do research.  Sure, there are opportunities to improve and practice your teaching as well, but it's certainly not required.  Some people don't even want to be TA's because of the time it takes away from their main task.

But is it not also perfectly legitimate to get a PhD because you simply want to learn more about something? To have the opportunity for academic and other experiences that you'd never have otherwise? Or maybe you want to work on a particular problem not because you love the world of research in and of itself, but because that problem is something you are passionate about solving.

Perhaps you want to just teach when you are done.  Sure, you might not need more than a Masters to do that in a university setting, but the reasons above may be enough to take it that step further.  Or maybe you want to continue working on solving that problem you started working on as a business venture or within another company.  Maybe you see the solution as something that can make the world a better place.

Are students whose primary post-grad goals do not include research less valued during their PhD, assuming they have fairly good (but not top) research ability combined with other excellent qualities (such as leadership, etc)? Do they get less scholarships and recognition? Do they suffer more because of the Publish or Perish mantra?

I don't know the answers, but while I would like to think this wouldn't be the case I suspect that it could easily be.  Does it matter? What are your thoughts?

Read more

Do I Want to Be an Entrepreneur?

Even though it's early, I have been starting to think about what I want to do when I graduate. Teaching is high up there if I can find a good local job doing it, but I have also been toying with the idea of starting something of my own.  But, at this point, I can't quite figure out if I actually want to be an entrepreneur.

Lemonade, anyone? by trippinlarry

Pros: I would be able to combine all of my current passions in a creative way: teaching, outreach, and educational games.  There are several areas of opportunity, from consulting to application development.

Cons: Entrepreneurship takes a lot of time! From what I can see you have to be willing to put in many, many hours, and our lifestyle has been more about balance than working much more than a regular work week.  Plus, there's that whole having a baby thing to throw into the mix.

Just for fun I took this Entrepreneurialist Culture Quotient Test that I found through a friend.  I scored somewhere in between being suited for a regular job and entrepreneurialism - perhaps, it suggested, I should consider a partner.  Hmm...

The pros, cons, and good characteristics to have (written by the same person as the test above) don't seem to make the picture any clearer.  There are as many things that excite me as scare me on these lists.

Luckily, I don't have to decide yet.  Over the next little while, I'm trying to make use of some of the great resources friends have shared to learn more and more about the possibilities.  Before I'm done my PhD I'd like to take advantage of a program like Lead to Win, or perhaps a less "actually start a business when you're done" version of it.  Maybe some business idea competitions (like the Nicol Challenge I participated in this year) would be a good place to test the waters.

Anyway, here are some of the resources I have found so far.  If you have any others, or any advice you can give me, please do share in the comments!

• AVC: musings of a VC in NYC (blog)
• Lean Startup Wiki (online resource)
• LaunchBit Startup Guide (online resource)
• Startup Weekend (events and associated book)
• A Good Hard Kick in the Ass: Basic Training for Entrepreneurs (book)
• Startup from the Ground Up: Practical Insights for Transforming an Idea into a Business (book)
  

Read more

CRA-W Grad Cohort: Non-academic Career Paths

Becoming a professor isn't the only option after getting your PhD.  There are plenty of non-academic options in both research and non-research areas.  Take a look at the following advice from the 2011 CRA-W Grad Cohort and consider your options.

Options

• Software/hardware or services companies
• Start-ups
• Research labs
• Other industries (such as banking, insurance, telecom, etc)

Your thesis may need to be shaped to suit industry if you are considering any of these options.  It is also important to do internships for both the experience and to see what kinds of positions you might be interested in.

What Might Get You Hired

• Having a PhD means you are intelligent, analytic, are persistent, and can work on a big project
• Your specific skills might be desirable or just these characteristics

Things to Consider When Choosing Research vs. Non-research

• Prototyping vs. industry-quality code
• Creative ideas vs. coding
• Are you interested in well-defined goals and project deliverables? Deep technical support and debugging? Working on deep research problems?
• Publishing vs. patenting
• Do you want the option of returning to academia?
• What pace of career growth do you prefer? Hierarchies in research labs are pretty flat - expect more promotions in non-research

Things to Consider When Choosing Academic vs. Non-academic

• Unlike academia, there is a wide variety of how jobs work in industry
• Network to find out the culture of various options
• If you want flexibility to go in and out of research, consider a company with research arms so you can switch groups (but note that it can be hard to go from R&D to research unless you publish)

Preparing for Non-academic Careers

• Try to do at least one internship:
• experience counts a lot
• adds credibility to real-world connections with your thesis
• gets you contacts
• Build your professional network, make yourself visible
• Build a list of references
• Keep your web presence up-to-date (such as a website with your publications)

Becoming a Leader

• Increase your technical breadth and depth
• Determine what your research brand will be
• Up your credentials (patents, publications, awards)
• Hone your communication skills (be correct, concise, clear, and able to match form and style to the occasion)
• Build your basic skills: business sense, prioritization, analytic and negotiation skills, leading without power
• Have good character

Do you have specific advice for choosing between academia and industry, and how to prepare for the latter?

Read more

The Nicol Challenge and My Latest Idea for Girls, Computer Science, and Games

On a whim, I entered the Carleton Nicol Challenge and was thrilled to make it to the Top 8.  I pitched my idea in front of a panel of judges (apparently in Dragon's Den fashion, not that I watch the show).  I didn't make the top three, but am perfectly happy with this first attempt at any sort of entrepreneurial competition.

My pitch was titled Girls and Computer Science: Increasing Interest Through Stories and Games.  It's similar in some ways to our recent Imagine Cup game, Gram's House (which sadly did not make it past round one).  However, there are some key differences, such as focusing on a novel with an accompanying app rather than a stand-alone game.

There are many outreach initiatives, and the main themes that appear in most include ensuring girls and women know what computer science actually is (e.g. it is not about learning how to use software), that life in computer science is not what the stereotype portrays, and that you can make a difference in society with computing.

In my pitch, I proposed the creation of a mobile app / novel combo designed to tell a compelling story about computing through story and games, thus encouraging middle and early high school girls to see the field in new light.

The most important aspect of this proposal is the story told to the users.  This story must be targeted to the audience of 12-15 year old girls and paint a positive image of computer science.  The girls must be able to relate to at least one of the main characters so they can imagine themselves in their shoes.  In other words, the story should encourage the girls to project their identities into those of computer science students, a concept explained by video games and learning expert James Paul Gee.  If done right, these identities can transcend into the real world and help counteract the many reasons that girls are not entering the field.

While the story helps with the image problem the field of computer science faces, it doesn’t necessarily show the readers specifically what computer science is.

For this reason, mini-games relating to computer science problems will be introduced throughout the story via a QR code that can be scanned by a mobile device.  These games will be closely related to the problems that the main characters have to solve for homework and for personal endeavours outside of class.  On the surface they will appear to be puzzle games (one of the most popular game genres for middle school females according to research), but of course a meaningful connection to real computer science theory will be made, showing that computer science problems are actually fun and interesting.

Another key aspect is to emphasize that computer science can be used for social good.  The focus is not on the computer or programming itself, but on making a difference with these tools.  Research has shown that girls do indeed care about social good, so these games are an opportunity to connect the technical aspects with the impact they can make.

During the question period of my pitch, I was asked how much money I would need to get this going.  The truth is that what I really need is time.  I have all the tools and resources to accomplish this, but no time to do it.  Maybe it can be one of my post-grad projects.  On the other hand, if anyone out there wants to collaborate with me very closely to get this done sooner, I'd love to hear from you. ;)

Read more

Patty Azzarello on Succeeding While Loving Life

The Anita Borg Institute for Women and Technology (ABI for short) Board of Advisers meeting last week was really inspirational.  On the morning of the second day, we were treated to a talk by Patty Azzarello based on her new book Rise: How to be Really Successful at Work AND Like Your Life.  Even though the focus was on life in industry, I felt like there was a lot of advice I could apply to my own situation.

Business girl by Éole

The main theme was that "just working hard doesn't work."  In your career, it's easy to think that it's all about your expertise.  And it kind of is... at the beginning.  But then there's more to it.

It's not about politics, promotions, or raises — it's about how you approach your work.

There are three main things you should be doing / thinking about: aim to do better (have more impact), look better (be visible but not annoying), and connect better (get support).  Next are some tidbits on each of these.

Do Better

• Be less busy.  Nobody has motivation to make you less busy other than you.
• Know what the business values.
• Be wary of the trap of being a workhorse.  Although it might feel like the right thing, the only reward is more work. (Incidentally, this is one reason I don't believe in working overtime regularly.)
• Rise above the work and learn to delegate.
• Create processes and systems.
• Defend your time and be ruthless about priorities.
• Evolve your job in order to add business value, and change it to suit you better.  The better you make your career, the more value you will end up giving your company.

Look Better

• Don't be invisible, but never put politics before getting results.
• You don't need to have a big personality to succeed.  Humility is ok.  Build credibility as you.
• People with high credibility get more done, and are asked fewer (potentially dumb!) questions.
• Don't educate others about what you do. Instead, use the language of the business, and connect the dots to your own work for those you speak to.
• You have a brand that is defined by others. Ask yourself if it's what you want.  It should show who you are, why you are good, and what you care about.  A package of skills is boring.  (Patty talks about brand-building on her blog.)

Connect Better

• The biggest impact on your career will come from having a mentor.
• Don't be afraid to get help.  Build your team and never struggle alone.
• Build relationships.
• When networking, give more than you take, meet people for a reason, and keep in touch with people you know.  (During the talk I mentioned how I use Facebook to do this when someone asked how to find the time to keep in touch.)
• Schedule 30 minutes a month to send personal emails to your contacts.
• Get on "the list."  There is always a list.  Find it and get on it.

---

Want more? I definitely recommend picking up the book.  I'll be reading it myself, since Patty was kind enough to give us all a copy.  There is much more detail and lots of great stories in there, so it's totally worth the purchase.

Read more

Traditional and Software Architects are Even Closer than You Think

I received a comment on Is a Software Architect Worthy of the Name? via email from Lourens Veen, a software architect for a project at the University of Amsterdam, where he is helping build a biodiversity information system.  He wrote about how much more similar software and traditional architects are than what I originally laid out.  I really liked his email, and he gave me permission to repost his comment here.

My job is to look at how the system we build fits into its environment. In my case, the lead engineers are similar to the structural engineers that you have in building architecture. Their job is to ensure that the things we design can actually be built and maintained by our programmers. What I do is figure out how it interacts with other systems, and with its users, system-wide and in the long term. My job is to look ahead and think about what the users are likely to want in a few years time. Of course I have no hope of doing so in detail (typically, users don't even know what they want for themselves, right now), but I can hopefully see well enough where things are going to make sure that the core of the system won't need to be recreated from scratch anytime soon. I think building architects have a similar role: they design a building for a client, but also need to take into account that the building will still be there decades into the future, and still needs to earn its keep then.

So, I think that building architects and software architects have even more in common than what you described. I even think there is an equivalent to that other job of a building architect: making it beautiful. Of course software has no physical embodiment, so it has no physical beauty (artful syntax highlighting excepted :-)), but its design can still be just _right_. It's hard to define what makes a design right, but a good software architect recognises when that is the case, just like a building architect recognises a good-looking building. Linus Torvalds (original author and architect of the Linux kernel) even calls it "taste".

As an added bonus, Lourens ended his email with a little bit about why he loves computer science so much in general.  I wanted to include it here because the point about puzzles is so similar to what I love, too.

The attraction of computer science to me has always been the solving-a-puzzle aspect, and while software architecture is certainly not the most technical area of computer science, getting current user requirements, potential future requirements, current technology and future technological developments all covered in a single design is usually a very interesting puzzle. And a rewarding one too, if you manage to give the users a system that satisfies their needs now and into the future.

Really makes me want to be a software architect myself one day! I suppose if I do end up in industry at some point (and I hope I do, at least during internships), this is something to explore.  Thanks again for letting me share your perspective, Lourens!

Read more

Is a Software Architect Worthy of the Name?

I have a friend who is an architect (the kind that designs buildings instead of software).  I was reminded recently of a conversation my husband and I had with him a while back that was basically about whether you could really be called an architect when you designed software.  It didn't really make any sense to him, possibly in part because of the intangible nature of the end product.


The Architect's Hand by George L Smyth

I was reminded because of a sentence I read in a text book I'm reading called Interaction Design: Beyond Human-Computer Interaction.  It was comparing architects with engineers, pointing out that architects care more about the user experience (what layouts of building are conducive to certain activities, etc), while engineers are concerned with the technical details (like calculations and numbers).  While I'm sure this isn't the whole picture, it does give a bit of basis for arguing why software architects can be called architects.

Software architects are generally responsible for the overall design of code.  They care about the user experience of software developers (who in this comparison may be seen as the engineers) for the end goal of making it easier for them to create high quality software.  They do this by considering design patterns, enforcing coding standards, and making high-level decisions.  In a sense, they create a layout of the software architecture in much the same way that architects do for buildings.  Even though the 'user' in the considered user experience isn't as much an end user as a regular architect would be designing for, I still think the philosophies of the two roles align.

What do you think? Are there more similarities, or do you see the two types of architect being pretty distinct?

Read more

CompSci Woman: Technology is Women's Work

Have you seen the new CompSci Woman blog yet? No? Well get over there and check it out! And better yet, if you happen to be female and have any kind of computer science background, consider contributing to the blog as well.

I just wrote up my piece for this month's theme on "how I got into computer science." It's called Behind the Screen:

I once considered attending a local specialized high school called Canterbury. It’s an arts school, and I wanted to attend for creative writing. After all, I had won a writing contest or two in my day, so I thought I was pretty good at it.

Unfortunately, the bus ride was far too long from my rural home, so I never went. Fortunately, I never let go of my creative side, which also included a love for drama, music, and now photography.

You'll have to read the rest of the story over at the blog.

Cate Huston is one of the two creators of CompSci Woman (Maggie Zhou is the other). Cate shared some of the "why" behind it all:

What brought it home so strongly, how hard it had been to be a minority, is that at the time I wasn’t. Extreme Blue Canada had an amazing number of women in the program this year. There was a girl on every team - two on some, including the team I was on. It was noticeable compared to the US teams at expo - Canada had exceeded the magic ratio, at which the women were not minorities, but normal.

It was different for Maggie, who was one of two women in her building. We talked about this - we had very different coping strategies. Towards the end of the summer, I floated the idea of a blog to her - the natural next step from the many conversations we had that summer. We thought that whilst you might not want to brand yourself as a woman in CS (every woman in CS I know is so much more than that, perhaps it’s like evolution, only the most awesome/stubborn/motivated/interesting survive), you could brand a platform, provide a forum for women who don’t have the time, or inclination to run their own blog. Maggie was excited by the idea as well, and we started to sketch out a vision and pitch (EB gave us a lot of practise in that) our idea to people. They were interested. They promised to blog for us. CompSci Woman was born, although unnamed.

With your help, we can build a platform, and a community. Because more people means more mentors, and more role models, and more inspiration. And that - well, I hope it’s just the start.

Inspired? I hope so! Now get out there and write your piece! I'll look out for it in the next few weeks. ;)

Read more

Balancing the Needs of Industry and Academia

As I embark on this journey that is a PhD, I constantly remind myself of my goal of remaining useful. I want to retain practical skills that could be used in outside of academia and research labs. I never, ever want to forget how to code, and I'd preferably be able to continue to say that I can code well.

And so with the unusually good timing the universe sometimes provides, I stumbled on a great article in Communications of ACM called What Should We Teach New Software Developers? Why? by Bjarne Stroustrup. It discusses the disconnect between what industry wants from computer science graduates, and what universities aim to teach.

Industry wants computer science graduates to build software (at least initially in their careers). That software is often part of a long-lived code base and used for embedded or distributed systems with high reliability requirements. However, many graduates have essentially no education or training in software development outside their hobbyist activities. In particular, most see programming as a minimal effort to complete homework and rarely take a broader view that includes systematic testing, maintenance, documentation, and the use of their code by others. Also, many students fail to connect what they learn in one class to what they learn in another. Thus, we often see students with high grades in algorithms, data structures, and software engineering who nevertheless hack solutions in an operating systems class with total disregard for data structures, algorithms, and the structure of the software. The result is a poorly performing unmaintainable mess.

There are some amazing software developers that come out of Carleton's computer science program. Some have even gone on to start their own successful companies. But there are also a lot who don't find meaningful internship experiences, and who have rarely (or never) written large software projects in a team.

Things look even more bleak for many grad students, for whom getting something that works just well enough to prove a particular result is more important than writing good, reusable code. I know I've definitely learned how to do exactly what is needed when it comes to course projects, and though I always wish I could do more, I know it is just not possible. Once courses are done, though, there is a great opportunity to keep your skills in check. I try to choose projects that require me to write code, and lots of it. I am also considering dabbling in the world of entrepreneurship to give myself an opportunity to write real-world software that needs to work well.

For those who aren't sure what they need to do for industry, or just can't find the right job or project to practice it, it would be nice to have a bit more balance in the degree programs themselves.

Industry would prefer to hire "developers" fully trained in the latest tools and techniques whereas academia's greatest ambition is to produce more and better professors. To make progress, these ideals must become better aligned. Graduates going to industry must have a good grasp of software development and industry must develop much better mechanisms for absorbing new ideas, tools, and techniques.

I can't really speak for the industry side, but I am intrigued by the changes that faculty in Carleton's School of Computer Science are trying to make. Program streams like the upcoming option nicknamed the 'iPhone stream' are meant to provide the same core computer science as everyone else gets with a few extra classes geared towards a career in industry. Granted, these streams are focused on only a narrow portion of industry, but they are definitely a start.

This balance between academia and industry isn't going to be easy to achieve. I honestly don't know exactly how it should work. I like Stroustrup's suggestion of encouraging profs to code, but somehow that doesn't seem to be enough. It also always happens that when changes are proposed to our degree to help students be better prepared for industry, some students cry out that the program is being dumbed down, and that if you want to be so industry-ready you should go to college instead of university. Figuring out how to get the best of both worlds and make everyone happy won't be a fun job, but it's one worth talking about.

Read more