Dealing with Legacy Dev ProjectsOctober 28th, 2020
Just thinking about the way I like to work and why.
Standards. Honestly, I grew up a bit messy. I left my toys laying around and would need to be told to pick them up. I try to follow existing naming conventions. But if a project has other conventions, I will follow what I think makes the most consistent result. Since I am a bit messy myself, when people don't follow strict conventions, it doesn't bother me in the least. I am used to and completely comfortable working on projects that stray, or combine systems with different conventions.
From time to time, I have made poor design decisions. It has helped me become a better architect. Nowadays, I find myself learning the design decision is poor when somebody comes and asks me to do the opposite of what I would ever expect.
When it comes to legacy project code, I don't focus on the mess. When you take on a legacy project that has had several developers on the project, you are bound to find some consistent things.
- Really well done database design
- Poor database design judgement
- Really well done PHP
- Some PHP that could be optimized
- PHP features that are missing but should definitely exist
- Great library support
- Some library options you would rather
- Trade-offs on libraries where you like some features but not others (there is no clear best solution)
Those are realities that need to be embraced. Focus on maximizing the good and minimizing the bad.
When systems are difficult to manage, maybe reduce reliance on it. When systems are promising, build as much dependency upon them as possible.
Any system can go in infinite directions with the addition of a developer. It is just a matter of priority.
As Elon says - Developers waste far too much time building things that shouldn't exist. So always ask yourself the questions. Should what I am building even exist? Is it the most good I can do with the resources I have?
This is why I want to work for Tesla. I am hopefully not Tesla's worst Software Dev hire. That would kind of suck. I would certainly need to do my very best. I think by looking over what exists in terms of PHP, I would be able to figure out a unique path to success for Tesla.
At Tesla I would choose a PHP project which I felt had great promise such as Insurance. I would be willing to spend my own time researching the position. That is learning unfamiliar composer libraries pro bono.
That would be getting a sense of the tools in the toolbox. From there, I could add value to CRM, Front End UI, Admin Tools, Admin Reports, API Integration, etc.
I would love the opportunity to work for Tesla. I assume there is a way to track what each employee does. If not, I will build the punch clock. (I have built > 1). As such, I am confident Tesla will have to issues seeing the contributions I make.
I am TSLA Long. Model 3 Owner. Brother of a Model 3 owner. Son of a Model S owner. I have reservations for Slate Roof and Cybertruck. I am a Tesla speculator and fanboy. I am not a financial advisor. Investing in anything comes with inherent risk. I own short term NKLA PUTS.
I proudly support the following Patreons:
The following YouTubers help support my TSLA long bias through stock price volatility. +Great insights.
- Tesla Daily Podcast
- The Limiting Factor
- Now You Know
- Dave Lee on Investing
- Financial Education
- EV Stock Channel