Hi!

My name is Claire. I am a front-end engineer in Chicago. I really enjoy writing code, and seeing what that code can do.

I want to talk about what it means to be a developer / engineer / do-er.

There are a lot of things that many folks consider metrics for how "good" I am at my job:

• Performance. This might come in the form of a Lighthouse score (or insert Your Favorite Tool Here®), or something more low-level like the complexity of a function and how well it performs (such as the dreaded "Big O" notation - more on that later)

• Soft skills, or how able I am to disseminate a topic of great technical complexity to someone who does not share the same skill set as me.

• Speed. How fast am I able to ship a feature? When that feature is shipped, is it riddled with bugs?

Those are familiar metrics to any developer. I'd argue, however, that there are more. More that we don't ask about in interviews, more that we don't really grade each other officially, but know implicitly about each other.

We all have our styles, but having a core set of values in a development team leads to a lot of good. That's what this series is all about.

I want to talk about the following more at length. Expect these to be their own post(s) in the future!

• Architecture: Is the architecture you're building reasonable? Believe it or not, you're building architecture every day. Every bit of code you place into the codebase is part of the architecture. Does it make sense?
  • Consistency is key.
  • Folder structure shouldn't be dictated by one side of the codebase.
• Tools: Do you monitor and ask why when someone adds a new node module? Did you choose it because it is shiny?
  • Less is more.
  • Fundamentals are forever.
• Discussions: In the world of COVID-19, a lot of us might know what it is like to be thrown into a new work-from-home-indefinitely position. Have your "go to someone's desk and ask a question" discussions directly transitioned to just a DM on Slack? Is that good?
  • When does it make sense to become a video meeting?
• Single Responsibility: script.js is so 2014. Components! Atomic Design! Insert system here! Single responsibility is, in my mind, one of the best ideas to come out of the UNIX world. The command cd doesn't also make directories, does it? No. It only changes the active one. The things you build should be the same way.
• Pushing back, but in a good way: We all know the stereotype of the developer who states “Nope, bad idea. Don’t like it. Won’t have it.” I’ve worked with them before. Pushing back is a good thing when it’s done empathetically. I find myself day in and day out pushing back on ideas designers, product folks, and even back-end developers give me.
  • How do you keep it from being “gatekeeping”, though?
• Building for everyone: Accessibility. It’s not a buzzword. It’s not a bolt on. It affects you if you write only JavaScript. It affects you if you write anything for the web.
  • Don’t sacrifice accessibility because of time.
  • Don’t sacrifice accessibility for anything.
• Who really is the customer anyway?: Is it John or Jane Doe who visits example.com? Maybe. But I’d implore you to think of the person who fills your chair after you leave to the next line item on your resume. They’re important too.
  • Will they understand what you’ve written? My experience is that if there’s a damn good reason for something existing there and there’s documentation to boot, I’m much more inclined to not touch it.

This series kind of sounds like it might just be about how to be a good developer / engineer / do-er, and you might be right about that. In order to be good at our job, we must always be thinking of who the customer is - and the customer is not just the end user. Developers - yes, you! - are also the customers.

These are the general topics I want to hit on, and there might be multiple posts per topic, and even possibly a topic not on this list! I want this series to not only explore all the different ways we can add / lead with empathy, but also expose that for myself. This is a writing journey for me, and I hope you find it useful too.

Our product really is the code we write, the discussions we have, and the feelings we leave with others. Developing with empathy will get us all to a better, more inclusive and helpful development world.