DEV Community: Nathan Sepulveda

A Quick Guide On How To Make Your Designer Happy

Nathan Sepulveda — Fri, 02 Sep 2022 23:09:46 +0000

Here at Asurion, I’ve found the design team to be some of the most fun and interesting coworkers around. Somehow as a software engineer, I’ve infiltrated the ranks and have been invited to their happy hours, lunches, and even bowling events.

Some of the Design team and myself at Donelson Bowl

Engineering and Design are two of the three main components of a Product Team. Asurion uses what we call a Product Team which is made up of 1 Product manager, 1-2 Designers, 1 Engineering lead, and multiple engineers.

Product teams use data and metrics to measure whether they are achieving this outcome and iterate accordingly. Product teams follow agile software development best practices and focus on functional features, not projects.

Product designers often are responsible for the whole user experience, not just the visual components. They try to create typically digital experiences that solve customer and business problems, through design research, testing, and collaboration with engineering and product.

What's The Problem?

An issue I've seen too many times is where some review happens after code is pushed and merged into main, now deployed on QA/Dev, or even worse on Prod, and the designer is surprised to see something different than the designs! They could be small issues like font boldness, incorrect copy, spelling errors, spacing, or even bigger problems like incorrect icons or images.

Let’s face it, it's frustrating to miss the mark after you think you’ve finished developing something. Having to make small changes can be annoying, we all know that. To hear “looks great, but that’s the wrong font size, the alignment is weird here, etc.." can seem trivial, but good design and its execution is in the details. Sometimes these changes stem from a failure to communicate a design update or even that a design itself is unfeasible. Did the designer not clearly convey the goal? Or perhaps it was just an oversight on the engineer’s part.

It’s understandable, as engineers we are often focused on getting the app to function properly and prioritize that above getting the UI to be pixel perfect. For example, I often aim to get the elements roughly laid out and then start hooking things up for the feature function properly. By the end, I have become so focused on the functionality that I’ve forgotten to re-reference the design closely to make sure everything is correct. This could be an honest mistake early on. Hopefully this reputation is fading, but engineers are sometimes known for being grumpy or reluctant to admit they missed certain marks regarding the UI, or sometimes argue even the importance of the target.

However, our design friends worked hard on that design. We owe it to them and the rest of the team to make sure things are precise before we think we are “done.”

"The Solution"

I originally wanted to write this article and reveal that I had discovered the “solution” to this problem and present it in a very actionable, pragmatic way. “If we only did this!” Hoping “this” would be some technical solution or framework we could apply to ourselves. But as it often turns out, the answer is a lot more human than computer underneath it all.

A Dall-E mini generated image using the prompt "a cracked computer screen revealing human muscle underneath"

For this article, I took a similar approach as I did with my last article and decided to meet with a few people from Design here at Asurion at different leadership and contributor levels to get their opinions and insight. Overwhelmingly the "answer" I was looking for was communication and context! Sometimes just saying "we need to communicate better" can get you a pat on the back in some meeting, but let's explore what this can look like.

Say you are a typical individual contributor engineer and you have received a Figma file (or similar UI/UX design tool) with something like this. Ideally you've had some communication and have been involved on the conversations leading up to receiving this file, maybe even had some input on the feasibility of the design from an engineering perspective.

Angie Li, Senior Manger Design, and myself discussed the attitude that engineers can be too satisfied with simply receiving the assets and design and being told what to build. There can even be reluctance on participating in the overall design conversation. I've personally heard the words, "I don't care what the design is; just tell me what to build." The more collaboration and communication before a hand-off, the easier it is for everyone to do their job well.

Coran Lapierre, Senior Principal- DesignOps, took time with me to look over some of the various ceremonies designers and the product team do/are encouraged to do as they begin building a large scale feature. Many of the processes focus on trying to clearly understanding the business problem and iterating over it the larger product team with ceremonies like Kickoffs and Background Briefs. Some of these ceremonies happen at the beginning of a new initiative, but some can happen ad-hoc such as a design review where the designer shares with the rest of product team any updates or development on the design. If you have the opportunity to attend these larger cross-functional meetings do so. Try to go out of your way to understand the whole product lifecycle and the steps that lead to you actually receiving the designs that you are working from. It can really illuminate the designs and enable you to more effectively from them.

Clear Line of Communication

