|
|
|
|
|
|
by tacostakohashi
1800 days ago
|
|
|
If you're joining a big/complicated/legacy project, and want to make changes (or even get anything done), Chesterton's Fence applies. https://fs.blog/2020/03/chestertons-fence/ There will be many things that don't make sense or look wrong initially. Its possible that they *are* wrong, and you can improve on them. The key to productivity is being able to demonstrate that your prospective changes don't break anything, and do in fact improve things. I doubt people are "withholding information" from you, probably the people who made the decisions left, or are busy with other things now (management). It's your job to gather the information you need with what you have. It may be the case that you need to invest heavily in testing, logging, instrumentation and debugging skills on the current system to understand how and why it works as it is, and whether your changes make things better or worse. |
|
|
"Hey this looks weird"...That's because I wrote the code at 4am after production being down for 12 hours. It was meant to be a quick fix, but no one wanted to touch the code and I was sent to another project for 6 months. So yup, my stupid hard coded code is still there, and yes it breaks on leap years on February 28th...I put it in the story I wrote.
For some reason my worst code ends up being used the longest. That solution I wrote code for about 14 hours straight to save about 100 hours of wasted dev time per week. I put a note with a date "yell at me if you see this in a month", because I meant to improve it...but re-priorities took me away. Three years later I am fixing it, most of the code is trash, bad decisions made, some horrible configuration assumptions. Part of it was inexperience. Now I know any code I write might remain in the code forever...