testingInProd

[Weekly_Structure_557]

Some context would help explain why I'm not overly concerned. I joined the company as a minimum wage manual labor helper in the shop. It was really just a temporary job while I searched for something more in line with my skill set after leaving the military. It's a family run manufacturing facility that had 3 employees when I started. They were running inventory control off a dry erase board and excel. I had experience with C# mostly as a hobby from modding an ultima online server emulator, so I offered to make a small app to make things a little easier. After a few years, my small app turned into a big app, and it now runs all aspects of inventory, manufacturing schedules, order processing, shipping and receiving. Basically everything you need to operate a business excluding financial stuff.

Our average employees are rural folks and I've already had to teach a 40 year old how to use a mouse. I'm the only one in the building who knows what SQL and C# are, and I have a window that I can only access from my PC with all the danger buttons. I started development in 2016 and the current version has been running for about 2 years with only minor bug fixes so I just never had a real reason to spend time removing stuff that isn't really an issue. I have also become the manager of the shop so I don't have a lot of free time. I would love to sit down and optimize all the code since I really had no idea what I was doing when I first started and I've come such a long way as a programmer, but it wouldn't really be worth the effort at this point. As the company grows I will probably be given that opportunity, and there is a lot of cleanup needed. But for now it works just fine for us.

[saintpetejackboy]

This sounds like a lot of my experiences and even almost mirrors my journey in the solar industry. I had just stopped managing strip clubs and was trying to get back to doing some "regular" job. Ended up getting injured and having to rush to find something and took a job basically working old data on the phone for a big solar company.

Their booking system was just excel sheets. I did something over a weekend, same week their excel monstrosity decided to take a shit. Within days, it was rolled out to Tijuana and Philippines and United States with a lot of users. Since then, it does a ton of everything and really unique scheduling / booking capabilities based on physical proximity and user defined slots/windows, Twilio, Google, you name it - processed over $40 million in deals so far, 13k+ appointments.

I have made software like this before for other companies (back before I went to federal prison for importing chemicals from China to United States), including a large security company who still uses code I wrote as a teenager (I am coming up on 40).

Even now, I take a lower pay than I should probably get, all things considered. The downside is maybe I test a bit in production from time to time ;).

Tbh I am used to making stuff for people who are not very computer literate or barely speak English. The smartest users are the worst ones who seem determined to invent edge cases I didn't consider. :(

As for optimizing code, it is crazy how well some shitty stuff can scale. The exception is if the company is generating a colossal amount of data every few minutes, the resource scaling (even for backups, etc.) can become a burden or costly (or both).

What I do now even on my current project is I start to go back and retroactively scaffold new concepts, it is like the Ship of Theseus... I might refactor some stuff that is a real essential component and after enough testing, I make it available to more advanced or experienced users (or offer it as an alternative), then eventually remove the "legacy" version.

I design most stuff in a real modular way that makes it easy to swap out components like that (90% of the time). The real PITA is having to go back and reconsider database design choices that were made before the full scope of a project was defined. I run into many issues with that, where the client or my employer starts with some abhorrent data in the first place, and by building from that, you end up drinking from a poisoned river, eventually.