Thinking Like a Developer & Breaking into Design
Jonathan Northcott, Scout alum (‘19), talks going from zero coding experience to leading a team of designers and developers.
By Jonathan Northcott, edited by Veronica Cihlar
During my first few weeks as a Computer Science major, each basic programming topic that was introduced in my classes was met by a collective groan of boredom and frustration from my more computer-literate classmates. Meanwhile, my confidence continually plummeted as I became more confused by the content, overwhelmed by the work, and anxious that I was going to fail. I was worried I’d made a mistake. Thankfully, I now know I didn’t.
I finished my combined Computer Science & Business Administration degree in May 2019. I’m now a Data Engineer at Recorded Future, which is a security intelligence company in Davis Square, and while going from no previous coding experience to a point where I was competitive with my peers certainly wasn’t the easiest thing I’ve ever done, in hindsight I have zero regrets. Still, since it wasn’t the easiest thing, I figured I’d put together a few tips on how to go from zero coding to knowing the basics, as well as integrating coding into your passions (which for me turned out to be design)!
Making Opportunities to Practice
If you’re struggling to find a way to pick up new skills in your free time, there are countless collections on Github, where people have compiled projects of varying levels of difficulty to help others get started. Here’s one, another one, and a third. If you’re struggling to get an understanding of a language to start a project, Codecademy is also a great free resource to learn the basics; I used it to learn Python when I was co-oping at Liberty Mutual.
Even with all of these useful resources easily accessible, I could never find the motivation to try any of the projects. I struggled to routinely dedicate time outside of class and co-op to side projects until I started coming up with ones that served a real purpose other than just a medium to learn a new language. I wanted to build something that would make my everyday life easier and more enjoyable.
I ended up working on an app that let my roommates and I walk into our dorm room while playing different walk-in music. Not only did I learn more about APIs, NodeJS, and how to deploy something on Heroku, but it also made for a cool party trick and a fun topic to discuss during interviews.
Learning from Mistakes
One area from which I got a great deal of return was embracing mistakes and failures. I found that I learned more from understanding my failures than I did from my successes.
I once had to read this article about two interns at Bose for class, and it’s still what I use as a baseline to keep my mindset positive and productive — especially when dealing with fallout from mistakes or powering through boring projects that I have to work on.
There was this one co-op interview where I just crashed and burned during the technical portion. I could have seen it as a waste of a few hours, or I could’ve seen it as a learning opportunity and, ultimately, as a productive use of my time. At the end, I addressed the elephant in the room and took a chance to get feedback from a senior software engineer. That interview helped me find areas where I needed to improve, and was the main reason why the search for my third co-op went so smoothly.
Getting Acquainted with Design Thinking
Once I started working on some design projects at Scout, much like with coding, I had to learn the language of design before I could really start being productive. I needed to learn how to talk about design concepts I wasn’t familiar with and effectively communicate the concepts I did know.
At Scout, this looked like me contributing logo concepts despite my self-consciousness, picking my designers’ brains about what decisions went into their designs so I could start to think like them, and getting more comfortable using Figma for various tasks like building our site map.
Outside of Scout, this could look like grabbing a coffee with a designer (perhaps from co-op or just someone in your network), looking at design co-op listings and seeing what tools you should try to practice or industry terms that you should learn more about, or reading about different peoples’ thought processes (such as big rebrands and what different designers think about them).
At first, I found it uncomfortable showing how unfamiliar I was with everything. I didn’t want to present my logo concepts during our meeting because I was embarrassed by how they came out. I overcame those feelings by telling myself to remember that my designers likely felt the same way about coding, and by confronting my embarrassment and practicing, it opened up the opportunity for everyone to improve.
Thinking Like a Developer in a Design Context
During the first couple design reviews with my team, I would get so caught up worrying about how I didn’t know enough to provide good feedback that I failed to realize it’s okay to think like a developer. Turns out, there was more cross-over than I previously thought.
For example, two of my favorite aspects of code reviews are hunting down bugs and edge cases. A bug is when the logic in the code isn’t working as expected. An example would be if a deposit into a bank account causes the balance to go down instead of up because someone mistakenly did subtraction instead of addition when writing the code. An edge case is something that wasn’t considered during the design of the program. An example would be expecting February to always have 28 days and forgetting about a leap year.
I found that the same kind of problem-solving approaches that are useful while hunting down program errors could be applied to providing input on wireframes. For example, design edge cases could be intentionally predicting different ways something could break, and creating fail-safes against those scenarios. What happens if the user doesn’t have Internet? What if they rotate their phone? If someone has a long name, will it fit on the screen?
Finally, a design may not be possible with the current technical implementation. Without someone with “dev” knowledge reviewing items, the fact that a design isn’t possible to build may go unnoticed. Continuing to think like a developer was crucial to ensure that those cases did get noticed.
Lastly: Finding Passionate People
Like most, I found that I had an easier time getting to know people when we shared a common interest that we were all passionate about. It was that mindset that brought me to Scout during my final semester.
I was a Project Lead and developer on the Breathe Easy team, and our project was to build a mobile app to help families with children suffering from asthma keep control of their health. Using an action plan provided by a doctor to build an individualized management scheme, users were guided through daily treatments, presented personalized analytics, shown feedback to help reduce avoidable asthma flare-ups, and given access to educational materials that help close the knowledge gap between doctors and their patients.
Building a mobile app that could effectively accomplish all of the above brought with it several difficult technical and design challenges that I hadn’t faced before.
Many of the original requirements either needed a detailed design that we couldn’t support technically, or a complex technology that we didn’t have time to make a design for.
It was my job as a PL who had no design education to make sense of it all and communicate between my team and client. I felt like a first year all over again.
When I’ve encountered the problem of having to decide between a design decision or a technical choice, I’ve noticed that there are always going to be trade-offs with either one. Sometimes the design is picked first and the engineers need to figure out how to implement it, while other times it’s the designers that need to rework the wireframes — or it’s a combo of both. Deciding which trade-off to pick depends on the organization or company, and what their priorities are.
In Scout, our priorities were keeping our teams happy and on-track, getting the major deliverables finished, and listening to our clients. Ultimately, Scout provided me with a community that made it a little easier to become a developer who could hold his own in the design process. However, the strategies I used to get to that point are applicable elsewhere as well.
In the fields of design and software development, it is incredibly worthwhile to gain some insight into how the other side works, even if it’s only at a basic level.
There is a growing demand for products to be accessible to everyone, as well as safer and more reliable. A designer with some coding skills or a developer with a little design background is positioned to be a more competitive candidate to meet those demands.
It can be overwhelming and a bit scary to put yourself out there and learn something new, so it’s okay to take it slow, make mistakes, and to lean on your peers for help. I can say from experience, it does get easier — and is totally worth it.
