Ivana McConnell

Ivana is an interaction designer in Vancouver, making things at Myplanet. When not working, she sometimes teaches people about the wonders of interaction design and code, but most of her free time is spent rambling around the city and mountains with her wife and her jack russell terrier in search of good rock climbing and good food.

She occasionally tweets at @IvanaMcConnell and can also be found via her personal website.

Published Thoughts

Impostor Syndrome: A symptom of happiness?

I recently saw a talk by Angelina Fabbro, detailing a wonderful set of tongue-in-cheek rules for how to spot someone who is not a true developer (i.e., not a twenty-four year old white male, someone who dares to care about fonts and colours, etc). It is on Github here for those who’d like to view the slides.

For those who don't know, impostor syndrome is a psychological state, wherein a person never thinks that they are good enough, and always feel as though they are posing as someone they're not. They consistently live in fear of being found out, and exposed for the impostor they are.

This talk struck a particularly ironic note for me, since it was something that I had been worrying about moments before, dressed in skinny jeans and a t-shirt with an ampersand unashamedly emblazoned on the front: henceforth I would easily be spotted as a 'designer,' and therefore an outsider, in this group of very intelligent people in which I most certainly didn’t belong.

As I started to think and read about this topic some more, I found that Angelina has also written for the Pastry Box Project. I would like to add to her thoughts on impostor syndrome with my own anxieties, tricking my own developer colleagues, and the newfound realisation that only as an impostor can I be truly happy.

Despite the brilliant satire of Angelina’s talk, I found myself worrying about why impostor syndrome (or impostor phenomenon) is so prevalent. After all, I’ve been in this profession for quite a few years, and yet my own personal impostor complex still persists; I’ve decided that this has at least a little bit to do with the fact that the profession of ‘programming’ as such is an incredibly broad one. ‘Web development’ itself is a term so all-encompassing that it’s bound to create problems about who fits into it and why. After all, to develop something by definition is 'to grow or cause to grow and become more mature, advanced, or elaborate.' How we do this is up to us, and that double-edged ambiguity sword is something I love about web development. It’s so all-encompassing that you couldn’t possibly do it on your own; to truly make something great, you have to ask for help and involve others, be it from the designer, the developer, the font nerd, the neurotic, the customer, the parent— everyone.

It’s strange to me that ‘design’ and ‘development’ have to be separate entities, as though they are completely different disciplines. The overwhelming desire to class myself personally as either one or the other during conferences or meetings, for the sake of simplicity, contributes to that impostor syndrome at its worst and most anxiety-inducing. However, I have come to realise and come to terms with the fact that while this is something I’ll always worry about, being an impostor is okay, and sometimes even desirable.

Recently, a colleague shared this post with me, an excellent exploration of how not knowing what you're doing can actually be a good thing. I was directed to this while I was hopelessly flailing in what I perceived to be the deep end of EmberJS (it wasn’t). Another colleague then shared this image, and that is what I find the most interesting about my own impostor syndrome; I am at my happiest when I am attempting to be someone else, or being challenged to talk about something that I think I know nothing about. This is because I am forced to learn about that something, to understand it well enough to hold a conversation, and from that conversation, my knowledge can only grow. And if I succeed in my ruse, then I’m all the prouder for it.

For example, I was recently chatting to a few of my colleagues about a problem ubiquitous in web development; the creation of a new feature in a product. As with many such problems in a web app, its user interface informs the development, and the development informs the interface. It’s not possible to linearly develop, then design, or vice versa. The creation of a feature is a result of communication and dialogue as much as it is about code and design, if not more so, and the two should work in tandem. Everyone should, to some extent, try to impersonate the other side for a while. For me, this understanding is the most satisfying part of the process: a chat in which everyone takes part and provides both problems and solutions, challenges and how to overcome them. I found myself participating in this conversation, not only with questions but with solutions as well— solutions to development problems, not design ones— and my masquerade was a resounding success.

However, it was only after this conversation took place that I realised that I had been successful, much more so than I had initially thought. I knew enough about Ember, Ruby, and how they interact with and generate the CSS and HTML that I write. I knew enough to propose interesting topics of conversation and hold that conversation, too. Even better, my colleagues had seen fit to employ that solution, and take my opinion on board. I had succeeded in the ultimate ruse, clearly— a designer taking part in a developer’s conversation, without being noticed. But what was most important was that I had enjoyed it, and learned something in the process.

