In development, everything that we do is a trade-off. Sometimes, we don't act like it is, and we are lying to ourselves.

Languages are a trade-off

I spend almost all of my time programming in PHP and Javascript. This is a trade-off.

By focusing on PHP and JS, I forego the chance to enter into deeper conversations about Ruby, Python, Lisp, etc. I know the basics of these languages, I have programs and scripts in all of them, but they aren't my expertise. On the other side of the argument, the time that I spend in other languages takes away from working more in my specialty.

Personally, I put the balance line of what makes me a more well rounded programmer. I look at things like Ruby's attr_accessor and think "what is a way that I could provide similar functionality in my current objects in PHP or JS?" I can see pitfalls in overly architected Java examples and avoid that in my own code (more on architecture in second). I spend enough time to learn, steal, and talk about these other languages or dive in on a code review, but they aren't my environment of choice or comfort.

Software Architecture is a trade-off

Object Oriented Programming is a trade-off

Too often have I seen Node, Ruby, or PHP CLI tools that pull in tons of dependencies, and are configurable to a fault: all to just do a find and replace on the filesystem. They have what some may refer to as great architecture: abstracting away file manipulation, creating drivers for various abstractions for regular expressions, using third party packages for argument parsing (for all 2 possible arguments)(… and they abstract away these arguments from a handler). But at the end of the day, this could all be handled by a 4 line PERL script (or even better, just a simple bash alias or function)! Similar things could be said for overly architected functional scripts so stop writing your comment now

Patterns are a trade-off

Patterns are a very funny thing in development. They become the battle cry for some. However, before you think about arguing over a pattern, diving deep into using some pattern you heard about on the internet or a book, think of this quote from Martin Fowler (among the biggest names when talking about programming patterns):

"Well, I think program design is all about trade-offs. There are very few cases when you can say, 'Whatever you should do, you should do this.' All the time, you have to say, 'Well, here are my options. Here are the trade-offs between them.' And I choose whichever one sucks less."

For all of the people thinking that they NEED to follow pattern X instead of pattern Y, I would say listen to this podcast with Fowler. Then, read his book on Patterns of Enterprise Applications. Personally, I found it amazing how flexible Martin is about what patterns we use. In fact, in more words, he even says that patterns are not to be followed, but simply used as a common way of talking about common solutions to common problems. One quote from the book goes like this:

"Each pattern describes a problem which occurs over and over again in our environment, and then describes the core of the solution to that problem, in such a way that you can use this solution a million times over, without ever doing it the same way twice" - Martin Fowler

We have to understand that each decision we make in programming is a trade-off. What's key is that when we look at someone else's work, we try to understand what trade-offs they made (we often find the criticisms, but what did they gain that made them choose what they did). When we look at our own code, we should think back on why we made the decisions we did and what we can learn from the things that hurt and the things that felt good.