I don't think any of the below are too exciting, but the effects they have probably show up in the bottom line:
- I invested a lot of time into speeding up our customer-oriented websites after I noticed we were regularly loading in 4-10 seconds. It wasn't seen as a major priority - however, past a certain load time for each page, you start losing users. We started off way past that certain load time and managed to end up at something between 1 and 3-second loads in most cases.
- This wasn't my idea, but a marketing manager I respect a lot once mentioned that people were spending a huge amount of time filling their date of birth while signing up. Something like 30 seconds or more. The reason was that we had been using a date picker that defaulted to the current year, so people would have to click back i.e. 30 times to select their year of birth. On his request, I replaced it with 3 lined-up fields of selects, and the time spent on average went down to 2 seconds.
- I had the chance to do a major rewrite of some legacy systems that worked fine, but weren't built to scale and lacked standardization - the company had a few hundred users in one country when they were made, and when I worked on it there was a locally-modified copy of the system for each country we were in.
The reason for it was that some of our integrations would cease to work due to third parties, and we had to implement a major upgrade, so I built a service to handle requests and standardized the old servers to only make requests to the service without being smart about how they're processed.
In the process, since everything was liable to break anyway if I didn't get it right, I updated every dependency (whether it was for the code or the server) that I could find. Not fixing what wasn't broken was a value that had served us up to that point, but we were racking on technical debt and it was a good chance to get rid of it. Sure, lots of things -did- break, but solutions were found. Technically, it'll help both me and future devs entering the project, and practically, since the integration chiefly targeted contract processing for our customers, the fact that we can still do contracts and nothing broke on the surface is a success.
- I implemented log aggregation across all our servers (using ELK) and it's been helping us track errors and server states a lot. We could have used something like Sentry, but we have millions of events going through on a regular basis, so it's cost-effective.
- We use an internal time tracker that works based on office card access events. I was always curious about racked up overtime, so I added in a calculation for it in the API and returned it in the response when loading a user's info without adding it to the frontend. I mostly used it for myself and told a few colleagues about where to look if they wanted to check. A few months later, overtime calculation was added into the tracker as a feature.
- I invested a lot of time into speeding up our customer-oriented websites after I noticed we were regularly loading in 4-10 seconds. It wasn't seen as a major priority - however, past a certain load time for each page, you start losing users. We started off way past that certain load time and managed to end up at something between 1 and 3-second loads in most cases.
- This wasn't my idea, but a marketing manager I respect a lot once mentioned that people were spending a huge amount of time filling their date of birth while signing up. Something like 30 seconds or more. The reason was that we had been using a date picker that defaulted to the current year, so people would have to click back i.e. 30 times to select their year of birth. On his request, I replaced it with 3 lined-up fields of selects, and the time spent on average went down to 2 seconds.
- I had the chance to do a major rewrite of some legacy systems that worked fine, but weren't built to scale and lacked standardization - the company had a few hundred users in one country when they were made, and when I worked on it there was a locally-modified copy of the system for each country we were in.
The reason for it was that some of our integrations would cease to work due to third parties, and we had to implement a major upgrade, so I built a service to handle requests and standardized the old servers to only make requests to the service without being smart about how they're processed.
In the process, since everything was liable to break anyway if I didn't get it right, I updated every dependency (whether it was for the code or the server) that I could find. Not fixing what wasn't broken was a value that had served us up to that point, but we were racking on technical debt and it was a good chance to get rid of it. Sure, lots of things -did- break, but solutions were found. Technically, it'll help both me and future devs entering the project, and practically, since the integration chiefly targeted contract processing for our customers, the fact that we can still do contracts and nothing broke on the surface is a success.
- I implemented log aggregation across all our servers (using ELK) and it's been helping us track errors and server states a lot. We could have used something like Sentry, but we have millions of events going through on a regular basis, so it's cost-effective.
- We use an internal time tracker that works based on office card access events. I was always curious about racked up overtime, so I added in a calculation for it in the API and returned it in the response when loading a user's info without adding it to the frontend. I mostly used it for myself and told a few colleagues about where to look if they wanted to check. A few months later, overtime calculation was added into the tracker as a feature.