Beyond the Binary

View Original

Pixels And Purpose: The Artistry Of Front-End Engineering And Inclusivity In The Tech World

Front-end engineering is the canvas where pixels meet purpose, crafting digital experiences that shape our online world. In this episode, software engineer Stacey Shkuratoff takes us to the world of front-end engineering as a neurodivergent individual in the tech field. She dismantles stereotypes and underscores the vital role that pixel-perfect attention to detail plays in crafting exceptional user experiences. But more than her experience in the tech world. Stacey also candidly discusses how she champions diversity and inclusion initiatives within her organization. She emphasizes the importance of amplifying the voices of underrepresented groups and promoting an environment where everyone's ideas are valued. Tune in to unravel the mysteries of front-end engineering, personal growth, and the strength of community.

---

Listen to the podcast here

See this content in the original post

Pixels And Purpose: The Artistry Of Front-End Engineering And Inclusivity In The Tech World

We've already talked about this. I'm going to mess up your last name.

My last name is Shkuratoff. My first name is Stacey.

Where does it come from? People ask me about my name all the time because it can be hard to say, but I’m curious.

It comes from a Russian subset of Christianity called Doukhobor. There are about 500 of us that still exist, mostly in small towns in Canada, British Columbia, Alberta, and Saskatchewan. What makes us special is we're interested in toil and working. We also believe in the 10 Commandments as literal rules like thou shall not kill. We are pacifists. We got kicked out of Russia for that.

Maybe this is not for the tech show, but I'm curious. Are you religious? Is this something that you care about? Five hundred is not a lot of people, so that puts some pressure to continue on with that legacy. I don't know.

It does a little bit. Probably my generation is the first generation that doesn't necessarily practice, but most of us are still vegetarians. My sisters and my cousins are. It’s a 50/50 split. Most people don't go to church like they used to. They still teach Russian and elementary schools in these small communities so you can learn Russian. It’s like Canada French is to French-French as the Canadian Russian is to the Russian-Russian. It's a casual dialect.

We have gone over our first tangent already. That’s wonderful. This is what happens when two people with newer divergent brains end up talking. It's going to be wonderful. Let's dive into your journey in tech. Can you share a little bit about how you became a staff software engineer? Highlight some of the critical milestones or experiences that got you here.

I got into tech a lot later. I took my first programming class when I was in my first year of university as an elective. At the time, I was good at math and physics. They would encourage women to go into the sciences. The entrance rate for engineering was 16% for women at the time. You went into sciences. It's what you did. I almost got a dean's vacation, which means if you get 55 or below an average, they make you take a year off and come back. I got a 58, so I stuck with it.

I took Humanities the following year and Math. I was good at math. It lifted my grades. I then applied for engineering. I thought I wanted to be a mechanical engineer. I ranked all of your preferences. I ranked mechanical first and computer second. My sister was in the computer engineering program already. I did not have the grades for mechanical and ended up in computers. It was all an accidental thing. I never thought that I would be where I am.

I didn't do any web programming. Computer engineering is like a combination of electrical engineering and some software engineering, but it has a focus on hardware. It’s building processors, microcontroller stuff, and embedded software. Although I had two internships, neither of them was necessarily embedded. When mobile phones were getting games, I was in device integrations. You had to port this Java micro edition application to thousands of different phones. You could use a preprocessor to check which phone it was and then execute that section of code. It was a wild time for mobile phone development.

How did you find a way to do what you do once you got into tech?

Once I got into tech, I had a couple of smaller startup jobs, and then I got my first real hardware job. I show up on my first day and they're like, “The hardware team isn't ready for you. Join the web team.” I've never done any web programming. I had done sockets once in my third year of university. That's how it all started. I ended up staying in the WebSphere. There was so much potential. That was during the recession. We've had several since. That was how I got there.

That's cool. What about web development? What about frontend development kept you going to find your way to staff engineering?

I've had a bunch of different jobs anywhere from Vancouver to San Francisco to Portland to Sydney. Every time I get the job because of my hardware skills, somehow, I end up migrating to the front. What that gives me is a base of all backend understanding and then with the love of the front end.

