Let’s just add one more feature

Shoutout to !fuckcars@lemmy.world
- I'm disappointed that I misunderstood the topic of that community
  
  Oh, you must be looking for dragonsfuckingcars.
  
  I exhaled vigorously through my nose.

I feel line this would be funnier as "code updated to do 999 things"
- Excellent point. Sometimes removing functionality is much more kludgy than adding it.
- @JackbyDev BTW, I love the Netscape profile pic.
- @JackbyDev lol

I've reworked SO many systems that started clean and were obviously updated by a series of different people over a span of years. New features nailed on with apparently little understanding of the overall app. It's like, "Oh dude it was already doing 90% of what you wanted, you didn't have to add all this...
<sigh>
." Especially true when offshore contract agencies had been involved - to churn through jobs as fast as possible (with no other concern) they tend to copypaste sections of the app that do something similar to what's desired, and make minimal changes to them, with zero code cleanup. This leaves all sorts of misleading unnecessary code, as well as inefficiencies like grabbing a large dataset to get a single item, etc. I found things that made me literally LOL.
- Our off shore contractors produce some of the worst code. But it's impossible to get work done and also be vigilant enough to reject their bad pull requests. So basically you'll end up looking a code one day that is godawful and think, "this is off shore". And yep, git blame tells you you're right.
  
  How do code reviews work with contractors? Is it just "you don't get paid until we approve it"?
- Addendum: one that stands out was an in-house survey app that allowed you to create questionnaires and email them to people in the company. Responses were saved in a database and you could make complicated statistical inquiries like, show me how people answered questions 7 and 8 who said Yes to question 12, No to 13, and filled in the "Other" blank for 19.
  My job was to speed up the SQL queries, which were so complex and slow the max runtime had to be increased to like an hour to let them finish. This was because the original database of questions and multiple-choice answers had been modified in several stages, which ended up with response details in multiple fields in multiple tables depending on the type of question. After about a month I managed to streamline the queries so the longest one took less than 10 minutes, but this was still enormously slow because questionnaires had maybe 2000 responses max. The problem was the database structure relationships was too complex because things had been scabbed onto it.
  One day at lunch I spent about 20 minutes noodling a redesign with fewer tables. All user responses would be in one place, and the longest queries probably would have run in a second or two, plus maintenance and enhancements would be WAY easier. When I proposed actually doing this, management said they would think about it if they ever did a new version.
  At least I tried.
- I just need to add 20 if-branches in 15 methods across 10 different files from 5 modules.

Don't worry its going to get refactored any day now

When your management judges teams by lines-of-code written.

Single responsibility principal and dependency injection are your friends.
- The problem is that so is the junior dev they hired to do the two seniors' jobs who left for less inhuman pay.
  Code problems are usually people problems.
- Also makes it easier to put spaghetti back onto the right track
  
  You reminded me of a guy who’s always banging on about how Elm combs the spaghetti in your source code for you and the meatballs and sauce are only mixed in at compile time. He says object oriented programming is like threading the pasta through the meatballs which is OK before anything’s cooked but after that it gets too soft and entangled and the spaghetti won’t thread through so you start again rather than refactor. It was a compelling image and got me curious.
  I used it for the second rewrite of a side project WebApp a couple of years ago, and I it felt like I had to do everything from scratch by hand all the time at first, but I have to admit that maintenance has been an absolute dream compared with the old codebase. New features, changed functionality, it’s always good and you don’t need to reunderstand everything because it’s all so separated and I told him he was right. It writes the css for you and I kid you not, I did not miss that flakey nonsense one bit.
  Our boss is shit scared of anything even a little bit different, though, so he noped out hard when he saw the syntax and got all shouty about all the whitespace and arrows on the big branching statements before launching into a sermon about how you can’t have a corporate look and feel unless you use css. I lost quite a lot of respect for him that day.
  Our code at work is so like the bottom picture. You have absolutely no idea whether you just filled someone's underpass when you build another bridge over the top and sometimes you just have to kill the whole branch you've been working on because adding a f*ing overhead sign collapsed seven other things and no matter what you try, you can't undo whatever it was that collapsed. I swear, one day we're going to find that someone accidentally nuked twelve routes six months ago and there's nothing anyone can do about it any more.
- Edit: Oops replying to wrong person sorry.

Top pic is a Mutex and bottom is lock-free concurrency.

Isn't the most effective solution for traffic something in the middle? Both of these suck for different reasons.
- It's mainly public transit. Trains, busses, etc
- @Matriks404 it dpends on the traffic. Where I grew up any more than the first would be dumb.
  
  Where I grew up even the first is a dumb overspend of public funds. You don't seriously need all 4 roads to be fully paved and have multiple lanes do you?