The Lounge is rated Safe For Work. If you're about to post something inappropriate for a shared office environment, then don't post it. No ads, no abuse, and no programming questions. Trolling, (political, climate, religious or whatever) will result in your account being removed.
I have experienced that the algorithm works for twenty four cases, but fails for the twenty fifth case. When the algorithm is made to work for the twenty fifth case, it fails for the seventh case. Then, it is like back to square one. But, experience also says that persistence pays.
If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about?
Help me to understand what I'm saying, and I'll explain it better to you
Rating helpful answers is nice, but saying thanks can be even nicer.
I was never a Ford fan, my father (who was a car mechanic) always said "It's not refined technology", and it also seems that Henry Ford had anti-semitic symphaties. But all that was a long time ago of course and on my last holiday in Italy I even rented a Ford Focus and must say that it was a fine driving experience.
Anyway, I find "refined technology" to be an interesting description. The meaning seems a bit fluid at times.
Sometimes it means simplified (as in perfected for a task), and sometimes it means advanced (as in the opposite of simple)
Refined is the opposite of crude. But Crude and simple isn't the same thing.
If "not refined" is the same as crude, I will have to disagree.
Ford has always been masters of simplification though.
After some bout of refactoring where I spent some time updating one of my old and trusty utility class to be yet even (significantly) more simple, elegant and functional... I started to idly wonder...
Did it happen to you that a coworker refactored some (large amount?) of your code, with the announced purpose to "make it more simple" (no new functionality, just improvement). Yet when you look at the result (honestly and deeply, not just a quick reaction and disgusted look) you find it way more convoluted, messy, broken, confusing, etc?
where I spent some time updating one of my old and trusty utility class
...Did it happen to you that a coworker refactored some (large amount?) of your code ... Yet when you look at the result you find it way more convoluted, messy, broken, confusing, etc?
ummm, as you are cleaning up your own code and writing about when coworkers do this to your code...
split personality? self trust issues? worried a coworker has hijacked your body?
your code is your expression of an algorithm - a sequence of steps to get from A to B.
but anything more than a few steps means there will be multiple possible paths,
you code: your mind begins by visualizing & testing a path, then expresses that into code.
a different person
(1) visualizes a different path,
(2) expresses [that different path] into code by different mechanisms, and,
(3) even with defined house or whatever rules in place style can still vary too.
later you look back at that code:
your mind recalls the path and mechanisms you used and looks for that,
...and then it all unravels (in the opposite order)
1. style differences: slows down your code/pattern recognition (- though soon [mostly] overcome - it'll still irk a bit)
2. huh? this mechanism doesn't fit the path (you're looking for "your" path)
3. whaaa??, why is this here? (figured the mechanisms, but the path you see doesn't match yours)
I'm sure this morning I arrived in and parked a black car in that [now empty] spot over there oh yeah, some guy told me it was looking a bit dirty and offered to clean it up for me
why am I now standing here holding the keys to this pink half-track truck?
your car code is gone, now you have this completely different one.
a different person
(1) visualizes a differentwrong path,
(2) expresses [that differentwrong path] into code by differentwrong mechanisms, and,
(3) even with defined house or whatever wrong rules in place style can still vary too.
It is not "agile" to document every decision you make when coding, meaning that the original dev probably had some reasons for building things the way they are. If there's an improvement to be made, I wanna know - it might teach me something and prevent me from making the same mistake in the future.
..but changing code that isn't broken needs a damned good reason - since any change has the potential to introduce new (and subtle) bugs.
Bastard Programmer from Hell
If you can't read my code, try converting it here[^]
"If you just follow the bacon Eddy, wherever it leads you, then you won't have to think about politics." -- Some Bell.
If the code works, and you're not tasked to work on it, don't "optimize" it. In fact, don't even reformat it. See if you can get that guy fired.
".45 ACP - because shooting twice is just silly" - JSOP, 2010 ----- You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010 ----- When you pry the gun from my cold dead hands, be careful - the barrel will be very hot. - JSOP, 2013
Last Visit: 19-Jan-20 4:41 Last Update: 19-Jan-20 4:41