You've done your due diligence in understanding the product and the features and now you actually have the design. Both Josh Sullivan and Ann Bomar, Senior Product Designers, encouraged engineers to establish an open line of communication while you're working on a new feature. "Don't ever feel like you're bugging", Josh said. If you have questions are unsure about something, don't assume too much. Your approach can be as simple as a Slack message saying "Hey, can I show you this?" Sometimes you might need some quick feedback, but other times you may need to show the designer that there might be some UX considerations not accounted for. Ann mentioned a an instance where she was unaware that a transition from one screen to the next required an API call and would need some sort of transitional state to be reflected in the UI while the data loaded. Stay connected and updated with your designer as your building things out!

Understand the Tooling 🛠️

If your team is using Figma, learn how to use the tool from a developer perspective. Most design tools including Figma will have an inspect mode where you can observe and copy property values for UI components. Here is an article specific to Figma. If your team is using a different tool, take time to understand the inspection features. Additionally, ask your designer for any tips or tricks on navigating the files; as we know, keyboard shortcuts can go a long way in terms of efficiency!

Does it look black? It’s probably not.

"You might think it's #000000 but it could be #111111" says Ann, somewhat facetiously. In all seriousness, things may not always be as they seem. Look closely at the inspect tool!

Common pitfalls in building out designs are made from lack of attention to detail and making assumptions. Double check the details against the design and make sure you are using the correct font weights, alignment, spacing, etc...

Never Build A Button From Scratch, Or More Than Once

At Asurion, we have a great UI library called AsurionUI that maps to the Asurion Design System. You'll notice in the above picture that in the Inspect panel has a section labeled "Component Properties" and above it "Button". The 🟢 next to Button shows that this component is ready to use and implemented in the AsurionUI library. The component properties correspond with React props that you pass to the component. Ideally and in most cases, that's the bulk of what you need to get the button to match the design! If you are an Asurion software engineer working on the web, you are likely familiar with this component library. However there might be a case where a newer engineer might not be that aware of how the system works and might develop begin to develop a component that already exists. Take time to show each other the ins and outs of a system like this and how it is integrated on Figma and through the code. If your organization doesn't have something like this, consider developing it! (Easier said than done :))

One Last Thing

Lastly, no one likes making small content changes in the code! Changing the wording from "Continue" to "Next" on a button is not my favorite or most productive code change to raise a PR for. But sometimes, we code the wrong copy in, or the copy itself needs to be changed. Many teams at Asurion are using Contentful to manage their content: everything from images, icons, copy, and even localizations. If you take time to implement Contentful into your product, it can see both yourself, Design, and Product some headaches in updating or correcting your projects copy and make everyone happier!

Conclusion

The takeaways that I learned from talking to the Design team are take time to understand the context of what you are developing, communicate early, often, and effectively when it comes to building out the designs, and learn to use the tooling effectively. Respecting the designer perspective and having empathy for the different functions of your team can go a long way in creating a strong, productive, and successful team! Mistake will still happen, but I can assure you there will be less if you consider these tips!

I Thought You Moved Here for Music?

Nathan Sepulveda — Fri, 22 Jul 2022 22:47:00 +0000

The process of preparing programs for a digital computer is especially attractive, not only because it can be economically and scientifically rewarding, but also because it can be an aesthetic experience much like composing poetry or music.
-Donald Knuth

Nashville is well known for being “Music City”. Like many, I moved here to pursue a career in music, but how did I find myself in tech as a software engineer? The path was somewhat improvised. I used to think my life was going to follow a pretty clear path, but it has been much more open-ended and unwritten (like the cover photo) than I would have expected!

When I was interviewing with Asurion, I had mentioned to one of the interviewers that I was very involved with music: playing piano and guitar, writing, teaching, even producing. In fact, at the time I was currently working as a software developer at a music-based learning company that used music videos to teach math. The interviewer related to me that there were many musicians that worked at Asurion as software engineers, and that they had done pretty well. I agreed with him, thinking it might help me get the job.

That being said, there are a few common assumptions about being a musician that may or may not be accurate, one in particular is that we are good at math. I can assure you, I am mediocre at best when it comes to math. However, what I would like to do is start spreading the notion that musicians make good software engineers!

This article is takes a look at my own story and a small group of software engineers that work at Asurion that are also musicians. I’m hoping it not only puts the spotlight on this general group, but that it might be encouraging to others that come from a creative background, particularly musical, that are interested in breaking into tech.

