Transcript
Thank you, everyone. Thanks for being here, and for having me. I'm excited to talk to you about a thing close to my heart.
My name is Violet, and I solve problems. Mostly, problems relating to web development. I've worked in this field since 2012 when I graduated from college with my degree in Spanish literature. That makes sense, right! After I graduated, I stuck around in town for seven months, and that was when I got started with my first full-time development job.
I was part of a three-person team, and all of us did back-end, front-end, and our own design, so started off wearing a lot of different caps. After that, I moved to New York City to be a front-end developer at an energy-efficiency start-up. This time, I was part of a six-person team about I was the only front-end weapon developer. Everyone else worked on software or databases. I had friends that were kind of alone there.
At that point, my job was making tiny static sites, and rolling out new features on our product site. I built a Shopify store once, and I also became the start-up iOS developer, which was new to me, so, again, more skills there.
And, after about two years of that, I moved completely across the country to Portland, Oregon for a job at a creative agency called Instrument. There, the sheer amount of things that I worked on, and the amount I've learned has taken off. So I'm not even trying to fit it on to that slide. So, to start with, over the past four years, I got to expand the companies that I've been able to work with, I've done with, tech start-ups with museums, the sportswear companies, non-profits, kind of you name it, I've done some projects in that field.
I've helped create style guides, and I've made interactive installations, and museum labels. I made websites with five pages or with tens of thousands. Sometimes I work alone, other times, I've been one of seven developers. On top of that you will all of that, my role has been dynamic. Sometimes, I've stayed on as an individual contributor focusing on building out the projects. Other times, I've been the tech lead, managing goals and making technical decisions and supporting the Italy. So, clearly -- supporting the team.
Clearly, I love variety. Amidst all this craziness, one constant is my work keeps getting more interesting. I've always got a new challenge to take on a new way to create and be creative. And that's rating where I want to be. But the point is that no single technical thing is THE reason why I enjoy being a developer, and no-one thing has carried me to this point in my career. Except for one thing, which is problem-solving.
For me, this means defining challenges, inventing solutions, finding connections, and getting a little better each time. Independent problem-solving underlies pretty much all the work I've done, and most likely yours as well. Because, above all else, we are creative problem-solvers. We do specialise. We become experts in interaction, performance, in photography, we lose ourselves in colour theory and Stack choices but we are more than those individual things. Our true strength lies in the fact that we think creatively.
We find answers to figure things out and we evolve. As such, problem-solving is a core competency of every single person in this room. So my goal today is to lay out for you some things that took me years to piece together for myself. We're going to do two things: we're going to redefine independence, and look at a framework for independent problem-solving. Let's start out by looking at what independence actually is.
For me, it's most useful to think of independence as a the ability to construct and understand solutions. I think construct, because these acts take generative work. That work may happen in the moment or it may be prefaced by decades of experience, but understanding problems and understanding one's self does not happen without effort.
Likewise, we talk about finding solutions but we don't usually find an entire fix to a problem. Maybe we discover pieces of a solution but, like problems, we need to purposely bring them into being. In the that the definition of "independence" says nothing about working alone or not needing help. Needing help is actually a essential part of problem-solving, as we will see later. Similarly, being patent doesn't mean that you - being independent that you always know the answer.
What matters is, through all of it, you can understand and expand, and improve. That's independence. Let's move on to the actual act of independent problem-solving. How can we think about this and how can we be most effective as we are doing it? One thing to note about what I'm going to talk about is that these are elemental and behavioural strategies. As we go through these, some strategies may feel familiar or resonate with you. They may already be part of your process, and that's wonderful.
For anything unfamiliar, the industry to understand the strategy - and incorporate it in your practice. Over tile, they will become second nature. Independent problem-solving fits into three broad recommendations: have a plan, be honest, and use your tools. Within each of these categories, we are going to look at specific ways to level up our independence and effectiveness. So let's start with planning. Everything's got to have a plan, right? When something new and exciting comes along, it can be tempting to dive right in and just start trying things. This can work but it doesn't really help us to deliver consistent results or learn over time. So, before starting work, we should make a plan of how to tackle the problem. And, before we can even make a plan, we should check that we actually understand the problem that we are trying to solve.
As mathematician Paul Wood said it's foolish to answer a question that you do not understand, let's begin by building our understanding. Let's clarify what the problem is, check our assumptions, and ask all the questions possible. So, here are some ways to check for and expand now you understand a problem. Begin by looking at the data you're given. What do you know, and what other information would you like to have?
Next, check the unknown. Clearly articulate what problem needs solving. Once you look at these, look at the condition. What else does our solution need to do what other boxes should be checked? This is a great place to involve your team-mates who may have a different understanding of the problem or a different context.
Asking these questions as a group ensures that everyone is in agreement about the work being done. At Instrument, most problems are so problems, that during the first three to eight weeks, we don't work on the deliverable at all. Instead of immediately going and working, working, working, it's our job to interview stakeholders, clarify client needs and reach agreement on the project's larger goals.
This does take eight weeks a loft time. But it ensure that, when we do start working, we are making something that actually everybody wants. So, we understand our goal, and now it's time to create a plan. This is probably familiar to most of us on some level. We might track tasks and to dos on Post-its, or on a ticketing system, or what have you. One way to level up the humble to do list is by estimating how long it will take, and establishing that step's sign of progress.
A sign of progress is a way to know that you've advanced towards your goal. For a step on your checklist, how do you know that it works, or that you've brought the solution closer to completion? For example, and this is not real code, the programming methodology of test-driven development is centred around signs of progress. The way test-driven development works is that, before writing any actual code, you write tests describing the behaviour you want your code to ultimately have.
Here's some pseudo code for making a dog. We want the dog to go woof when it barks and we want it to be a good boy. For now, both tests will fail because we haven't coded the dog yet. Once we put in the first bark functionality, it goes from failing to passing.
The passing test is a sign of progress we're on the right track. Once we've written the code so that every test passes, we know we've reached our goal. Okay, so now we've got our plan. We understand the problem, and we have our signs of progress.
But I mentioned this thing about honesty, so where does that fit in? Honesty is extremely important when you're actually solving the problem. Having a plan, even a great one, does not mean that carrying out that plan will be quick or easy. So, a as you work, check in with yourself and be realistic. Is this step taking as long as you thought it would? Are you seeing real signs of progress?
Lastly, how are you feeling about that step, or about your solution in general? By asking yourself these questions and checking in frequently, you can avoid spinning on one minute aspect of the past or by straying off into a similar but actually unrelated problem. You also build mindfulness around your own work habits, and these check-ins will become easier as you examine your habits more closely. In executing a solution, this is also a time to be very honest with your team. I'm going to say the quotes below one at a time, and I would like you to repeat after me, okay? These can be hard to say in the moment and I want to give you some practice. So, "I'm having trouble solving this."
AUDIENCE: I'm having trouble solving this.
VIOLET I'm going to need more time.
AUDIENCE: I'm going to need more time.
VIOLET I will try a different approach.
AUDIENCE: I will try a different approach.
Thank you.
So, right now, you are way ahead of me, because it took me four or five years to become even vaguely comfortable with expressing that I was having trouble. , which, in hindsight, was not productive. But, the secret is managers love it when you tell them they're having trouble. They love it when you go to them and tell you that something is wrong and tell you what you need to overcome in that thing.
It's proactive, it's good information for them to have, and it shows that you care about the project and not about looking perfect. Now that we've got that down, we've come to the last aspect of problem-solving: using your tools. By this, I mean look to connect with what is happening now with things you have already seen or already know.
Mobilise your knowledge, find parallels, and this can guide you towards new steps and solutions. So there are three extremely helpful ways to leverage outside knowledge and experience: by changing modalities, finding a related problem, and asking for help. Changing modalities simply means switching up the medium that you are using. We spend a lot of time in a mouse-keyboard-screen triangle, and, while these tools are amazing, they can trap us into the same thought patterns.
If we're having problems thinking something through, it might be time to express those ideas another way. Writing something on paper instead of typing it can work wonders.
For me, I love drawing pictures, and I often work through problems visually on a whiteboard before taking that back to my computer to type up. Team modalities helps awaken dormant associations and analogies. It's hard to express in words but might be easy to show spatially. Something you can miss on a computer screen can stand out if it is written longhand.
One classic modality is rubber-ducking. In programming, it's a debugging tactic where you narrate every thing that your code is doing or every single thing to try it out. It works whether you're talking to another skilled programming colleague or a rubber Ducky sitting on your desk, which is where the term comes from. So the effectiveness of this technique does not come from getting real feedback. It comes simply from being forced to vocalise your ideas and to do it linearly. Assumptions, mistakes, and subtleties that you can miss when you're typing and reading are suddenly super apparent.
Apart from changing modalities, finding a related problem is a great way to bring fresh knowledge into your current task. So, all problems are related to each other in some way. Even if, in the moment, it doesn't feel like it. These problems are wonderful because you've seen a related problem before and may actually have solved it. When you find a related problem, this can deepen your understanding of the current problem. A related problem can suggest steps to take for signs of progress, it can point to an alternate solution, or illuminate domain-specific knowledge. How do you know if the two problems are related? You can search for a related problem by asking questions similar to the questions we were asking at the beginning when we were trying to understand a single problem.
So, basically, problems can be related to each other through their data, unknown, or conditions. So, for instance, data-wise, a side bar built in React might have information applicable to an image gallery built in React. Unknown, building a footer might have applicable learning to building a header because they solve navigation needs. Having an e-commerce site can help you build a blog if they satisfy the condition of working out JavaScript.
If this sounds like a bit of, the good news is that, as you gain experience, you will have more and more solutions to look back on and use as related problems. Taking on a wide variety of challenges, especially early in your career can help build up this stock of related problems to refer to later. As you work through these problems, you'll start being able to notice and leverage patterns everywhere.
And, you don't only need to rely on your own experience - there are ways of bringing others' experience to the table. So, asking for help is where we are now. This can work wonders, but getting comfortable with it can also be very difficult. Here, we're going to look at tactics for seeking help. They aim at structure, how you look for help, build your confidence, and to make it easier for others to help you as well. So, before we dive into the specifics, I want to tell you a secret that is so secret that a bunch of the talks today have already highlighted it! But, I'm going to say it again because it can't be said enough: if you get comfortable asking for help, you will be way ahead of so many of your more senior colleagues.
For a variety of reasons, societal and personal, people just don't ask for help, and they get used to life that way. If independence means you don't need help, it follows that seeking help means you're not independent. Needing help, admitting that you can't do something alone, can feel like admitting that you have failed. I know because I've suffocated under that weight. So, here's what I wish I had known earlier: seeking help shows self-knowledge in that you're aware of your own limits. Where you should be challenging yourself, you're not magic, and you won't gain cognitions through the same repeated struggle. Asking help shows you respect your colleagues and expertise, and, most importantly, it shows that you value solving the problem at hand over preserving your own ego.
This factor is incredibly important to your manager especially, and it shows that you can be depended on. So, first let's establish some of the really helpful things you can get from seeking help. If someone has solved a very similar problem, you may straight up be able to use their solution and tailor the specifics to your situation. You can also use others' experience as a way of finding related problems and to challenge your own assumptions. Lastly, some things are just really hard to isolate or do well. So asking another person can be the best way forward in a reasonable time frame.
So, for a personal example, here is a picture of me not asking for help. I don't know if you can tell from the photo, but, when this was taken, I was completely freaking out on the inside. So, a long story short, we were setting up an installation the day before an event, and, for some reason - I still don't know why - an animation that had worked fine through months of development and testing was suddenly dropping frames all over the place. It was choppy, extremely obvious, and it looked terrible. It was my animation, so, by my logic, it was on me to fix it. I had no idea why it was happening. I set myself apart from my other team-mates, and I Googled things over and over. But again in retrospect, not a great move. I Googled everything I could think of, and I was panicking that like, this was it. I was never going to get it working again, I was going to get fired. I was wondering if my parents would let me move back in with them while I looked for another job. Then a colleague wandered over and suggested one line of CSS that I had never even heard of before. This was the line, by the way! Very applicable learning.
So the moral is that if I asked for help earlier, maybe this photo would have been of me eating nachos or hanging out with my co-workers. Instead, it's me, and I'm tense, and worried and alone. So, I just want some nachos, and I want you to minimise your amount of worry. All right, so, still asking for help. Who are good people to ask, to seek help from? Honestly, pretty much everyone.
Team-mates and co-workers may have insight into your specific situation, or into company standards and prior work. Special-interest communities can help you get deep expertise on narrow topics. Select groups are amazing for this. I'm a member of an accessibility Slack group, and the other people in it are either experts or at least care a lot. So the discussion and knowledge-sharing there is invaluable.
I encourage you to find and engage with, as you can, specific groups that correspond to your interest. The goal, to borrow a metaphor from Lara Hogan is to build a ... meaning you should strive to build up a mental database of people you know can help you with various topics. Right now, mine includes co-workers who can help me with accessibility, technical design documents, TypeScript, and more.
Now that you know who to go to, when should you go to them? Some amazing moments for asking for help are when you're unable to complete a step in your plan. If you're not seeing an expected sign of progress, or, if, when you're carrying out a solution and you realise that you need to complete the that you need to completely rethink your plan.
This is a little wordy, but this is one of my rules of thumb for seeking help: if I'm pretty sure that someone I know has dealt with the exact thing I'm trying to solve, I ask for help very early on. It probably won't need to take too much time to think or to think very hard at all, and will likely be able to copy-paste some code and send it over to me. On the other hand, if I'm pretty sure that no-one in my usual group has done something similar, I will work on it longer before seeking help.
In this case, I want to make it worth their while. Which leaves me to the last part of the strategy, how to go about asking for help. These are guidelines, not hard and fast rules, that they do make it easier for others to help you. First, it helps to give context. Some questions are fine to ask with no preamble, but most of the time, it helps to know why you're here in the first place. It helps colleagues understand your position and make better recommendations.
Sometimes, and this happens to everyone, you're so lost that you just need general guidance, or general way-finding on some topic, but most of the time there's some specific question you're trying to get to the bottom of, at it's your advantage to ask that question. Listing out what you've already tried or are trying helps others target their advice better, so this way they won't suggest things that you've already attempted.
Lastly, it's just nice to end with a thank you. It will keep the virtues cycle going by showing others that their time is appreciated. As a corollary, especially as a junior member of an organisation, asking for help can be a really effective way to create cultural change in an organisation even if you might not have a lot high high up on the totem pole yet.
With that, that wraps up problem-solving. Have a plan, be honest, and use your tools. Those are the best skills that any of us in this field can develop. I hope you're able to bring those skills into your own work and your own practice. As you gain experience solving problems, you'll be able to push harder on your own boundaries and open up new creative possibilities for yourself.
So, thanks so much, again. I'm excited to see how you grow and how you create. Say hi, shoot me an email, come work with me, and, in the meantime, happy problem-solving!