I wonder. Sometimes, I quite enjoyed the creative side of front-end development. Any code development can be creative, but when it comes to the front end, there's a tangible aspect of it. My brain loves tangible things. Would you say there's an aspect that pushed you or did you end up finding your way towards the front end?

It's that dopamine hit us neurodivergents are known for. I'm like, “I can do this. I can see it,” or, “That's broken and I can see it.” I don't have to wait for this large build or turnaround process that most people have to wait for when they're doing backend development.

Let's talk about leadership in the technology sector then. Largely, there is this myth or this notion that managerial positions are the ones that usually have most of the leadership aspect to it. You and I both know that is not the case as a principal engineer myself and then you as a staff software engineer. How do you see yourself leading without necessarily being in a managerial position?

I was the principal engineer at my last job, and I got promoted because I took on all of the projects all at once and they all still survived. I had a huge basis. The principal engineering job is for a technical lead, a key decision-maker, and a stakeholder. The staff engineer job that I do this time is a collaborative get-consensus style job, so I don't lead a team and I'm not on a team. I'm more of a resource. I get to do a lot of research and then I get to teach people about it. If I get a good idea, then we'll get together and build it. I may or may not be the person that gets to build it.

You are leading by sharing different projects that could be possible. Is there a mentorship aspect to your job, too?

Yes. There are four parts to the job. There's an individual contributor code that I make, build, and deploy. Then, I have squad-level stuff, which is that leadership or that mentorship. I work with 4 or 5 different squads at a time. There's a companywide initiative where I'm meeting with other staff engineers so that we can knowledge share and not duplicate the same efforts.

This brings up a great point because front-end development itself is big on collaboration. You really need to work with the hardware team. You need to work with the backend team to get things or the APIs that you need and the answers that you need from the database. You on top of that are collaborating with multiple teams. There's a level of collaboration within the team. Your job is collaborating with different front-end engineers. How do you foster an effective collaboration between frontend engineers and other teams or units such as design and backend development as well as the various groups within your organization?

Our designers, our front end, our back end, and database people are all on one team. We're outcome-based so what are we going to get out of it? We have one person from each of those things when we're going to build something. Communication there is usually pretty good. Usually, there's a researcher who does their work first. The design creates design. We do some iteration between the front-end folks and the designer. We work with our backend engineers to create the data that we need. That data may come from within our team. It may come with another team. It really varies. People move across teams a lot. There's a fluidity to it.

Is there something that you have implemented or a process that has helped you make sure that there is a flow of information in a seamless way?

It’s meeting with people regularly. It doesn't have to be long conversations. It can be short. With our staff engineering meetings, every couple of weeks, we'll go through and be like, “What are you working on? What's new?” That constant flow of ideas is the best way to create collaboration because two teams might be working on the same idea at the same time. That's engineering in a nutshell right there. They’re all slightly different because the code is very opinionated. If I would implement something one way, that does not mean that somebody else would implement it that way. Neither is wrong, but you can sure argue about it for an hour and then come to, “Both are good,” and move on.

Just because you would implement something one way does not mean that somebody else would implement it that way, and neither are wrong.

Let's talk about that. Let's dig into that aspect of it a little bit. As a staff engineer, I bet you've had to calm people down or bring them off their high horses and be like, “You two are working on slightly similar things. You two both have great code and it does everything perfectly, but at the end of the day, we still need to combine these things.” Is there any situation that you can think of? You can pick one because I'm pretty sure you have encountered it multiple times. What is your approach to handling those situations?

The specialization I find myself in is what we call micro front ends. That's where you make several different websites and combine them into one unified experience. When I started at my job, there were four different implementations of this particular phenomenon. They're all using the same web pack module federation technology but all of them load slightly differently. They bring different parameters with them enough to make them not compatible with each other.

