I Burnt Out on Inconsistent Codebases

I burnt out, quit my job and can’t stand the thought of jumping into another Front End codebase that isn’t my own.

A disclaimer: This article isn't about framework(library) X vs framework Y - it's about people building unsustainable web applications in ways that make the developer experience suffer.

We all know the ‘there’s a new framework every week’ meme. While a good rib, it hits on a very frustrating and unnecessary truth of developing web applications. People keep on reinventing ways to do the same old shit. It adds complexity, bloats applications, makes on boarding new developers costly and tedious. It’s a royal pain in the ass.

The following is a summary of problematic aspects within front end that drove me up the wall.

Frustration number 1 - Projects with inconsistency 

Ever check out a codebase and think - 'what the hell is this'?

Inconsistency, be it across folder structure, naming conventions or design patterns is a developers worst enemy. It makes logic incredibly difficult to follow, prop drilling prevalent, and nested structures that recede hairlines. One project I worked on had components with mixed prefixes such as  ‘Driving', 'Drivers', and 'Driver’ with more combinations for say ‘Driverlicense’ and ‘DriversLicense.’ Silly things like this cost time and mental health points.

If ’I don’t understand’ is something you hear often, that means you need to do a better job at making your code more readable or the documentation better.

Inconsistency presents a major problem on-boarding developers - they have to decipher what's going on. How files are structured,  redux logic and state management, custom utility functions people have been sprinkled all over the place, why they’ve built their own form library… wait… WHY HAVE THEY BUILT THEIR OWN CUSTOM FORM LIBRARY. It introduces domain specific logic when there is no need.

The issue of consistency extends to the many ways JavaScript / React allows devs to accomplish the same task. This freedom sours when you have several developers adding to the react broth over the product's lifetime. You end up with an acidic mess that makes your nose curl. It encourages deep domain knowledge with new recruits struggling to understand the intricacies and little hacks implemented to get things to work.

You should always aim to make the life of the next developer an easier one.

Solution: Ducks (an opinionated way to organise your frontend), a review every three months to identify and tackle building tech debt.

Frustration number 2 - I'll just roll my own

Developers adding their own ‘version of redux’ to things when, well, you really don't need to. In one instance a developer got sick of having to rewrite the boilerplate for making async calls with redux state, so decided to wrap things in a higher order component to make things easier.

Great idea in theory, not so much in practice.

What ended up happening was that they implemented this throughout multiple projects, developing and improving it as they went. This resulted in multiple code bases with a non-versioned, ever changing implementation. It confused the living bejeezus out of many who tried to understand how it worked, slowing down development time as they wrestled with the implementation.

Solution: Think twice before writing utility functions to replace standardised ways of doing things. Is it really worth doing when there's probably a well maintained library that does this for you? Build wisely.

Frustration 3 - Not using standard libraries. 

Instead of using redux forms or native form inputs, developers decided to create their own inputs that integrated with redux, made async calls and had their own validation implementation. This was a nightmare. The form input was used throughout the entire on boarding process and multiple repositories. It was so deeply embedded that whenever a new bug arose (which was often) and we needed to change it (which we did) it would impact multiple repos. This component was literally copy pasted between repos of the same app, resulting in multiple untracked versions and bug fixes that needed to be implemented multiple times (if people bothered to keep things consistent). With many versions comes many different behaviours- which meant what would work for one implementation, would differ from the rest. As I mentioned before - Nightmare.

Solution: Forms are nothing new. With a plethora of well developed and tested third party libraries available there is absolutely no need for most web apps to have to roll their own forms these days.

Frustration 4 - People who just aren't very nice

An extremely important part of the hiring process is culture fit. You get a sense of each others values, your ways of working and you can make an informed decision on whether or not you'd like to work together. It's a completely different story when you're assigned to a client - there is no culture fit. They're a client, they're paying money, you work with them. This lack of control, especially when a client does not share the same core values, can be extremely demoralising. For myself, the lack of autonomy and being stuck in a team that so differed from the values that I was hired for was the leading factor in my eventual burnout.

Solution: Work on internal product teams - you'll be working with the same people who passed the same cultural interviews you did.

What learnings can I pass on from all of this?

This may come across as a bitter, get it off your chest rant and while this was healing to write, I hope it provided some valuable insights and takeaways. The issues identified above, jokes aside had a serious toll on my mental well being. I’m hoping this will serve to highlight any of these difficulties to you, provide work arounds for some and raise red flags for others.

They may seem menial, but when you're working on projects like this every day - it's like trying to be a writer whose pen nib randomly alternates between pencil, pen and smoke.

> Life is too short for shitty code and lack lustre products. If you have both then move teams or move companies.
> Investigate the type of programming and applications that interest you. Find out what kind of products you enjoy working on, then find out what aspects of programming you actually enjoy. Knowing how to program opens up so many doors, so open a few, you’ll never know unless you try.

> Consistency is sometimes more valuable than doing things ‘the right way’. If you come across some terrible patterns, just hope they’re at least consistent terrible patterns.

> If you're interviewing at an agency, ask how often developers move between teams. I would consider it a potential red flag if this happens often.

A key aspect why I disliked my role so much, was that it was primarily bug fixing with very little feature development. A builder does not become a builder to fix other builder's houses. While it's extremely valuable to have the skill to do so, it's not what keeps you happy.

When I realised I was burning out, I:

Attempted to address internal issues - these were not resolved.
Requested to move teams - this was not possible.
Interviewed at other companies - I received a couple of job offers but ultimately decided I had had enough of front end and decided to take a step back from React.

I didn't solve my burnout by quitting, albeit removing myself from a bad environment was an important part of this. I took a month off to reflect on my career, mental health and what would ultimately make me happy. Building forms for a living and fixing other people's bugs was not conducive to this. I still enjoy the power of programming, the lifestyle it offers and the technical challenges it presents. I'll continue to program but in a more 'stable' ecosystem.

So what's next for me? 

To be abundantly clear - while this whole situation did suck, I'm happy it occurred. It pushed me to take a good look at my current career path and what I really wanted to add value to. My mental health is good, i'm happy, i'm excited for the next venture.

At the moment i'm learning Webflow and motion design with Cinema4D. Finally creating consistent content for my YouTube channel (3.8k!) and dabbling with some IOS development. If this seems like a terrible idea - please let me know down below!

If you're starting to feel burnt out, I'd highly recommend this article from Smashing Magazine which hits on some different (but very relevant) issues relating to burnout and javascript fatigue. Another excellent read is "What it feels like to learn JavaScript in 2016" a very in depth, relatable exploration on the lengthy process of making web apps.
‍
Adieu Weback, so long Babel, you shall not be missed.