This, to me, is the essence of web development. It is a series of people, each bringing their expertise and individual pieces to one larger puzzle that is far greater than the sum of its parts. A desire to splinter all of these disciplines is perhaps predictable, but unnecessary. No, I couldn’t build anything without someone to wrangle servers and build product features out of maths and magic. That said, there is just as much refinement, thought, and intricacy to arranging those features in a manner that makes sense to people unaware of the witchcraft behind it all. A nice little UX twist can have just as much unsung heroism as that piece of Ruby code. Each piece has its own place in the puzzle, but you have to see the big picture to know where your piece will go, and impostor syndrome lets me see the big picture.

I think that is the key to my version of impostor syndrome; it is a constant desire to be tested, and that insecurity is A Good Thing, in small doses. Each time I successfully navigate a development conversation is one more day that I’ve learned something new, and can continue to masquerade as a developer. I would venture to say that this challenge is the only way we can become truly great at what we do, and many people would benefit from attempting to pose as someone else. Even if you are unmasked, what you learn in the process is invaluable, and people might even believe you, or you might actually start believing yourself. It might not work for everyone, but this is the only way I am happy; with a good dose of insecurity and fear. It is what makes me better. The aforementioned development conversations present new challenges that I would never be able to think of, and it is a great feeling to rise to that challenge. No, I may not know what I’m doing, but I am enjoying it, in the same terrifying way that a skydive or a rugby game is enjoyed by those partaking. It’s terrifying and worthwhile, though it isn’t everyone’s cup of tea.

I am a designer, yes, but I do feel that I am a developer as well. No, I am not going to be the one who worries about security or staging servers, but I will be the one who creates an interface and occasionally adds a new feature in Ember, and develops the product in an entirely different way. I will have conversations with those who provide the skeleton for what it is I do, and inform their decisions, just as they will inform mine.

So maybe you are occasionally a developer, and like me, you’re too neurotic to realise it. Even if you have a giant ampersand on your t-shirt— if you solve problems with code, make apps and websites and products more elaborate, and spend a good deal of your time worrying if those solutions (and you by extension) are good enough, then you are a developer.

I’m not sure if Angelina or the others that have written about the syndrome would agree with me, but I would venture to say that perhaps a certain amount of impostor syndrome is a sign of happiness, and offers a certain amount of freedom. You aren’t constrained to one thing, but are free to dabble in others, and see if you can hack it. You continue to test yourself and constantly learn something new in the process.

There are moments, of course, when I have failed this test. It doesn’t feel good, but it is outweighed by the countless times where I have passed, and successfully fooled people into thinking that I am a true developer. Moving forward, I’ll try to take my own advice to heart. I will rejoice in my trickery; I am the Frank Abagnale of web development, and will happily carry on in my ruse, until I decide to pose as someone else.

Notes on Code First: Girls

Until recently, I had thought that course-teaching was for the seasoned veterans of the web world, those who knew HTML, CSS, and Javascript like tying their shoes, for whom Powerpoint and networking over coffee and sandwiches comes easily (without worrying about how many sandwiches is too many given the number of students and the number of food items on offer). I am not one of these people. I worry about sandwiches, handshakes, and other such mundane things. Unsurprisingly, then, I had thought that I was not cut out to teach a course. Perfectly happy in my design and development corner, I didn’t feel like I could be a poster child for tech as the cool new thing, standing before a group of students with their eyebrows raised, expecting to be taught the virtues of a career in code.

That was, of course, until I was actually asked to teach a class. I was on my way out of the office for lunch a few months ago when I was approached by one of the organisers of a Code First: Girls event about teaching some young women about the basics of coding. It was far enough away for me to think it harmless (or to think I could read a Wikipedia article/several motivational blog posts about how to teach), so I agreed. And I wouldn’t be teaching it alone, they said; much to my delight, I would be with one of these seasoned course-teaching veterans, Alan Gardner.

On the whole, I was terrified of teaching, mostly because I have the perpetual feeling that I’m not actually very good at what I do. Rationally, I understand that I must be, but I can’t get away from the belief that I’ve somehow tricked everyone around me. A course would surely expose that lack of understanding.