What we did was we got together and made a working group that's representative of each of these different implementations. Instead of trying to convert one to another, how can we make them compatible so that we don't have to change how they're being built but we make them compatible with each other? We can converge them into one single type later but still have that compatibility. We're not reinventing anything. We're getting to a solution that we can all agree on. It doesn't have to be perfect. It has to be available to everyone. Once we get that, we can finally contribute to one central place. That's one of those communications. People want to be heard and have their voice at the table.

Front End Engineering: Instead of trying to convert one to another, how can we make them compatible so that we don't actually have to change how they're being built?

It’s having them converge and come together towards a goal or a project together. It is like, “This is our team. We are doing this together,” and not pick and choose. I see what you did there.

Those teammates all have regular priorities and customer-facing goals. I do not. I'm taking on the convergence portion of that. That's where my focus is. I am trying to make this compatibility happen.

How much would you say your job is coding versus other aspects of it that you talked about?

It took me almost six months to code at my third job. The communication breakdown was so high that I had to meet with all of these different departments and figure out what exactly was going on. I look at the political structure of the company and find the right voices to bring everyone together.

This is something that I have personally been struggling with. I was part of it. Is there an aspect of being good at the “political”? Is there an aspect of politics that comes with the higher-up you go? Speak to the aspect of neurodivergent brains and how we struggle to make some sense out of it. I don't want to speak with all neurodivergent community, but you and I personally struggle with that part.

I got diagnosed with combination ADHD, so both inattentive and hyperactive, in 2022. It makes a lot of sense with my personality. I'll talk about something and forget and then talk about something else. People are confused. In terms of navigating the political landscape though, I did a really cool program in San Francisco where I worked with an investment firm. They brought together all of these engineering leaders. We learned how to navigate that. We would problem-solve as a group. I recommend that.

A lot of companies have employee resource groups. When you run into communication problems, that's always a good place to get feedback. They’re like like, “How do I approach this person?” You work with them, too. They’re like, “I want them to see my point of view or I want to know their point of view.” With the staff role, that's even more important because you have no authority so you have to get people to agree with you in order to get anything done.

Front End Engineering: It is recommended that a lot of companies have employee resource groups and so when you run into communication problems, that's always a good place to get feedback.

At first, I found it challenging. I then find it exciting. There are some features of my brain that other people's brains don't have. I can read your face and know what you're upset about before you even know. It's a superpower. It’s that little hyperfocus. I can see all the little muscles move in your face or I can hear that change in intonation in your voice when you get frustrated or talk a little faster.

Is that something that you were good at from the beginning or is this a new hyperfocus once you got that training and you were like, “This can be fun.”

I worked with an ADHD specialist to hone some of these skills. Before, I had high anxiety. When I was solely an individual contributor, I would put so much pressure on myself to get work done. I would set a deadline and I would wait until half an hour before the deadline and then complete everything. What that caused me was this horrible anxiety. I didn't know how to sort tasks, prioritize, or go through that process. I read a couple of books. Your Brain's Not Broken is a good one, which is an ADHD book. I highly recommend that for anybody who's on the spectrum.

For me, it's the same scenario. I got diagnosed with a combined type as well. It's been a year of trying to figure out. We get things done, but the way we get things done is so stressful to other people around you but also to yourself but don't realize because you're in the zone and trying to get it done. Later on, you're like, “I am exhausted and burnt out. What happened?”

Burnout is a real thing. I've almost left the engineering profession a couple of times because of burnout. After my first big tech job in San Francisco, I was given this HTML email project. I worked at it hard and it never really came to fruition. I didn't have any mentors on the team or people I could go to. No one had implemented it because that functionality was new. That took a toll.

The second time was in a job when I was doing all the things. When I got promoted to principal, I put so much pressure on myself that I could feel my ability to work diminish. I thought I wanted to be an architect so I did architecture classes at the same time as all of that burnout. I was like, “I need to be an individual contributor or something like that to reign it back in.” I ended up with the staff role instead, which worked out perfectly because I got to do research and proof of concepts. There are tons of variety. I work with tons of teams. I don't have any actual set deadlines. I set my own times.

I love hearing that you set a goal and were like, “Maybe not this isn't for me. I'm going to take it back.” You find what works for you. You create a system that works for you and create a system that you can thrive in. I love that.

