When I graduated from college back in 2014, I did so with two bachelor’s degrees, one in computer science and the other in design. I was able to do so through the Reilly Dual-Degree Program, a five-year program for students to graduate with a degree from the College of Engineering and College of Arts and Letters. I originally chose design because I wanted to learn the necessary design skills in order to improve the usability and appearance of my personal projects. While I originally joined the program to acquire these hard, intrapersonal skills, it was the soft, interpersonal skills and knowledge that proved to be more valuable in my career. I’m here to share these same teachings, so other engineers can hopefully learn from them.
Lesson #1: You are not your audience
For various things in visual communication design, you are supposed to keep your audience in mind. This requires extra thinking and nuance when you are designing to keep these people in mind. You are not designing something for yourself, but rather you are designing to communicate something to an audience. How will they interpret it?
The Lesson for Software Engineers
Similarly for engineers, when you are building a product, this phrase transforms into “you are not your users.” Even though your users can be similar to you, they will never be exactly like you. When you work at companies with a significant global presence, such as Google, this becomes more readily apparent as you have to engineer products for users in both developing countries and developed countries. Never assume that your end-users will be thinking the same thing as you.
Lesson #2: Constructive, objective feedback is always better than reductive, subjective feedback
Robert Sedlack, my professor for Visual Communication Design I (who also happened to be my advisor and the driving reason why I decided to join the design program) banned two phrases during critiques in his class – “I like” and “I don’t like”. Rather, he encouraged us to use to give more thorough and substantial feedback by using stronger phrasing with less subjective language. Here are some example phrases:
- “I think that this is successful because…”
- “I don’t think is successful because…”
- “The way you did X strengthens this work because…”
- “I think that the direction of X is stronger because…”
The rationale behind this is because anybody can say, “I like this” or “I don’t like this” and name the first prominent thing that speaks to them in a piece. Through rephrasing the delivery of feedback/critique, we were forced to give a deeper analysis of the design and clearly articulate our reasoning behind our critique. The same communication was expected when we were explaining the directions we were taking for our pieces as well, forcing us to deeply analyze our own work and really think things through.
The Lesson for Software Engineers
Constructive and objective feedback and language is helpful for software engineers when doing code reviews. While I believe there’s nothing wrong in using the forbidden phrase “I like how you structured this specific piece of code or solved this problem”, I do think that you shouldn’t use the words, “I don’t like how…” Rather, transform your language to be constructive and objective feedback in code reviews. For example, let’s look at two forms of feedback.
- “I don’t like the way this code is structured. Use a hash map instead of an array.”
- “Have you considered storing it in a hash map instead of an array? I think that might have better performance.”
Both have the same underlying message, but the second one has more substance because it contains a why, while the first one does not.
Additionally, use this when thinking about defending your implementation decisions in your code. If you are ignoring feedback or suggested changes to your code because “you like doing it this way” instead of an alternative approach, your emotions may be getting the best of you. Step back and ask yourself, “Is this truly the best way this could be done given the requirements, or will this feedback help improve my code?”
Lesson #3: You are not your designs/work
Another gem that Sedlack would constantly reiterate is that “you are not your designs”. Meaning, you should not have any sense of ego or personal attachment when it comes to your work. Through learning this, I realized that while it’s great to take pride in your work, you should not attach your sense of self into your work. This is often because once you attach a sense of self or personal attachment into your work, it can become harder to accept criticism of your work and strive to iterate or improve on it. I’ve found that through removing my sense of self and personal attachment to my design pieces, it became easier for me to go back and iterate on my work, to see if I can push it in a stronger direction from feedback from critiques.
The Lesson for Software Engineers
I think this is one of the most valuable lessons for software engineers. Too often, both in professional and open-source codebases, there are cases where people attach a sense of self to the code that they write. This makes collaboration way more difficult once somebody’s ego is involved, especially if you think that all the code you write has no room for improvement. Have you ever met somebody who was always against exploring suggested changes to their code in a pull request? Perhaps they got upset if somebody else went in and refactored some code they worked on in the past? Or maybe they get defensive in response to constructive feedback on their code. I personally believe that these all stem from being too attached to your code, so let that go. Through letting it go, you will be more open to iterating and improving upon your code without letting your ego hold you back.
Lesson #4: Iteration is key for improvement
While designing, it’s very rare that the first direction you take for a project is going to be the best one. Rather, through iterating and exploring different directions and presenting them during critique, you can use critiques to help you find the strongest direction. Even if you don’t present them for critique, having multiple works to compare to one another can help you find strengths and shortcomings once you have multiple pieces to compare to one another. Once you decide on a solid direction to take for a design, you can keep on iterating on that design and critiquing it until you are sure that it’s at its best form.
The Lesson for Software Engineers
Similarly with coding, the first direction that you take with tackling a problem may not be the best way. Many times I’ve coded something up but then realized there’s a more optimal and/or simple way of solving something. During a pull request, a coworker may present an alternative solution that you didn’t think about that is simpler or faster. In the end, these iterations will ultimately help you grow, since you learn something new in the process.
Lesson #5: Always critique your work
A common element in all of these previous lessons is critique. The most valuable feedback or ideas for improvement on my design work always came during critiques, whether they are alone or with classmates. During critiques in the classroom, you throw your work up on a board in front of the class, explain the direction you are taking with the piece and the reasoning behind that, and then you open the floor to feedback. Often, my classmates would find things that I had overlooked or help me figure out which directions are the strongest.
Even outside of the classroom, it helped to step away from designing and hold a critique on my own. Asking yourself questions such as, “What does this design do well and what does it not do well? What does it communicate? Is this the message I want to communicate?” Stepping back and critiquing my own work pushed me to create the best piece possible.
The Lesson for Software Engineers
As a software engineer, the lesson that I took away from that is that you should always do code review. Even on side projects, it’s not often that I push to the master branch unless it’s a small and quick fix. For most features, I do my work in a separate branch and open up a pull request, even if I’m the only one working on the project. During these pull requests, I go through and review my code myself, to make sure there aren’t any bugs or that I did not miss anything. I even add friends to my side project repos and ask them for code reviews on more complicated features, just to make sure I didn’t miss anything.
At work, while you may need to have a team member review it before merging it in, you should do a passthrough of the code one or two times yourself. You can also use these pull requests to tell the reviewers, “This is the direction I took, but I also thought about doing it this way, thoughts?” This is the same as getting feedback on two directions you may take for a design during critique and it can be useful to have feedback to lead you down the right path.
Overall, these are the main things from design school that have been invaluable to my career as a software engineer and I have design school to thank for this. I’m hoping these lessons provide the same value to you.