You won't believe this one weird trick discovered 2500 years ago in Greece.
[W]e could elevate the entire profession by assuming most programmers would want to become better programmers, capable of wielding sharp knives without cutting off their fingers. That’s an incredibly aspirational idea, and one that runs counter to a lot of programmer’s intuition about other programmers.
- The Rails Doctrine
I love to program.
If you don’t, that’s totally fine. You can have a fantastic career and do great work whether you really enjoy programming or just happily do it as gainful employment. I love it though.
I come from an engineering background. Not software engineering, just engineering. I went to school believing that I could use my math and science skills to create things. That promise isn’t necessarily a lie, but it’s perhaps a lie by omission. You quickly learn that the projects you’ll be doing take months to years to develop. Engineering looks more like Office Space than it does Maurice from Beauty and the Beast. The act of engineering is extraordinarily dull.
That’s how I came to love programming. A person can grab a laptop, I used my sister’s abandoned 2013 Macbook Air, and they can create. The cycle of conceptualization, evaluation, and creation is extremely compact. It’s an amazing feeling.
That’s why it bothers me when programmers want to omit the second step of that cycle. There’s a beauty to programming in that once you leave the metal, every concept is completely imaginary.
It leads to a sort of Socratic exploration of ideas. You are presented with a problem, and you have to design a solution in code that can withstand scrutiny. Our profession has come up with a variety of ways of assessing code, but I think the simplest incarnation is something like this set of questions:
Now, I am by no means saying that we should start from square one in every act of programming. We have lovely tools like Ruby on Rails that guide us towards quality solutions to conventional problems. Unfortunately, not every problem is conventional. Every business has unique problems that require unique solutions, and no amount of cargo-culting service objects, vanilla Rails, or SOLID principles will get us to a quality outcome.
If you see a 2000 line model, look in to breaking it up or moving its business logic to another location. If the strict use of services is making it hard for programmers to align with product on what’s happening, try an object oriented approach. If Rails has no good way to solve a common problem in your codebase, try extending The Rails Way so that it does.
What’s essential is that we evaluate these solutions with other programmers. When a solution is genuinely considered against basic principles (Does it solve the problem? Can I change this if I think that I need to?) we hone our thinking and improve the codebases that we work in. That improves the lives of ourselves and our teammates. No one wants to hear about how their code isn’t DRY or how it should be a service or a model. What they’ll appreciate is discussing why centralizing a piece of code will make their work and the project better.
It is a professional duty for us as programmers to think deeply about the work that we do. Regurgitating other people’s ideas, or worse, not thinking at at all, will never be sufficient. The one weird trick to better code is to really, truly think. Don’t be afraid to wield sharp knives instead of Slap Chops.