We have to look at the concept of failure. If I tried for this architect role and I didn't get it this time, it doesn't mean that I'm not going to get it later. Everything comes in due time. With this neurodivergent brain, that dopamine, we want it. When we don't get it now, there is horrifying disappointment and some sort of shame like, “I'm not good enough,” or, “I'll never be good enough.” We have to change that into a different narrative which is getting up and giving yourself a high five and being like, “I showed up today. I made an effort.” Sometimes, laying on the couch is your effort because we're worked out, and that's okay. Change that narrative and be like, “This is fine.”

We have to look at the concept of failure as, "I didn't get it this time. It doesn't mean that I'm not going to get it later. Everything comes in due time."

This is how I view time. It’s now or not now. There is no other way to look at time for me. This is how I end up tackling projects. Being aware of that was great for me. In my head, if I “fail” at something, it is not that I failed at that one thing. I am a complete failure.

That's a black or white thinking. It’s a real phenomenon. It's like, “I am horrible or I am awesome.” Neutral days are so few and far between.

My partner, this is before the diagnosis. He was like, “You are sometimes so proud of yourself and it's amazing. On other days, you are trash and garbage. Everything you do is a disaster.”

One of the things I did at this job that I did not do at another job was I told my manager all the negative feedback I had received at my previous job and then told him what I needed help with. I was disorganized. I missed deadlines occasionally. I really had a problem with prioritization so we meet once a week. He was like, “What are all the tasks?” I have a rocket book and make a list of everything I want to do, which is way too many. He sorts them for me and then I start my week.

That is amazing.

Those can change at any time and I may not know all of the things that he does.

I love that he's also supportive of this. There are scenarios in which sharing your diagnosis or your mental health is not a good idea. It sounds like you were able to do it and they supported you with it. I love that your manager is like, “I'm going to help you prioritize this.” This is amazing. This is a great story.

It started with the ADHD diagnosis not a fully diagnosed neurological condition, which gives me numbness in my hands and my feet. I had cognitive issues and fatigue. I exacerbated all of my ADHD symptoms so it made them way worse. Sometimes, I need to take a nap during the day. I take a nap every single day. It's fantastic.

There is this fear that people are going to think that you're weak, speaking of diversity and inclusion, if you have an illness or you have a neurodivergent personality. We need to break that stigma by becoming that example and telling people that we're unwell or we're having an ADHD day and we need to take that half day off and maybe do it on a Saturday. I don't see anything wrong with that.

If you have an illness, or if you have a neurodivergent personality, we need to break that stigma by becoming that example telling people that we're unwell or telling people that we're having an ADHD day.

Executive dysfunction is a thing that happens to us where it’s bad. Some days are so bad that nothing can help you. No amount of getting small tasks to give you that dopamine is going to help.

I become squirrel fest, which is squirrels when they're outside. It’s like a little squirrel festival. I get nothing done. I do 30 seconds of each task all day, and then if it has gone on for a few hours, I'm like, “That's it. It's time for a nap.”

That's a good idea. I've been recommended naps before, but I grew up in a household where naps were not allowed. My brain doesn't do naps anymore. I’m almost 34 and it's like, “Come on, brain. We can do naps.”

My mom was all about napping. She used to tell us this story. We fall asleep on the sofa and she'd be like, “Let me tell you about the napping. To go get the napping, you must first close the blinds.” She would lead you and tell you this story about the napping. Before it was over, you were unconscious. It's like those nighttime podcasts. If you ever listened to the moving meditations, there's one called Get Sleepy. I like the golden day on a pirate ship or something. They tell you a story about a pirate ship. Before you know it, you're asleep. Those are very helpful for daytime naps because it's noisy and my brain won't shut off. That's when they're good.

That is a brilliant idea. Also, you had Calm and all those apps before they were invented.

I can't do the mindfulness ones because the inside of my brain is buzzing. There's no way I can sit quietly and pretend to feel my hands because that's not going to work for me. Stories and visualizations do.