An Improvised Path

I think I was a pretty boring kid. Imaginative, but not with too many interests other than video games. It wasn’t until middle school when I started playing guitar and piano that I learned what it was to have a passion. From about 14 onward, all I could really think about being was playing music and being some sort of professional musician someday. I played 4, 5, 6 hours a day. I played at church, I played with my friends in the garage, I played in my bedroom quietly late into the night. When I was a junior in high school I decided I wanted to go to earn a music degree with the hope of gaining the skills and connections I needed to become a film composer. The intensity only increased, I played more, wrote more, and practiced more than ever. After I graduated I decided I wanted to move to Nashville to be around a more immersive music scene and pursue a master’s degree at Belmont University. I did just that. However, about halfway through my degree I started to explore programming because I had a crazy idea in my head that I could make a computer understand emotions and turn it into music.

EmojiMusicInteractive. My thesis project that uses facial expressions to create and manipulate music

  My only previous experience with programming was using the Automater tool on macOS to batch rename a set of files and brief exposure to the Max/MSP programming language that by one of my music composition professors. I had known one friend that was working as a developer, but my interest expanded my partner at the time decided to enroll in coding bootcamp here in Nashville. While she was studying I saw glimpses here and there of what web development was and being a curious person I asked as many questions as I could. Coincidentally, I had a thesis project to do for my master’s degree, and I became obsessed with the ideas of music psychology in relation to emotional expression and perception and the musical structures that convey these emotions. And then I had an idea: can I incorporate a computer as a semi-intelligent agent exploring these topics?   I spent over a year exploring these topics, learning about programming, machine learning, the psychological models of emotion, and created EmojiMusicInteractive, a musical computer system that detects emotions in facial expressions plays, modifies, or generates music based on the incoming emotional expressions. It was so much fun and I explored a pattern of thinking that was so new, but that gave me a similar sense of fulfilled curiosity, in some ways deeper, that I had felt when writing or arranging music.   I learned so much! And needless to say, I was hooked on programming from there. Within weeks of my graduation I was enrolled in Nashville Software School’s web development bootcamp here in Nashville.

From my first dev job at Muzology. Along with development, I also got to play guitar at the difference education conferences we attended.

Fast forward to today, I have been doing this professionally for a little over 3 years at a company called Muzology and Asurion and have worked on a variety of projects from computational music research, mobile iOS development, and web development. I am currently a Software Engineer 2 at Asurion working on the Connected Home Web team.   My musical background certainly led me to this point and I am still very involved with music today with my band, Nite Tides, my students, and my production work. I also strongly believe my musical nature affects my thinking when it comes to software development.   That’s just one story though. I was told did that there were many other musicians working here at Asurion so I reached out to a few to get some different perspectives.

Meet The Band At Asurion

Stephen Parsons, a Software Engineer 4 on Platform Team for Horizon Web developed a passion for music in his teenage years: “I started playing guitar around age 13 after discovering the band Green Day. Around that time I didn’t do much else except play guitar everyday, discovering more music and eventually starting bands with my friends in school.” He also had someone close to him expose him to software development and decided to make the jump via the coding bootcamp path; “I was frustrated and felt stuck in my pervious career and working as a musician, and I knew I wanted a change. My brother was doing his computer science degree (and works for Microsoft now) and after asking him of advice he suggested checking out a coding bootcamp, specifically CodingDojo. I signed up, quit my job and immediately started learning the fundamentals of web dev, html, css, javascript, etc. before starting the course.”

Check out Steven’s band Sun Casino

Like myself, Sam Bender an Software Engineer 1 on the Replacement’s team and MaryEllen a Software Engineer 3 in the enterprise architecture department studied music formally in college. Sam studied a dual major in both Computer Science and Viola performance (at the time of writing he is currently on an East Coast tour with his friend’s band). Mary Ellen “studied both classical voice, jazz, and music business while playing in 3 bands on weekends”. She “low key started coding my band's website in my free time. Fell in love first with CSS and front end basics. Then started teaching myself JavaScript via CodeAcademy and Treehouse… Eventually this led to attending a code bootcamp in 2015, followed by a job offer at an ad agency as a web dev.” A similar story to my own.

Checkout MaryEllen’s music

