How to Talk Like a Software Engineer

Engineers may spend their days steeped in code that is part of a programming language, but their affection for shorthand communication is not limited to software.

We’re also prone to speaking in code, with a sizable vocabulary of acronyms that reduce key concepts down a single word standing in for four or five, or more.

The most useful acronyms, of course, are widely adopted. Others are constantly evolving along with custom software development and legacy application modernization.

But if you’re new to the industry, or you’ve spent a good part of your career working solo, these terms can sound like another language. They are.

Here are a few favorites from the team at Tampa’s MercuryWorks, where whether we are building a rock-solid back end computing platform as part of our .NET Development practice or hanging out after work over BBQ and IPAs, we’re partial to acronyms.

More Meaning, Fewer Words: The Appeal of Acronyms for Engineers 

DRY: Don’t Repeat Yourself – a software development principle designed to reduce the repetition of software patterns, using abstractions or data normalization as a replacement to avoid redundancy. “Every piece of knowledge must have a single, unambiguous, authoritative representation within a system.”

The principle was first described by Andy Hunt and Dave Thomas in The Pragmatic Programmer. When the DRY principle is working, a modification of one element in a system doesn’t require a change in other logically unrelated elements.

Common examples include sending emails using database connection pools and other instances where code can be reused in the application a number of times. While it may seem designed to decrease the code base, the main intent is to discourage copy-paste programming and make our code more maintainable by having only a single instance of reusable code in the application.

A common misinterpretation of DRY is to make all classes overly generic or accommodating of any functionality (breaking the SOLID principle, below). A common side effect of misusing this practice is the creation of “Swiss Army Knife” components which, to be reusable in different (most of the time unforeseen – see YAGNI) situations, begin to encapsulate multiple actions, breaking the Single Responsibility Principle (also below).

Both back-end and front-end software benefits from reusable code or components because they reduce development time by avoiding the rewriting and testing of the same thing multiple times. This is a great way to ensure the DRY principle.

SOLID: in software engineering, SOLID is a mnemonic acronym for five principles of design promoted to make software designs more understandable, flexible, and maintainable. The ideas are:

• Single-responsibility principle: “There should never be more than one reason for a class to change.” Every class should have only one responsibility.
• Open–closed principle: “Software entities … should be open for extension but closed for modification.”
• Liskov substitution principle: “Functions that use pointers or references to base classes must be able to use objects of derived classes without knowing it.”
• Interface segregation principle: “Many client-specific interfaces are better than one general-purpose interface.”
• Dependency inversion principle: “Depend upon abstractions, [not] concretions.”

YAGNI: You Ain’t Gonna Need It – a mantra you will frequently hear from members of Agile software teams. It reflects the idea that presumptions about future software needs should not be used to justify adding capabilities that aren’t needed now.

Like many elements of Agile and Extreme Programming, it’s a sharp contrast and a reaction to elements of late 90s software engineering. At that (pre-Agile) time there was a push for careful up-front software development planning. The modern approach embraces incremental value and incremental creation.

Engineers often build presumptive features because they think it will be cheaper than building them later. When you consider the probability of the feature being needed with the hoped-for ease of flexible project management (via a sage product manager) and more flexible software architectures, the likelier probability is that the cost of implementing it “up front” is not much lower. 

KISS: Keep It Simple, Stupid – a principle cited by the U.S. Navy in 1960 to stand for the proposition that most systems work best if they are kept simple, with simplicity a key design goal and unnecessary complexity avoided.

Streamlined Communication & Deeper Understanding

Engineering acronyms can be powerful tools for streamlining communication and increasing efficiency. By becoming familiar with these tried-and-true engineering acronyms, you’ll gain a deeper understanding of technical concepts and be better equipped to navigate the world of engineering.

Similar Stories