3 ms·
The problem with saying "you can do things in whatever way you want in Ruby" is that the moment you have more than one developer it collides rather dra
by jamesbritt 16y ago
The problem with saying "you can do things in whatever
way you want in Ruby" is that the moment you have more
than one developer it collides rather drastically with
the "principle of least astonishment".
I've solved that problem by actually talking with the other developers and agreeing to some common practices.
Not every problem requires a technical solution. Social solutions often work just fine.
- kenjackson 16y agoThat works great for two people. Maybe even 20 people. But try to write a 1M+ line app by meeting at the water cooler. One of my favorite stories is we had hired a bright young dev many moons ago. Months into his work we were trying to fix this terrible memory leak, and it looked like most of it was coming from his code. We asked him, "Where do you free this memory, we can't find it anywhere -- you clean up everything else." His response, "Wait, how do you free memory?"
- jamesbritt 16y agoSmall pieces, loosely joined. Or do you really write monolithic 1M+ line apps?
- lars512 16y agoI had the opposite problem at a student intern gig. I hadn't experienced smart pointers before, and was double freeing memory accidentally. The fun part was that the unit tests for my code always worked. It was always someone else's code which appeared to break inconsistently after my change ;) You live, you learn. We picked it up remarkably quickly in the end, basically because the company had their process working right: clean codebase, solid testing, and regular code reviews.