Here's a recent project Sam worked on.

It is not uncommon for musicians that were working professionally prior to software engineering to take break into the field via a bootcamp, however many developer-musicians studied computer science while maintaining their interest in music independently. Oded Welgreen, a Senior Principal Software Engineer who produces generative music writes, “I was always good with computers, starting with the logo language at kindergarten. Played a lot of video games and learned Pascal in high school. Studying computer science felt like a natural continuation.” Rohit Sam a Principal Software Engineer and guitar player expressed a similar sentiment, “I have always tinkered with computers since I was younger. Taught myself how to "program" in VB/Autoit to automate stuff on the computer. Thinking back to my scripting days, a career in tech was always a natural and expected end goal.” Madelyn Reyes an Software Engineer 2 that produces music under the name Madebit stumbled upon software engineering in college, “I randomly interned at a computer repair shop before i started college where I enjoyed fixing computers and thought i might like to study IT in college. I signed up for computer science not really understanding what it was - my only requirement for college is that it had to be something that was challenging, and computer science fit the bill. So I continued with the major, alongside doing internships (some in IT, help-desk work and others in actual programming) and extra programming projects on the side.”

Checkout Madebit and Oded's Music

This Is Your Brain on Music

A Dall-E mini generated image using the prompt "a brain playing piano and typing computer code on a computer"

I find that writing code engages my mind in a way similar to writing or arranging music. I find an abstract correlation between being a musician and a software engineer. Each participant had their own take on the relationship between the two parts of their minds, with some seeing a clearer connection than others.

Madelyn - “There’s a lot of studies that have shown that people who enjoy making music are drawn to professions like software engineering and similar fields. The big correlation i see is in the fun of problem solving, creative expression, and autonomy - whether you're making a piece of music or writing code, you're creating something thats not really tangible in a physical sense. You can't touch or feel a song/code in the same way that you could touch a chair or a sculpture, and I'm certain that it occupies a similar brain space.”

Mary Ellen - “Using both parts of the brain at the same time is required for both. The logical steps mixed with the creative problem solving, the improvisation, and critical thinking, and knowing there is more than one solution. Especially music theory.”

Sam - "I’m not sure if I’ve personally noticed a lot of direct correlation between my music and engineering lives, but for me it means that I’m able to engage all areas of my brain in a given week. When I finish up with work, I can turn to music, and I find the whole arrangement to be very fulfilling.”

Rohit - “The creative aspects of software engineering sometimes remind me of a well written piece of music. But that mirage quickly fades when I look at actual production code. Perhaps the tinkering with the guitar and pedals and achieving the perfect tone can be correlated to debugging a software problem until I solve it? But then again, I've never pulled my own hair out because I couldn't nail a tone – production code on the other hand is a different story.”

Stephen - "There is definitely a correlation, although it may be different for lots of people. Both music and engineering require creativity. In western contemporary music you have only 12 tones but an endless number of possible ways to utilize them when writing a piece or song, where many rules and ideas exist on what is pleasing and what should or shouldn’t be done. In coding, you have a similar framework with which to solve an engineering problem. Raising a PR is almost like performing a new song in front of an audience for the first time, you have to prepare yourself for feedback and be open minded. In both disciplines it is also encouraged to borrow ideas from others!”

Oded focuses in on modular synthesis - "I 100% see correlation between modular synthesizers and software engineering. Both involve an element of exploration ("what would happen if I do this") and exploitation ("I want to this, how would I do it"). Both involve using building blocks to build an "architecture". Even debugging is similar in nature (using oscilloscope for "logging", systematically following the flow of the system to pinpoint where the problem is). I would also equate playing in a band to working in a team - giving space for others to express themselves, enhancing each others strengths, strong communication etc.”

Conclusion

As you can see, there are many perspectives when it comes to musicianship and software engineering! Regardless, I think there is a case to be made that musicians, regardless or background, have patterns of thinking that lend themselves well to being software engineers. I hope whether you’re a musician that is looking into becoming a software engineer that this article was inspiring, but also if you’re a musician-engineer already I hope you’re discovering there may be more like you than you realize.

Coda

If you are a musician-developer, I highly suggest working at Asurion. I've found so many people here to be supportive of the me and my band from seeing our shows, buying our merch, and even being asked to play for Asurion events!

Poster for Nite Tides show at Asurion Gulch Hub