But you should probably touch it before all the dependencies are outdated. And before everyone who understands how to work with it has left. Especially if it happens to be core to the business.
:)
had to completely replace a component in a massive project at my work recently because we forgor how it worked and had a newer different thing for it. it was so intertwined into that project that I practically had to do a ship of Theseus on it 😭😭😭😭
Why would you touch your job security?
looks at the startup scripts I just took from a 2h runtime to 15m
Guess I gotta revert those changes.
I mean, runtimes can be a legit reason to say something’s not working.
But it does work. Eventually.
Really, I fixed it because we’re doing an OS upgrade and I didn’t want to wait 2h every time I spun up a new instance to test a change.
Absolutely untrue. Keep your shit up to date. If you have time, simplify code.
There’s always opportunity for improvement.
Well over a decade ago I remember a coworker would just go through the codebase and add his own coding style.
Instead of
if (predicate) {
He would do
if ( predicate )
I would always ask why he did it and he said, “well we don’t have any coding standards so I’m going to do it” … I replied, “there’s things like unwritten rules and sticking to whatever’s in the codebase makes it easy”. I told the seniors and they chose not to do anything (everyone just merged into trunk) and they just left him for a while.
Then he turned rewrote built-in logical functions in code like this:
if (predicate || predicate) {
Into code like this:
if ( or( predicate, predicate ) ) {
This was C# and there was no Prettier back then.
Also, he would private every constructor and then create a static factory method.
Eventually the seniors told him to knock it off. All I said was that I initially tried telling them weeks ahead of time and now we got a mess on our hands.
Hilarious but their fault for not making a standard. The guy was just taking the initiative.
The correct initiative would have been to make a coding standard and get buy-in, not yolo unilaterally enforce your own idiosyncrasies.
The best part is that his “or” function changes the semantics of the code in a subtle and hard to find way. :D
We have one of those situations at work. We’re a small team, but one guy is kind of unilateral in his work style. He added a bunch of “interfaces” and “domain” modules in our python Django app. His idea seems to be like instead of doing Project.object.get(id=1) with the standard Django library, you’d do like import project_interface; project_interface.get_project(id=1). The “interface” then does some home grown stuff, and probably delegates to the Django library eventually. All of which to me seems unnecessary, “yo dawg” redundant, and error prone.
Also in some places he’s returning like a dict instead of query set or other Django object, which is going to cause problems later.
All of those specifics aside, because I’m sure he has reasons for all of this, but it’s annoying that he’s been doing it unilaterally. Worse, he had a project proposal to make the entire codebase like this and it was shot down. And every time it comes up in code reviews he’s like “well, I think this is good and we don’t have a standard saying otherwise”.
I started really putting my foot down in places I have clear code ownership, but it still turns into like 30 comment exchanges on the pr.
He also has his own import sorting. Which could be fine except he never shared it or put it in the ci pipeline. So no one agreed to sort and comment imports like this, it’s only in files he touched, and when other people change imports the comments become lies.
We have a standards meeting next week and I am not looking forward to it. We’ve been friendly for years and worked together before, but somehow at this job it’s just not a smooth time.
i = 0x5f3759df - ( i >> 1 );
// what the fuck?
Fast inverse square root?
“That sign can’t stop me because I can’t read!”
I was mildly annoyed the other day when someone moved a works-fine function and reimplemented it with dropwhile. This apparently was a divisive idea.
Me: it worked fine. Don’t reimplement it for no gains. Don’t send people to somewhat esoteric parts of the standard library. No one on this team is going to know how that function works off the top of their head.
Them: it’s in the standard library it’s fair game. It still works.
One benefit of using dropwhile is that (with a bit of practice) it can actually be easier to read than a for loop. All for loops look similar. You need to read the for loop line by line to understand what it really do.
With dropwhile (or map, filter and reduce), it’s immediately obvious it will drop all elements until a certain condition turns false.
What the hell is a drop
Skip. As in, “drop the first 5 elements of this iterable.” dropwhile is “drop each element until the given predicate is satisfied.” It’s really not that obscure, I dunno what the original commenter is on about
Yeah, I’m not even a python dev, I knew what dropwhile did immediately from the name. Some people just don’t want to learn anything new, ever.
Fix it til it breaks.
This is actually not a good advice, from my experience. If we don’t monitor, refactor, or improve the code, the software will rot, sooner or later. “Don’t touch” doesn’t mean we don’t ever think about the code, but we make the conscious choice not to modify it.
if it ain’t broke, don’t fix it.
if it’s still under-budget, break it carefully.
if it’s stupid and it works, it’s still stupid, and you’ve been lucky this far.
Its ok to touch up code. If you have lots of notes, on what its supposed to do… I learned this the hardway.
… said no programmer, ever. Especially not after hearing about a cool new feature in their favorite language or library that was just added in the newest unstable version!
that’s a challenge
Found the junior dev that wants to refactor everything.
Man this would have been great to have read a day ago.