Buzz words that maybe matter.
It’s ten o’clock sharp and you’re in the office to work, but let’s take this hot drink first.
Full of buzz words our world is. Software engineering does not escape from that: how many times in a conversation someone just throws a bunch of overused words?

Letting the bingo down, maybe there are words or sentences that have a lot of behavioral context behind them. And we get the buzz word history studying it.
Learning from jump-in courses or coding cookbooks is not a problem. We learn a lot from other technologies without basic stuff that are inherent from languages and paradigms: probably you not interested in reading about what a variable is(again), as you have learned from your first language, or read the concept behind a pure function that you studied on your massive Haskell book when learning functional programming. We just want to get the Goroutine running through all cores or know how Elixir’s map works.
Let’s remember that coding itself is a way to something: coding as hobby (grow your career after all), profit (full time job or freelancing) or non-profit (helping a NPO). And we love it, and that’s nice! As a former college mate says in this talk, we like maintainable code because it gets revenue, not just for art. So, the way we are working maybe has the same importance as the code we make.
Your teammate in a pair session, or just paying attention to other developers during the day, some jargon always pop up. Let’s dry something, this piece of code is violating Demeter Law, broken window this module could became… Yes, probably you know what I’m talking about. They didn’t just appear: they have been helping the industry to build profitable and friendly code.

So, in a weekly series of fun, no-code posts, I would like to present some jargon used daily by engineers. A light approach while you start the week with the aforementioned beverage. Let’s jump in, shall we?
If you allow me, let’s start today, with Don’t Repeat Yourself.
Thanks!
DRY
Someone proposes to dry the code. We automatically translate that to “I shouldn’t duplicate this piece of code, or this entire module.” But, where and when was Don’t Repeat Yourself born?
DRY maybe is the most famous in the buzz family. I should tell you that the Y2K bug were in place for a long time until two guys first wrote it in a book.
First coined by Andy Hunt and Dave Thomas on the first edition of The Pragmatic Programmer in 1999, it gets through generations and technology hypes. In the section called “The evils of duplication”, they describe four types of it:
- Imposed duplication: no way to go. Standards, multi platform libraries, languages that requires both header and implementation sections, etc. If comment is code and you don’t have any other option rather than commenting why your method exists, there is still no point of duplicating this comment. That’s your call, C++ developers. Also I’m doing a lot of Python this days, and goddamn it, temptation has come several times. We can avoid it, classy way.
- Inadvertent duplication: we didn’t know we were duplicating. Different aspects of the same feature sharing stuff around, we could grep and we would find tons of duplication. Step back and look further for business needs. Clones definitely aren’t needed. Here.
- Impatient duplication: time. Product managers, c-level, market, we always have features to make and time to do it. We can estimate and get a comfortable term to work, but sometimes revenue will get increased by 20% if the deadline gets 2x times shorter.
Writers mention Tolkien’s quote “shortcuts make for long delays”, and it’s all about negotiation. Maybe that 20% can turn 18% in short term if 50% is projected against 30% in long term. We know that this requires a lot of business sense, but remember that we don’t just code, we help to build features: so an honest talk with demanding people and you may get your deadline a little more flexible.
- Interdeveloper: a team composed by several squads (thanks, Spotify for another bingo word). This is similar to inadvertent duplication, but this is closer to team sizes and communication gaps/pitfalls. Of course a daily or even a weekly stand up meeting with a 100 developers forum is not good, but how about asynchronously broadcast your features and a wide view of it? People will read it in a periodic pace, and if dry awareness is present in the team, they will know about it. Don’t Repeat Yourself, plural.
Maybe I got lucky when one of my first tech coaches gave me the tip to read the book. I have learned a lot from The Pragmatic Programmer: from letting mouse aside to get more focused and productive from coding shell scripts to don’t rewrite boring daily commands. Maybe the point isn’t the number of lines you code, but the single value of each one of them, and maybe less lines gets more revenue.
See you next week! We will be talking about Demeter Law. I accept bingo cards suggestions, drop me a line :)
