Yes, I switched companies for the sole purpose of being afraid of staying in the comfort zone and a decade later realizing that the world is not what my reality had been shaping it. Now I don't think there was anything wrong with that per se, but I am definitely learning and definitely out of the comfort circle.
I work with a project that cannot afford any downtime. It powers a business spanning time zones around the clock. That means no cutting corners to migrate legacy, no cheat codes that I pretty regularly execute on my side projects.
I started writing this article out of frustration ignited when working on a particular task. The objective was to expose data on the new system, shown in the legacy system, that has its own unique database design, that we are forced to query from the new system running with Doctrine.
Confusing Pivot Naming to Foreign Tables/Columns
For example, one pain point is obvious looking at this table architecture:
SELECT * FROM products WHERE id = 151;
SELECT * FROM products_info WHERE product = 151 AND deleted IS NULL;
I really hate that the Doctrine project I'm working on uses this naming column convention, where relationship columns don't include the _id suffix, where id is the column name on the foreign table that the pivot references.
I grew up working with Laravel and then spreading into other projects. I don't need to use raw SQL as often, since typically ORMs such as Laravel's Eloquent or Drizzle from the TypeScript world are simply amazing.
I've seen a lot of open source projects (obviously not as aged) and never came across this convention. I might be completely wrong but this is so hard to get used to. Even though it's been months that I've been working with this database, I still end up wasting hours, needing another day, another look to actually SEE "oh wait, this is actually the foreign column for this table and this column."
I could imagine that this is very much MY problem and the way I was raised. I imagine if I went to that one country where people bow to say NO and turn their head to say YES, I'd want to hang myself alive :-). It is definitely difficult to unlearn a convention. I don't want to either. In my opinion, a column containing data should be self-explanatory and a column containing a reference should also be self-explanatory as to which column it links to.
No (Unique) Indices Besides the Primary Key Index
That brings me to the next part. I have absolutely no idea why back in the day, back in early 2000s/2010s, there was no convention to add unique indices/constraints.
There are so many tables with the only index being a Primary Key constraint. Just as there are many tables where duplicate data is inserted sometimes as many as a dozen times due to lack of unique constraints (and no code-side checks).
It makes me think that a career on UpWork to optimize one's database queries by merely adding indices could be a great one. Of course, that implicitly comes with a great clean-up task before constraints can be added.
Not Storing File Upload Status on the Table
This is a very recent task that I find rather comical. Some data comes along with media attached to it. A user can upload, delete, view it. I am really glad the system leverages S3 storage, since it's one of my favorite technologies in web dev. However, instead of storing the bucket path in the database, or at least storing a boolean whether the upload was done or not (it's optional and rare), the code will list all files (however it won't iterate, so it was capped at 1000 first results) in the bucket, store them into an in-memory array and then check based on a certain key if the file exists, which will decide if it's included as a pre-signed URL in the API response.
I bet that's what AI would vibe code, or what me as a 16-year-old learning to code would write. But not what a professional developer in a multinational company should ever put into production.
There are a couple of problems:
At the very least, it should iterate and ensure all results are returned.
It should implement a very primitive cache in Redis with tags to store that in-memory array. Tags are to be purged upon new upload. Or simply update the list in Redis upon upload.
But that is redundant. There is no need to query S3 server-side other than uploading or deleting the file.
Ideally, a user should store the bucket path on the table column that could be nullable.
If a record exists, presign the URL, and return it.
Very fast, clean, and scalable.
And there is another list of countless examples that really frustrates me. Sometimes it makes me question and self-doubt what the meaning of working on things like that is. That is hard, because I won't know until I'm gray and old if I was right or wrong thinking the way I am. But right now, I strive to remind myself that character traits and awareness that I can grow working in contexts like this, is going to be a great reward down the path.
As The Primeagen says, if you choose the easy path now, you pay the price later. And vice versa. Or as my grandma used to say, what you learn, you don't carry on your back. It feels like I'm paying the price for someone else now but we shall find out haha! I also write this to double down on my positive mindset and show myself what I am learning.
Something I'm Learning…
If you migrate something in your folder structure, do it all or none; so you don't end up with a folder of shared, dump, smart, new and components for storing components for a frontend.
Prefer to stick with defaults for as long as possible, because one day, when you will want to migrate, it will be FAR easier to understand how things work now and how to migrate it - looking at the legacy frontend project running WebPack with a 100 and 1 customization.
Isolate to one change per PR as much as possible. I hate this in practice because it feels so easy and tempting to refactor everything at once (might be my ADHD/OCD to blame) but it is Achilles' heel when working with a sensitive system and legacy code base.
Patience, really, just be slow and do things slow. Perhaps the biggest thing that sometimes drives me absolutely nuts. I will sit in front of a computer yet my heart will race up like I'm running up a hill. It's funny I react that way. Makes me even laugh afterwards realizing the irony. But it does make me wonder how I can build this mental muscle to be indifferent. Because with the rise of "vibe coding," people with the ability to work on legacy will be in as high demand as developers were a decade ago.
Of course, plenty of examples of what NOT to do in architecting the system for scale and many years to maintain in production.
Takeaways
If you're not a very calm person by personality (that is, you have ADHD), meditate each morning. As little as 8 minutes can do wonders. 15 minutes is wonderful. It helps a lot to remain unaffected when literally needing to dive into challenging code. I now do this daily. And without it, I notice how I'm all over the place. Just to double down, this with running outside, crosses out more than half of the pills & tips in the /r/Nootropics subreddit.
Consistently remind yourself that frustration comes as the by-product from learning something new. It is a chemical that gets released in our brain to enable elasticity to establish new synapses (the links between neurons, between our knowledge storage). Plus, building this versatility against legacy is going to be a superior shield against AI taking away your job sooner. I don't know if I know this for 100% sure but I'd rather believe this than waste energy doubting.
I'm here to learn. I hope that my mind will absorb these mistakes of others and I can learn from them. So that the code I write will look better for future developers. :)
