26 Sep

It’s not my job to care what the product looks like, or is it?

Well it doesn’t look pretty, but we’re not designers anyway…it’s not our job.

-Software engineer intern

I overheard one of the interns earlier this summer talking about the project he was working on when he was updating his mentor on his progress. He was working as a client-side iOS engineer for the summer and didn’t seem to think it was his job to make things pretty, just functional.

While there’s a certain truth to the fact that engineers don’t have to come up with good UI/interaction designs for their products (at least at large software companies where there’s dedicated designers for this purpose), this doesn’t necessarily mean that they should turn a blind eye to their “ugly” but functional work.

For front-end/client-side engineers, there are two things that I’ve observed that the best engineers do:

Work hand in hand with their designers to come up with the best experience but DON’T hinder the designer to think big.

In general, the ideal workflow goes something like this:

  1. Based on the requirements, designer and engineering team brainstorm different ideas for the product
  2. Designer takes an initial stab at the designs (alone) with the brainstorming feedback from the team
  3. Designer sits down with engineering team to do a first pass over the user interface and user interaction mockups
  4. Designer takes team feedback and iterates on his mockups
  5. The engineering team does another pass over the new designs
  6. Steps 4 & 5 repeat until both sides are happy

As someone that’s taken a stab at being an interaction designer from an engineering background, step 2 is a particularly important step. This is what is necessary to allow a designer to dream big and not get their ideas immediately shut down by the engineering team. Engineers are generally limited by what they think is technically possible. However, I often see instances where an engineer will tell a designer “It can’t be done” and come back later and say “Wait, I think I figured it out.” They just needed a little bit of time to think (or Google around for an answer) and a bit of inspiration from the design itself.

That being said, the rest of the steps are to bring the designer back down to earth and find a common ground between the design and engineering teams. Sometimes things actually aren’t technically feasible, or there’s just not enough time to implement everything the designer wants.

Push back against designs that just aren’t good enough.

Even though your designer is probably great at his job, he doesn’t always have the right answers to everything. If there’s something that just doesn’t sit right with you as an engineer, say something, even if you don’t necessarily have a solution for the issue. Likely, others on the team will agree with you and then together, the team can find a better way of doing things than sticking with the original idea.

When both the engineers and the designers have a say in the UI, everyone will be much more invested in building a great product. Otherwise, if the product doesn’t turn out quite the way everyone envisioned it, you may have a case of the blame game on your hands – “The designer just didn’t do a great job with the interactions” or “The engineers didn’t understand me and built something completely different.”

Building great and beautiful products is definitely a team responsibility. While everyone has their own roles on the team, that doesn’t mean that as an engineer, you shouldn’t get any say in the design (if you want it). The best designs are not “thrown over the fence” and given to the engineers to implement. The best designs are iterated on, pushed and prodded, fiddled and tinkered with until it just works…for everyone.

25 Jul

How to be a speaker if you don’t have any experience

I recently did a presentation for the Intuit Girls Who Code class – it was the first of many presentations I hope to give throughout my career. Some people seem to feel that public speaking is one of those fears that is even greater than death. I’m not a big fan of being put on the spot either, but with enough preparation (and maybe a friendly starting audience), it can actually be a pretty enjoyable experience. Now, I don’t claim to know it all from just one presentation, but these were the things I used to get started.

The Start

In the beginning, the first two hurdles I saw were:

  1. Opportunity
  2. Topic

Opportunities are actually a lot easier to come by than most people think. Presentations aren’t necessarily shown to hundreds of people at a time. In fact, that’s probably the worst way to get started as a speaker. There are plenty of opportunities around in unexpected places. Here’s some examples:

  • You have a new coworker that doesn’t know how to use Git. Create a presentation and teach them all about the wonders of this versioning tool. (1 on 1)
  • You have a group of summer interns that need to come up to speed on the best coding standards for your team. Grab all that information and create a presentation that’s way more interesting than the boring wiki you normally tell new team members to read. (1 on 5)
  • Worked with some interesting new technology that not everyone on your team knows about? Present all your findings during a lunchtime/staff meeting. (1 on 10-20)
  • Go back to your alma mater and teach your 21 year old self how to do something that’s not pulling all-nighters and partying too hard. (1 on 50-100+)

You can scale your talks accordingly. Start small with friendly people that will give you great feedback…then work your way up to a larger and more intimidating audience. Once you master the few, working your way up won’t seem too bad.

Topics on the other hand…this is one that I struggled with more than finding opportunities. Especially when you’re early in your career, sometimes it’s hard to figure out what would be an interesting topic to teach others about. Topics can be too basic, too complex, too narrow, too generic…the list goes on and there’s extremes at either end.

This one is more personal – what works for some may not work for others. I took some advice from Zach Holman, who has an amazing resource on speaking. In particular, he states that anyone can be an expert on most things if they focus and narrow in on something that they’re passionate about. Even if you’re not a complete expert in that particular area, it’s really about “making your audience reconsider their own perspectives. You don’t have to be smarter than them or even be more correct than them to do that.”

Generally, chosen topics are about something that you have done or experienced personally. However,  another way to think about it is that the best way to learn something is to teach it. If there’s a particular area that you’re interested in learning more about, the best way to thoroughly understand that area is to teach it to someone else. You can’t teach what you don’t know.

Read More

16 May

Are you a bad (software) engineer if you don’t do side projects?

This is a question that recently came up on Quora and something that I’ve personally struggled with during and after college. It’s been especially hard for me ever since I started doing recruiting for Intuit, as one of the things that we look out for in promising candidates (at least at a university recruiting level) is that these students are self starters that have side projects listed on their resume. When students ask me what they can improve about their resume, one of the first things I recommend is that they work on a meaningful side project or get involved in extracurriculars to help bulk up their resume.

For me though, I feel a bit like a hypocrite because spending time on side projects is not something I do on my own time. Working as a full time iOS engineer fulfills my need to build, create, problem solve…etc. – I prefer to spend my time engaged in other meaningful learnings that aren’t as explored in my day job.

That being said, there’s definitely other ways that you can gain knowledge and continue learning without having to do side projects – they can even be your day job! I have a very similar perspective to Tracy Chou’s opinion on the matter – snippet below:

I don’t do side projects and I don’t identify as a hacker, but I do read technical documentation, articles, and books; I do attend (and give) technical talks; and perhaps most importantly, I pick my day job based on learning and growth opportunities: which company I’m working at, which team I’m on, and which projects I take on. I stumbled onto this a little bit by accident, but I discovered that responsibilities in your day job that require you to learn are a great forcing function for learning. 

Aside from these things, I’d also recommend joining Meetup groups and attending technical events/conferences. There’s nothing better than learning first hand from experts on the subject matter, and being able to discuss it with them (networking isn’t a bad idea either). What matters most is that you find what you’re passionate about and make sure that the world knows about it, side projects or not.

****One caveat to this though is that if you are currently a student, side projects are definitely one of the easiest ways to make yourself stand out among the rest of the candidates. I’ll add though, I personally didn’t do that many large side projects in school. I did, however, participate in hackathons and was greatly involved in student leadership. These were the things that made me stand out.