Our brains do like that. If they talk about a little town, my brain is going like, “There's a little town. People are walking around. There are little cutesy shops.”

I have a very vivid inside life. Often, people who are neurodivergent will envision conversations that will never come to fruition. You could see the other person's face so you've already planned for something that will never happen. That's why those visualizations are better for us. Rich in our lives.

I'm learning so many terms that I'm going to use after this. Also, coming back to the front end, leadership roles. You touched upon this already, but what advice would you give to junior or mid-level front-end engineers who aspire to grow into roles like yours? Are there any specific steps or experiences they should consider or look into?

The ADHD brain has been really helpful because I can do everything all at once sometimes. It’s an obsession with my craft. I want to be the best at this particular thing. There is perseverance. I find hard problems that nobody else wants to do and make them happen. Come hell or high water, that's going to happen. My biggest promotions come from these projects that nobody wanted to work on but were critical. It's usually me islanding with maybe 1 or 2 other people. I work better in small groups. That whole obsession part of it too and keeping, learning, and honing your craft. I do not do well at learning at my own pace. I have to take online classes. I have to read books. I can't be like, “I heard about this thing,” and then go learn about it. That's never going to work.

I hear that part and I find that very interesting where you're saying you took this class for architecture and things like that. It sounds like you are taking those courses and workshops. Is this usually through your company or you are investing in your own self?

It depends. Usually, you get education stipends. If it's something that I need to pay for, then I will ask for money for it. I did stuff all on my own. Think of AWS Coursera. For example, I worked on this chaos engineering tool without knowing anything about DevOps. I'm like, “In order to serve my customer,” which is a DevOps person and I was doing front end, full stack, web development but no ops, I went to the chaos engineering conference. I did the Google SRE training, and then I did the fundamentals of AWS course on Coursera in order to serve my customers. They're tangential things. That's what gives you that broad scope. There's that obsession piece. I have to know everything about what they need before I can build it.

I hear you on the obsession piece. The promotions came from projects that had to be done and were critical but weren't thought of. I remember working on a project like that. It was after that project or they used that project to make a case from a principal engineer. It came to me that it was me and this one other person. I was leading everything. The project manager left the company halfway through it. Our brains love complex problems and things that we don't know anything about. Even for a neurotypical brain, going and getting those classes, trying to solve those hard problems, and keeping going at it is generally good advice.

There is something about you talking about that dopamine. Getting those little certificates or those achievements and then putting them on my LinkedIn is the reward for me. I'm like, “Look at my street cred. I am awesome.” That's one of those proud days. Although I usually do all of the classes in two days because I've waited until the end of the semester. Killed by caffeine. Caffeine and garbage food are how it happens.

Whatever works. What are some of the common misconceptions people have about front-end engineering? How do you address those misconceptions? This question is coming from a place of being a frontend engineer and noticing that people are like, “This is a last-minute thing. This will happen.”

Most of the misconceptions come out of people who are not necessarily programmers or people who have been in that industry longer in higher-up management positions. They don't value the front end as much because they came from a time when everything was server-side rendered. The heartbeat of your web application was the server.

We have client-side rendered applications served through A CDN, which is a Content Delivery Network. That’s static code that your browser knows how to run. If our web applications are taking money and your front end does not work well and it seems sketchy, people are not going to give you their credit card information. You're not going to get paid. That has changed the way that people feel about front-end work.

When people hear about it and they're not necessarily in what I do, they're like, “You write HTML.” I'm like, “I haven't written straight HTML in five years or CSS. All of this stuff is JavaScript-based frameworks.” It is mostly React. That seems to be what everybody is using. It is like an HTML-looking language but has the functionality of JavaScript. It is like HTML and JavaScript had a baby together.

Also, CSS.

I don't even do CSS for the most part because we'll use themes, themes being like injectable frameworks. I do almost no CSS ever. I'll do a line, but that will go in conjunction with a theme. If you're building micro front ends and you're trying to make a unified experience, all your styles have to come from a unified place. If you change one style, it changes for all of these different applications.

