Blog Post

Most recently, I was the sr. front-end developer leading the UI on several projects at a company. It was a position that brought me great joy most days. Getting to choose the tools/frameworks/methodologies applied and provide direction for the front-end to new projects, working remotely from Austin, and being able to be heads-down on projects to write code for hours. It was great. Who would voluntarily leave that environment, right?

Well, yeah, I did. And here's why.

I care about the front-end

When a company has full-stack developers, it more often than not will mean that they treat the UI as a second-class citizen (MMV). They'll have developers that are very strong on the back-end but struggle with making thoughtful implementations on the front-end. This is often the case with tiny startups that have limited resources. However, at a small to mid-sized established company, there is no reason to not have dedicated resources on the front-end.

I think Brad Frost covered the topic decently in his recent blog post:

In my experience, "full-stack developers" always translates to "programmers who can do frontend code because they have to and it’s ‘easy’."
- Brad Frost in full-stack developers

None of this is to say that the devs weren't skilled -- they were just significantly much more back-end oriented. They could quickly spin up new Rails apps and identify/fix issues with the databases. However, since they could write enough HTML/CSS to show a feature, they often had to in their limited capacity. This led to the "front-end developers" handling more content-related or design-oriented tasks while I luckily established myself as more of a developer.

Having team members that can own the frontend experience is a good thing. Having team members that can own all things backend is a good thing. Having everyone work together to create successful products is a good thing.
- Brad Frost in full-stack developers

At the company, I was the sole front-end developer on the biggest cross-functional team that was working on the two biggest products for the company. For a good portion of the time, I was also tasked with keeping the design afloat. Initially, I was proud to be able to own the UI for those products and lead the efforts on the front-end. However, that joy gradually deteriorated.

Trying to make the front-end a priority

I worked hard to become a strong resource for the full-stack devs. When I first started, I noticed they were uncomfortable having to style up their features which they often enough had to do as we had limited front-end/design resources. As a result, I introduced reusable styles and the use of styleguides. For existing projects, this allowed for them to grab code snippets of design patterns so that they wouldn't have to worry about pixels anymore. On new projects, I'd create reusable styles (SMACSS/BEM) and document them with an example HTML code snippet. This increased the speed of building new features as they no longer had to worry about writing new SCSS or HTML.

Anyone with a browser can see your markup. Don’t be lazy.
- Billy Whited in Front End Craftsmanship

During my annual review, I asked for the role of designers to be more collaborative with the front-end process. This included suggesting that they promote the most senior designer to a lead so that there could be a direction for them to follow. The designer had already been doing the majority of the design work and knew the products quite well. With so many products being introduced, consistency and unity in the design at the company seemed increasingly important.

When I used Angular/Webpack for a new project, I kept up with version updates and best practices. If you've been keeping up with Angular (2+) since it's beta... you know that was quite the task to take on. I didn't want the full-stack devs to be boggled down by a new framework, though. I handled any breaking changes and would inform the devs of how those changes impacted how they write features in the future.

I tried to establish code standards for the UI codebase as well. Unfortunately, as the second class citizen, no one was really interested in writing maintainable front-end code or even using the lint files for that matter. I couldn't blame them, though; this was to be expected as no one had ever given any priority for the front-end at the company. As long as the front-end code 'worked', it got merged... and that wasn't going to change any time soon.

Being miserable...

We had a process in place for getting code reviewed and merged; the back-end code greatly benefited from this process. However, that's where I really started to feel isolated. My pull requests would sit there for days despite being posted on the dev slack channel several times or bringing it up during our daily stand-ups. Often times, silence would follow and on good days, the product manager would push for the code to get merged. And some times, I would make performance branches to speed up the site significantly but I was pretty much the only one that cared despite my enthusiasm for getting them merged.

A few months ago, it just started to feel like while I was pushing to improve the front-end code and process, I was alone. If new styles were added, no one would use the naming convention or document them which led to bloat from one-off styles and design inconsistencies on the apps.

I'd jump in to save what I could in the time I had but it felt like we were on a boat that was filling with water. I was using a bucket to scoop it out but I was the only one that noticed it and therefore despite everyone being on the boat, no one did anything. There were no contributions to maintaining the living styleguide or UI standards. This was surprising to me since after all, it had proven to benefit all of us already. Using a naming convention that promoted readability and reusability had made assigning classes quicker and easier. Making reusable components led to more rapid development.

I believe that programming is fundamentally about humans, not about code.
- Kyle Simpson in Functional-Light JavaScript

After two months of having trouble sleeping and feeling miserable most days, I realized I no longer had a future at the company. I could stay and continue to push, sure. The company was not in a position to actually focus on the technology, though. They'd be product-pushing for years to come. My career and the front-end world would not be forgiving to me losing some steam.

Before giving my notice, I chatted with some of my mentors about my situation. They agreed unequivocally that there was no more room for me to grow at the company. I wasn't in the position to make any significant change as the change had to come from the top. I had expressed my goals, concerns, and desires at the company and little to nothing had been done.

My team had just started transitioning focus in our projects and it seemed like the most painless opportunity for me to step aside. So, that's what I did.

What am I doing now?

Since I've left, I have mostly worked on passion projects. Working on these projects that I deeply care about has ignited the desire for my next role to focus on building a product that I find both enjoyable and helpful to people. A company that is committed to its' users. This has helped me narrow down my search in jobs and given me something to look forward to working on soon. I've taken a limited amount of interviews for this same reason of aiming to work on specific types of projects. In the mean time, I'm pretty immersed in my personal projects.

Other than that, I went to Dallas to get LASIK. I've taken 3 trips with my husband to places including Las Vegas (USA), South Padre Island (USA), and San Miguel de Allende (Mexico). I also restarted my weight loss journey to finally hit my final target weight.

Overall, it was the best decision for my career and mental health. My advice to anyone in a similar type of environment or situation is to be attentive to the changes your company goes through and how they impact company values. At a small or mid-sized company, you can typically pick up on what they deem important pretty early on. Have conversations with devs and designers to be able to collaboratively create a productive environment. You should always try to improve your situation but also be mindful of what the company deems most important. Does it align with what you value? Does it benefit you or your career to do the work you are doing - in the manner in which you're doing it?

---

If you work at a cool company that values the front-end, hit me up on LinkedIn or @sceendy