This fear was only exacerbated when I first sat down to write the materials. We agreed that Alan would teach the HTML and I would follow immediately with CSS. I had no idea where to begin, as what I thought were the most basic of concepts were like nesting dolls; there was more and more inside of them, all of which needed explained. It was instructive for me personally to keep trying various methods to find a good starting point from which to teach the basics, and which order to teach them in. Code is a non-linear thing, and trying to wrangle it into a linear, structured format can often be frustrating.

The trouble with web development in general is that there are so many different ways to approach a problem that there is simply no time to teach them all. The act of choosing one method to teach over a multitude of others caused no shortage of headaches and fear, but eventually I had something I was happy with. It was a humbling process, and I realised that I didn’t have to teach them the right way, but simply the way that made the most sense to me.

The course itself, we decided, would have a loose general structure that we could adapt along the way, depending on how good (or how terrified) our students were. We would do a very short introduction to our topic and immediately throw the students into the deep end with an exercise. This was because we know as developers that it’s not at all helpful to have someone talking about code you haven’t yet seen. Slides go past, but the syntax is unclear, and the student has no idea where to look. For this reason, they did an exercise first, usually for about thirty to sixty minutes, to get a handle on the basic principles of HTML, CSS, or Javascript. It was only afterwards that Alan and I talked about the subject with a little more depth, once they had a context for it.

We used pre-made materials from Dash and Codecademy; the rationale behind this was that we didn’t want to reinvent the wheel. The materials were already on the internet, far better than anything we could make given the constraints, and it made no sense to spend time creating a coding environment when there were already some excellent ones out there. This also touched on the point that there are so many good resources out there on the web; you just have to know how to look and, when you have a question, who or where to ask for help. We thought it would be more useful to be the help, to guide students through the myriad of materials and resources available, rather than redundantly adding to those materials.

In teaching CSS, I enjoyed distilling it down to its very basics, extolling the virtues of external stylesheets and demonising inline styles. However, it showed me just how many assumptions I’d made when I saw the girls trying to negotiate their very first external stylesheet. For example, I had forgotten to tell them that they didn’t need the <style> tag in an external CSS file. This had been so simple that I had taken it for granted, and forgotten to point it out as a result (something which I immediately rectified). It was great for me to see the thought process and expectations of someone completely new to the languages that I’d been working with for over half my life. And these languages are fickle; it was difficult sometimes to tell a student that their expectations were correct, but that the language or browser simply didn’t work that way. Semicolons and syntax were a continual source of frustration, but that is why short lectures and external exercises were so helpful, because it meant that Alan and I could walk around and help them with these small errors and reinforce the basics, so that they didn’t get too disheartened too quickly.

I also had to continually remind myself to slow down, especially if I was writing code myself. I had to remember that they don’t know the salient points of what I am trying to show them; they’re trying to take it all in. They cannot distinguish between personal preference in coding, unwritten etiquette, and hard-and-fast syntax rules. The shortcuts that I have become so used to, the likes of Coda and Emmet and multiple selections in SublimeText— all of this went out the window, but it was useful for me to see just now engrained those little personal preferences are to my workflow, and how demanding it is to step out of them so as not to overload the people I’m teaching.

Despite my best efforts, that overload came quickly. Once I began to teach the more complicated aspects of the course, Bootstrap in particular, I realised how unwieldy the web’s simplest principles can be. I also realised just how lucky we’d gotten with the students we had, and how big a part their demeanour and attitude plays when it comes to teaching code, or anything at all.

We like to think of the coding world as having a very low barrier to entry. Whoever has the attitude and the desire to learn is welcomed. In general, this is true, and there is an incredible wealth of materials available online for those who want to learn at their own pace. However, the sheer scale of this material proves a double-edged sword almost immediately, and the freedom of the profession is quickly turned against us. When someone is first learning something novel, whatever that something may be, they almost always require structure. They need to learn basics, sets of rules and heuristics on which they can build the rest of their knowledge. Coding doesn’t always lend itself well to this; there are so many quirks, so many personal preferences and so many materials that it can be hard to choose one thing to learn from. There are so many different websites, bloggers, and startups trying to teach coding in different ways that the simple act of choosing one can be overwhelming. Searching for a solution on StackOverflow can be horrifying on its own; a solution that is lauded in one place is vilified in another, and a beginner has no idea why. They don’t yet know how to apply these solutions to their code, and the strong opinions within the development community occasionally scare these people out of asking a question.

