The Process Behind Treating Coding Like Design
We recently sat down with Iheanyi Ekechukwu, a Senior Software Engineer at GitHub, to talk about his side project, the job board app Seeker. We discuss the similarities of creating designs with writing code, and how he took what he learned in his college design courses to his job as a developer.
What’s your career background?
I'm a senior software engineer at GitHub, working on GitHub Actions . I graduated in 2014 from Notre Dame, where I majored in Computer Science and Graphic Design. So I have a BS (Bachelor of Science) in Computer Science and BA (Bachelor of Arts) in Design. I've never really worked as a designer, I just do it for fun on my side projects.
Can you walk us through a few projects?
The latest one I've been working on is a job board as a service, it’s a side project that I built called Seeker. I designed it from the ground up and I actually just finished a redesign of it and have been adding polish to it, that I'm ready to start coding.
What was your process for creating Seeker?
I was working on a website with some buddies. It was an online magazine that interviews creatives and designers. Inside of it, it had a little job board widget that was hooked up to a third-party job board.
So while creating this site I was thinking about it and how I just had to drop this job board into our site. I was like, hmmm, I think any community or content driven site should be able to have a job board to monetize itself. It's a dually aligned incentive. Audiences get tailored, custom job postings, and the user makes money. Also the companies can sponsor it and get their jobs out there. I think that job postings are one of the least intrusive forms of ads per se. It’s beneficial, and if you’re not looking for a job, you can just ignore it. So that is how the idea came about.
The first step was to start writing up the requirements. I need a way for users to be able to get paid. I need them to be able to get their own vanity URLs for each of the job boards. It needed to be customizable per se. And I need a way to take application fees. So, I wrote out the technical requirements, then I started working on the designs.
The design process for Seeker was really quick. Normally I would do wireframes, but honestly, the older I get, the less I wireframe. I just get an idea of what I want in my head and start drawing up blocks and content and then build up there.
What is your process for iterating on Seeker?
I launched my MVP (Minimum Viable Product)and revenues were somewhere in the $300 and $400 a month range. I felt like it was strong enough, that the idea had been validated. And now rather than having just a rough product, it can be refined, built upon.
There were a lot of things from version 1 that I didn't like, in terms of tech debt I needed to address. For example users wanted the job board to be more customizable. So when I was designing version 2 I was like, okay, I need to make one core accent color in the design that can be utilized for buttons and stuff. When it comes to being overwrite-able, add a simple custom theme or branding. Users just wanted to upload their own logos to their job board. So I made sure I'd have a widget in place for that and place it in the top left. If the user doesn’t have a logo, the name of the job board will appear there. It’s small things like that. Adding things users have been asking for.
What similarities do you see between designing and coding?
Something that I took from design school and I carry with me in my career is whenever I was in design school, we'd have projects assigned to us and every couple of weeks we'd have a critique. A day for critiquing, in front of your peers. People just started giving feedback on it. You can't give shallow feedback like “I like it”, or “I don't like it”. My professor, Professor Sedlak, for that class, every time he heard “like” he’d say, “Eh, try another word.” He banned that phrase and encouraged the use of the phrase, “I think this is successful (or not successful) because…” It forces you to go deeper in your feedback. Objective feedback. It makes you give a valid reason for why.
So, in the same vein, I try to do the same whenever I'm doing code reviews with peers. It's my style of code review feedback. It's like, “Hey, I think this is really strong here, but also, I think you’d get better performance if you do it this way.”
We talked earlier about how design is iterative. Code is iterative as well. You always have to iterate and you should not have any sense of personal ownership in it. A lot of things that I designed in school, I just had to throw out and start from scratch. Code is the same way.
Do you feel that your design degree benefits your development work?
Yes, but not in the way of me being able to do it all. More of the way I was taught communication.
Having this design degree and being able to communicate with the designer I worked with. Sometimes something would feel off and I will be able to give feedback on that. You know, like the leading feels a little bit too tight here, could we bump it up a little bit? Being able to speak their lingo and being able to know what I'm talking about helps. And also when people seem to be miscommunicating. I work with engineers and designers and sometimes engineers don't know what it is they're trying to communicate. It's helpful to listen and know what they are thinking about, what they’re trying to say. And then be able to translate what their message is to the designer. Help them craft that feedback.
You can read more in-depth about the lessons Iheanyi took from his design classes in a blog post he wrote titled, "Lessons from Design School for Software Engineers".
Well that is it! I hope you all enjoyed learning from another talented product creator. Please reach out to us if you have any questions, and as always, Happy Designing.