Catchy dev taglines you probably don't know

There are many acronyms and catchy taglines you probably don’t know.

Permalink to heading Disclaimer Disclaimer

While some practices may appear creative, you might find others trivial. Besides, some could have disappeared in 2021. Popularity doesn’t matter here.

Permalink to heading Think Outside the Box Think Outside the Box

This tagline is a timeless message that invites you to think differently. Apple helped in popularising it even more with its famous advertising slogan “Think different.”

It means the opportunities are left for those who keep looking, don’t give up, and think outside the stranglehold of society that everybody knows.

Permalink to heading Programming, Motherfucker Programming, Motherfucker

Programming, Motherfucker rejects XP, Scrum, Kanban, Waterfall, and “anything that is getting in the way of…. Programming”. It’s a radical approach that wants to destroy classic software development methodologies, claiming they don’t work at all and even humiliate programmers.

The manifesto has been signed by Zed A. Shaw on programming-motherfucker.com.

In practice, it can lead developers to introduce breaking changes regularly.

Permalink to heading Eat your own dog food Eat your own dog food

You might be seduced by “Programming, Motherfucker” and other approaches, but don’t forget to experience them first hand.

This principle is not limited to software dev and is also known as Dogfooding. Roughly speaking, it means the employees use the company’s products. Marketers and advertisers often have similar approaches.

The main goals are:

  • Prove the company’s confidence in its own products
  • Improve the overall quality
  • Enhance the user’s experience
  • Speed up iterations

Permalink to heading Big Design Up Front Big Design Up Front

It means don’t rush the implementation. Don’t start with code. By taking more time to think about things, you can save lots of dev issues and dead ends.

It’s a bit counterintuitive, especially for beginners, as you might want to prove you can translate any idea into code, but even in the best-case-scenario, the feature might fail because you didn’t involve the right people at the earliest stages, making the couple hours you’ve spent on your POC (proof of concept) pretty useless.

Permalink to heading The Least Astonishment The Least Astonishment

Please keep it simple when you code. You’d rather use intuitive structures and algorithms than hacks and clever syntaxes.

The naming conventions can be pretty decisive in this perspective. If you create a class that handles Payments, then don’t name it “Subscription.”

Be careful, though, with too generic names, as it might be challenging to use for other developers as well.

Permalink to heading Premature Optimization is the worst Premature Optimization is the worst

Do you want your code to be perfect? Well, don’t make it a general rule. While optimization will be necessary for the successive iterations, doing it at the very beginning is a terrible mistake.

It would require much effort and time, while the first cycles usually include lots of modifications. You could even introduce nasty regressions with premature optimization.

Permalink to heading The Law of Demeter (LoD) The Law of Demeter (LoD)

The LoD is the principle of least knowledge:

  • Each unit should have limited knowledge about other units: only units “closely” related to the current unit.
  • Each unit should only talk to its friends; don’t talk to strangers.
  • Only talk to your immediate friends.

Source: Wikipedia

In other words, the idea is to decouple classes and entities and reduce connections between them. Projects that follow this principle may have lots of relatively small modules and packages.

Permalink to heading The Twelve-factor app The Twelve-factor app

12factor.net is a list of modern principles for software-as-a-service apps:

  1. Codebase: One codebase tracked in revision control, many deploys
  2. Dependencies: Explicitly declare and isolate dependencies
  3. Config: Store config in the environment
  4. Backing services: Treat backing services as attached resources
  5. Build, release, run: Strictly separate build and run stages
  6. Processes: Execute the app as one or more stateless processes
  7. Port binding: Export services via port binding
  8. Concurrency: Scale out via the process model
  9. Disposability: Maximize robustness with fast startup and graceful shutdown
  10. Dev/prod parity: Keep development, staging, and production as similar as possible
  11. Logs: Treat logs as event streams
  12. Admin processes: Run admin/management tasks as one-off processes

Permalink to heading The Pareto principle (80% - 20%) The Pareto principle (80% - 20%)

Only 20% of features are essential to 80% of the users. Reciprocally, teams usually spend 80% of their time on 20% of the application.

Theoretically, with this approach, 80% of the application could be developed, with only 20% of the time allowed in the best scenario.

Permalink to heading Reward The Player Reward The Player

It’s a game design principle that highlights positive reinforcement. It’s not uncommon to see the same approach in software development, as platforms can use scores and badges to improve the users' motivation.

The technique is known as gamification. Apps offer unique capabilities that unlock pretty cool features to the most involved users, just like it’s done in video games.

Permalink to heading Conclusion Conclusion

Hopefully, you learned some principles here. The idea with those approaches is to find the right balance.