There is also the curious idea that the very things which should be making web development easier for beginners— things like Bootstrap (or whatever jQuery plugin is the fashion this week)— are only usable by those who are already in the industry. For example, Bootstrap should make it easy to create a simple, responsive website for those of all abilities. However, it has gotten more and more complex in its versions, adding quite a few different components and classes that make it very unwieldy to teach and use, especially to someone who has just learned the nature of CSS classes recently.

Don’t get me wrong; I think the web development world is a better place for having these frameworks, but there is nothing more unfortunate than presenting a beginner, the very person who will gain the most satisfaction from a quick Bootstrap mockup, with its documentation page. Imagine a beginner reading this sentence: “To ensure proper rendering and touch zooming, add the viewport meta tag to your <head>.” It isn’t clear from this that the line of code that follows is absolutely integral to the site’s rendering on phones, and that it must be added. The grid system is confusing at the best of times, with its different classes depending on screen size. As a result, the learning curve is far steeper than intended, and the simple act of creating one’s first grid is an inordinately difficult thing to teach and learn. It shouldn’t be.

This isn’t a personal vendetta against Bootstrap, but a general point about web development for beginners. It is ironic that the tools which make our lives easier are only accessible when we don’t really need them. I can very much understand the value of all of this documentation, but the observation did strike me that it’s perhaps not as beginner-friendly as it can and should be. There is something to be said for learning the ins and outs of responsive design, for coding a responsive site by hand to get to grips with its functionality, but this should not be a prerequisite. I believe that not everyone should have to learn raw Javascript inside and out to know how to use a jQuery plugin just to display a simple animation on their web page, and not everyone should have to know CSS inside and out before using Bootstrap (or any responsive framework, for that matter).

In spite of all this, however, the students dug in brilliantly, tried their best using an example I gave them and after a few hours, had truly grasped the basics of responsive design and made their own small websites. They asked questions, engaged with the code, and were unafraid to say when the documentation or my material wasn’t what they expected.

At the risk of sounding a bit ridiculous, it was all very self-affirming. I had thought myself woefully unqualified, but each time there was a question asked that I could answer, I understood that my knowledge was perhaps better than I’d given myself credit for. And at the same time, when I didn’t know the answer, it was easy (and perhaps even more helpful) to work through the process with them, to show them where I would look and which terms I would search in order to find a solution to that particular problem. It was integral to me that they understood that they didn’t have to know everything; nobody does. There is that stereotype that somehow still persists about the lonely programmer, sitting at his (and it’s always a man) desk on his own. He wears glasses, eats pot noodles, has a degree in Computer Science or mathematics, and is far smarter than you. It was important to me to break down this stereotype and show them that the web is filled with problems and their solutions; if you are sitting there slaving away on your own trying to reinvent the wheel, not bothering to engage with the community, then you’re doing web development wrong. Asking for help isn’t a sign of weakness.

It is that tenacity and that desire to improve which is the most important, either in teaching or in learning. Given enough time, I can teach someone anything, be it programming or sport or mathematics. I can’t teach them to have that drive and passion, and that terrier-like tendency of a great developer to grab a problem and never let it go, despite its best efforts to squirrel away and get the better of them. Not everyone has that and that’s okay, but these students did. They had a drive to learn that made my job as a first-time teacher very easy. They wanted to be there. That’s more than half the battle: having students in the classroom who actually want to learn, and believe that they can.

By the end of the weekend, I felt I had learned just as much as the students, if not more. I had been able to engage with them, teach them a few things, and offer them some support for the future. It was that support, direction, and mutual fear (that is, the feeling that someone else is or has been just as afraid as you are, and has pulled through) that had been so difficult for me to find when I was just starting out, and that I feel is integral to the beginning of a career in code. It was incredibly fulfilling, and something that I hope to do again in the near future. In the future, I will be much more open to teaching, and I would recommend it even more to those who feel they don’t know enough. Teaching our passion very quickly affirms what we do know, and shows us what to learn next.

Of course, there are still a few things that haven’t changed. I still worried about how many sandwiches were too many, what my cake choice said about me, and I forgot a few names. I said a few nonsensical things and perhaps I cursed a little too much, but I think we taught the girls something really useful and maybe broke down a few stereotypes, not just about women in tech but men as well. They came away with a responsive, individual website, and I can only hope that we inspired them to create more. It definitely inspired me to continue teaching, and learning in turn.