having spent time on both sides of the fence, i've noticed that there can be a rivalry of sorts between software engineers and ml/ds/researcher types.
researcher types often get to work on problems that swe types find interesting, so some swes get grumbly. researcher types also tend to write pretty horrific code which adds salt to the wounds.
but there also can be a sort of envy that emanates from the research side. many are fully aware of their shortcomings and are envious of the swes ability to get things done on computers cleanly.
it often seems that there can be yearning to wear each other's hats from the two groups. if i were running a company i think i'd try to break down that wall as it would probably make a lot of people happier.
of course, the right answer here isn't a meme... it's performance regression tests in the ci suite. and maybe a little training on why customizing a programming language with macros is bad.
> maybe a little training on why customizing a programming language with macros is bad
Both the author and the reviewer had passed C++ style certification. They knew why it was bad. They just got a little lazy and wanted to write their code in a way that felt familiar to them, and figured it was harmless. I got a bit grumpy at having to drop what I was doing right away to fix their mistake due to their laziness.
I think that maybe the author felt like finding the end of a loop stood out much better that way, instead of trying to distinguish the ends of conditional blocks from the ends of loops. If you're used to poorly formatted code in an ML PhD program, it does make some sense. I've worked with a bit of academic Fortran code for my mechanical engineering degree and can sympathize. Also, D and O are shorter reaches on the keyboard than { and }.
Yes, "OD" was definitely just "}". DO might have been ") {" to allow
that's the downside. nobody owns anything, dependencies and deployments become opaque.
i once had a team lead in a quasi monorepo situation tell me straight up to copy-paste some functions i was interested in from their code. they made up some fishy story about deployments. was the story true? did they even know? did anyone know? who even owned it? would they even know?
or the guy who got up in arms because i touched his team's code and didn't write the unit tests that they didn't write when they originally wrote the code.
It's funny you should say that, I definitely was the DS who wanted to be an SWE. I switched hats and am just thrilled, but I do run into a lot of my new peers who wish to go the other direction.
Finding some perfect compromise for those groups would probably be a superpower for whichever org pulled it off, I agree.
researcher types often get to work on problems that swe types find interesting, so some swes get grumbly. researcher types also tend to write pretty horrific code which adds salt to the wounds.
but there also can be a sort of envy that emanates from the research side. many are fully aware of their shortcomings and are envious of the swes ability to get things done on computers cleanly.
it often seems that there can be yearning to wear each other's hats from the two groups. if i were running a company i think i'd try to break down that wall as it would probably make a lot of people happier.
of course, the right answer here isn't a meme... it's performance regression tests in the ci suite. and maybe a little training on why customizing a programming language with macros is bad.