When you write code, there are signs that you are doing the wrong thing. Independently, there may be perfectly valid reasons for them to exist - and that's fine.
But when they start grouping together, then it's time to take a really honest look at your approach to a solution and decide if you're doing the right thing.
I came to Mudbath Digital having been heavily involved in the re-development of homesales.com.au.
I was technical lead on a project that saw many of the devs on that project introduced to Angular for the first time - including myself. On the homesales front-end, we were working with some decent sized data and view models, that altered only slightly across different channels e.g. buy, sell, etc, so the decision was made to make use of Angular's existing DI (Dependency Injection) facility in an attempt to prevent code duplication.
It worked extremely well, and it meant that we could develop and ship new channels of the site quickly because work was only being done where there were differences, and there weren't too many differences between channels.
Enter Mudbath. I was brought in to develop a mobile application using NativeScript with Angular. The recent experience I had with Angular had shown me a way of doing things that worked so well, I felt the need to apply it across every situation. So, when I was given the opportunity to add a new feature to the mobile application, I set about introducing the DI process I was so familiar with. It worked fine, the app handled the process without any problems, and I was content with a job well done.
I continued to develop the application, and since I was new to the remaining codebase, I spent a great deal of time refactoring and optimizing the structure of the project to make it easier to navigate and understand - which in turn facilitated my own understanding. As I learned more about the project, I came to realise it was built entirely around ngrx. Ngrx is an Angular implementation of the Redux pattern that manages and simplifies application state. I was sceptical at first of the overhead it required, and it's a fairly steep learning curve, but now that I understand it better and its context within the app, I wouldn't use anything else. And as I learned more about the ngrx Store and Effects systems and how they were implemented within the application, I started to notice the signs I'd made a mistake.
First sign. I needed to do more work.
For any project I'm involved in, I try to set up so I have to do as little as possible. From folder structure to modularisation to DRY - it all adds up. It can be difficult to stay on the path at times because you're working to help future you and sometimes future you isn't as important as present you. For example, I might find a bunch of code that's been replicated in a couple of places in the app. I know I need to pull it out and re-structure things so it can be inherited/re-used from a single location (for many reasons), but sometimes it's four-thirty on Friday afternoon and I don't want to. You gotta do it anyway, or you'll forget, or you'll triage it, or you'll slowly develop a sense of apathy, or you'll stop doing it altogether.
The first sign I was doing the wrong thing came when I needed to refactor an existing component, and I discovered an Interface that the rest of the app had been using. In my recent DI adventure, I had built a replica of that Interface as a class and created a factory for it. The Interface had two properties: name & ID. I saw (weirdly for the first time) that I had created 3 separate layers for creating a class with a name and an ID. I was attempting to future proof this class, when all I needed to do was return { id: <SomeId>, name: <SomeName> }.
And as I started to review and address this work I had done, I realised I had taken that same path for objects of similar complexity and in fact, I'd applied a solution used to solve a problem that didn't exist.
Second sign. I couldn't see a reason to use the same solution again.
As I became more and more familiar with the project, I never again saw or even considered a reason to take the DI approach to building objects. The system just didn't need it. It's a mobile application, which is already working with small amounts of data - and the existing system reflected that. Why implement a process that only adds complexity here!?
Third sign. I started to get annoyed.
Whenever I'd see the DI work (isolated though it was), it made me feel uncomfortable. I was so passionate about it at the start, but I had to take an honest look at what I'd done and kick pride out the window. It was time to refactor the DI processes out of the app.
It was in this moment I took a second to apply that simplified thought process to potential problems in the future, and some walls began to break down. For instance, whereas previously I was in a space I couldn't conceive of building my next web project without Angular, I started to see that a simpler solution e.g. Vue (for instance), might be all I need. I started to research and learn more frameworks as a result. It was enough to make me feel like I'd been doing everything wrong the whole time... and I loved it.
I am not a good developer, I've got way too much to learn.
***
Mudbath is a 40+ person digital product agency based in Newcastle, NSW. We research, design and develop products for industry leaders.
Are you a developer who's looking to join Newcastle's fastest-growing software agency? Get in touch.