Is there any other misconception that you can think of other than a server-side?

One of the misconceptions would be that we are messy programmers. In the old days when you used HTML and jQuery, for example, you would throw some on the page or insert it over here. With frameworks like React or even server-side rendered but with node-like things like Next.js, there is a massive code structure inside of it with good testing resources. Cypress does all of the integration testing frameworks. There's a lot to it. It has become a lot more stable and usable.

Let's talk about like advocating for the frontend technology stack. You mentioned a bunch of technologies. What are some of the critical aspects you focus on? How do you champion the importance of front-end development within your organization?

A lot of my staff is focused on how we deliver the code to the browser. We upload our code to an S3 bucket. It is accessed through a DNS that leads to an AWS resource that leads to a CloudFront which is a CDN distribution, which loads that code. CloudFront lives on the edge. There are all these different locations all over the world. It delivers these pieces of code quickly.

If I've got one piece of the code that changes but is also cached in the browser over here but is cached at this content delivery network over here, how do I orchestrate to invalidate all those at the same time so you get the freshest and latest features? Caching is really complicated. The two things that are hard in software caching and naming things. I do a lot of caching.

This one is close to my heart. As a staff software engineer, especially as a newer divergent woman in tech, you have a unique opportunity to leverage your senior leadership platform to advocate for underrepresented and minoritized groups in tech. How do you approach your position to promote DEI initiatives or create inclusive environments and then amplify the voices of those who are often marginalized or overlooked?

Showing up as my vulnerable self. There are days when I'm grumpy or I'm frustrated. I’m starting with the emotional level because that's something that everybody can agree on. We all have bad days. Also, if I see that somebody else is having a bad day, it is having those conversations about it. I do have a personal vested interest in the people that I work with.

That's something that everybody can agree on. We all have bad days.

When it comes to being a woman at my level, there really aren't that many of us. Statistically, we're less likely to be promoted. We don't apply for things if we don't have all the skills right away. We get pushed into management roles where you're supposed to be emotionally in tune. With the way my brain works, I'm emotionally in tune but I don't have the organizational skills to do a management job. I worked as a project manager for four months. It was horrible. I never want to do it again. I can barely keep my own schedule. Can you imagine keeping the schedule for different people? Somebody else keeps my schedule. It's very important.

I will encourage women or people of color to apply for those roles that they may not be promoted into because of internal bias. As somebody who's not in a management position or necessarily above somebody who's in a different role, you have a unique ability to encourage people to be like, “You have most of these skills. You can work on developing that skill and apply for the job or you can do it at the same time. Show them you're already working on it so they can see that potential.” It’s encouragement.

Is there anything in the interview process or anything on those lines like getting those folks in the door? Has something worked? Are there any initiatives that your company or you are working on or thinking about?

I don't know if we do this in our company, but I know at my last company, we did the blind. They take the name and any educational background off when you first review the resume so you look at the skillset. I also tried when I used to hire for my own teams to try to find people who are not like me. Homogenous teams make homogenous products. Diverse teams make diverse products. I always use the original iPhones, for example. Even cell phones. My hands are so tiny it's so hard to hold a phone. I'm like, “I bet you there's a big dude with a big hand that made this phone.” They don't think about that. You want to have as many different voices and different backgrounds in order to make that product that works for everybody.

I was listening to a podcast. They were talking about how there's a notion that tech does not have or code does not have any opinions, but it does. The person who's making it or the person who's running the show or designing it is the one who is giving it an opinion. That's the opinion that the code has. It’s your product or your phone.

I worked on a team that did a scholar project that told me that scholars are strongly typed functional languages. They wouldn't put comments in the code because should be able to infer the types. I was like, “That's not a thing.” I'm on a team that uses TypeScript and they comment on everything. It could be the smallest piece of piece of code. Although it looks like it blows the repo, it doesn't. It’s helpful.

You are not always going to be there to explain that code or help someone infer what that type means.

