Lessons from Design School for Software Engineers
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 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…
Iheanyi Ekechukwu
Senior Software Engineer, GitHub
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 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 a little about those skills, so other engineers can hopefully learn from them.
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 a certain 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?”
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.
At work, while you may need to have a team member review it before merging it in, you should do a pass 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.
Tags: bulletin, design, stackoverflow
Lesson #1: You are not your audience
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 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 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.”
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 a certain 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 more difficult once somebody’s ego is involved, especially if you think that 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 in 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, as 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 pass 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.
Tags: bulletin, design, stackoverflow
14 Comments
Great job. The biggest take away for me is is adapting the removal the two phrases “I like this…” and “I don’t like this…” and substituting more concrete response. Thank you.
Has the team considered adding an upvote button? I think that would bring out better that this is a nice read 😉
Excellent lessons for apply (IMHO), not only in the workplace, but also in every day.
Not really in agreement with lesson #3. My work reflects myself, partially. Anyone saying my work is bad is saying I have been a bad worker in that particular instance. In the absence of new requirements anyone who wants to change my work is saying it could have been done better. And that is fine. I don’t always make the best work even if I try. Hiding my failures pretending that the work is wrong but I was not wrong won’t help me improve as much as admitting my own failures. Admitting my work is wrong is good. Admitting I am wrong when my work is wrong is better. And is one of the steps required to become better
” “Have you considered storing it in a hash map instead of an array? I think that might have better performance.”…has more substance because it contains a why…”
It also suggests an objective measure which can be identified and examined. This allows for more clarity in how the code meets the objectives of the activity, and a better understanding of the tradeoffs taken in design choices. Maybe the hash map has better performance than an array, but in the context of the overall code there’s less translation of inputs needed to feed things into the hash map (and to turn the results into information useable by the other parts of the code…)
Great work on putting up all these points so nicely.
The most essential thing that I have seen in a collaborative project is how to give constructive feedback on code reviews or design documents.
“Not really in agreement with lesson #3. My work reflects myself, … And is one of the steps required to become better”
You should avoid assuming that because some code needs to change it is bad. There are many reasons code needs to change outside of our control as programmers and dealing with it is part of the job. There isn’t an objectively “correct” way to write any particular piece of code, so it is natural that other options exist. Whether it is worth the time, effort or money to change between the options is a secondary question that also needs to be answered.
If you are in a situation where you are judged as being bad at your job because some code you wrote needs to be revisited, you may be working in a toxic management environment (unless you are incapable or unwilling to learn from mistakes — then you should examine your own motivations or communication skills).
Thanks for all.
Thanks – this is very useful, especially for software engineers who are not used to thinking along these lines.
This is a nice write up. Please allow me to offer some additions.
When reviewing designs, or especially code, remember to not let perfect be the enemy of good. As long as the work meets the requirements it is good. Yes, often (usually) it could be better but improvements should be weighed against the cost of changes. If the code being reviewed is working and has been tested the improvements have to be significant enough to justify the effort of redoing it.
Which leads to my next point: Reviews are best done early. The most valuable reviews are before any code is written; they are done when in the planning stages trying to find best approach to take. This is also before much time has been invested in one particular solution, and before much ego has been invested. It is true that you are not your work but this is often a hard thing to remember and you should help yourself by getting the input early.
And one more thing about “you are not the work”: I have found that writing SW is incredibly humbling. Many times I have worked long and hard on a piece of SW, reviewed it and re-reviewed it, and have already developed pride in the great work that I have done, and then I start testing. That’s when humility is needed. The same humility is needed when asking for review input. I believe I have written some great SW but I’m not sure anything has worked first try. And all of it could have been better.
Thank you for sharing. I loved it. After working as a front end engineer for a year and a half, I can relate to it very much.
I’m totally going to share this article. As a senior dev I see these patterns in the new guys coming up. There are a LOT of really good tips here. Thanks for posting!
Beautiful article. I don’t just like (love) it: I think that this article is successful because it shows 5 clear, practical, easy to grasp, lessons. Joining these opposite world’s: design, engineer, shows great fertility: maybe they shouldn’t be so distant one from the other.
Again: beautiful article, if I may say.
Really great write up you wrote here. I have learned valuable lessons from your list of lessons. Thanks for posting.