Also, you may have left the company, too. At one of my jobs, I inherited this older application that was four different teams deep. It had a C-sharp server-side rendered app with a Mongo database. It was partially taken out. It had a scholar backend and a MySQL database. There was not a comment in the whole thing. No test, no logging. We found out one of the servers was in somebody's office in Shanghai. That's the kind of stuff that documentation is so good for.

Everybody can benefit from writing more documentation. Those of us with neurodivergent brains may not follow the code in a linear order because we don't think linearly. Sometimes, having that documentation can really help. That's an accessibility thing. Even though you're like, “You should be able to get it if you're a junior,” you may not. We have to think about the level of diversity as well. If you have all principal-level engineers, nobody's going to want to do that CSS. You got to have diversity of thought, diversity of level, diversity of gender, and all those things in there.

On that wonderful note, in your experience, what essential skills or qualities make a great front-end engineer?

Pixel perfect. That eye for detail helps the frontend engineer.

That's a good one. With new frameworks and libraries emerging regularly, and you mentioned a bunch earlier, how do you stay up-to-date with the latest trends and advancements in the front-end world? Are there any resources or communities?

Podcasts. There's a great podcast. It's called Software Engineering Radio. It's funded by the IEEE, which is the Association of Professional Engineers which includes computer software and computer engineering. There are a couple of other ones. I have a whole list of them. Honestly, I listen to podcasts and I walk around the neighborhood.

Thinking, Fast and Slow

In the book Thinking, Fast and Slow, which is an older book about how your brain works, they discuss having two types of brain. There is your fast-moving brain and your slow-moving brain. The slow-moving is a deep-thinking brain, but you have to occupy that fast-thinking brain. That's why you get ideas when you're in the shower or when you're walking around the block and doing those automatic processes. For me, I walk around the neighborhood. I walk the exact same route every day and it's exactly the length of a podcast so that I know where I'm going. I can shut off and walk, and then I can listen to a whole podcast.

I will email you so I can get all these lists. The book, Rest, also mentions this different type of thinking. It doesn't mention occupy, but it does say task-oriented brain or rest is essential so you can think about creative things. Your brain is constantly working so when you're resting, it helps your brain to think about those solutions. That's why in the shower, we come up with ideas and things like that. You need to separate yourself and rest. He also talks about naps in that book. You'll like it.

I'm going to have to read that book because I'm all about naps. Some of the technology books that I've read also refer to this Thinking, Fast and Slow book. I recommend that for anybody to read. It helps with problem-solving.

I will put that on the list. Can you tell me about a project or challenge that sparked your interest in the front-end domain? What’s something memorable that you experienced?

It was mostly automatic feedback. The first time I worked in Flash, that would've been my first real UI exposure. I was working at a company that did PlayStation 3 games. I worked on one of their Army titles. It was, “Choose your weapon. Choose your Armor.” It was all done on a timeline. You used code to move around on the timeline so you could show the button or the body. Flash still used it in gaming. It was for a really long time. That instant feedback that I could type something, hit refresh, and then I would get to go there, I was like, “I want more of that.”

What's your favorite coding playlist or different types of music that you code to?

I like The Orb, which is ambient. They're the godfathers of ambient. It doesn't have any singing in it. I can't listen to music while singing because the words will go in my ears and out onto the page when I'm trying to code something. It has to be ambient.

Do you have any advice for someone who's trying to decide between a career in management or whether to continue as an individual contributor?

I guess it's how much emotional patience you really have for other people. It's true though because management positions are a lot about managing feelings. Also, the idea that I would have to give somebody critical feedback or they could lose their job, I could ruin their life. That fear keeps me out of management.

Front End Engineering: Management positions are a lot about managing feelings.

That's fair. Why tech after all these years?

It's always got new problems. Every time I go somewhere new, I get one job and then I end up in another job. There's so much movement, fluidity, and new technology. There are nerdy stuff that you could get into. You come out six hours later and realize that you haven't gone to the bathroom, eaten, or had any water. I like that. That's fun. I want time to stand still for a while as I learn something.

That's beautiful. This is the last and final. Where can people find you?

You can find me on my LinkedIn.

This has been wonderful.

Important Links