Home Blog How to speak geek, if you are a marketer

How to speak geek, if you are a marketer

Blog, April 16, 2015

If you work in marketing, you might not be aware of all the beautiful things that happen in the IT department of your company. In this article we tried to find interesting programmers’ jargon that can be an inspiration for all the copywriters out there who struggle to squeeze out a new name for a product or an article. We have stumbled across one fascinating topic on Stackoverflow.com about a new programming jargon. Here is the compilation of the most interesting expressions that can help you to understand how to speek geek, if your are a marketer.

Ancient egyptian

Egyptian operator brackets

if (a == b) {

Fear Driven Development

Development driven by Fear — when project management only adds fuel to the fire and exerts excessive pressure onto a developer.

Hope Driven Development

Development driven by Hope — development in the long-term unplanned cycle with a hope that eventually during a release everything works out fine.

Real waterfall model

Real waterfall model

Rob Busack: Real Waterfall Model

It was named so after a yearly Rob Busack Rapid Development weekend.


ReFUC*toring — by applying small changes getting completely unfunctioning code into a quality and well-structured code. There is another version of it: when one takes perfectly fuctioning code and by applying a lot of changes makes completely unfunctioing program.

Code — Baklava

Multilayered (multilevel) code


Click with more enthusiasm/incorrect finger/hold a mouse properly

Developers’ reaction to the testers’ claims that something does not work using one or another input device.

Typical conversation:

Tester: Module X does not work correctly.
Developer: Show me the testing steps
Tester: I touched it, after that… oh, wait, everything work now.
Developer: With which finger do you touch the screen?
Tester: Forefinger.
Developer: You must have used the wrong finger before that.
Tester: Yes… Probably.

strigly typed

Stringly typed vs strongly typed

Using strings as parameters where more suitable types can be used instead

Natural selection

Replacement of other people’s code with your own.



frAGILE — infuriate people by incorrect usage of Agile methodology.

Project manager: Let’s use Agile methodology!
Developer: Okay. I will do minimum to achieve the essential business-functionality.
Project manager: Great!
Developer: We can do refactoring once all the other parts are built. Now it is not important.
Project manager: Good. We should do no more than what is absolutely necessary.

Later in the project…

Developer: We need refactoring, because code is unmaintainable.

… Afterwards…

Project manager: Looking for excuses to cancel launching:

  • We can do that a little bit later
  • If everything works fine, why to change anything?
  • We do not have time for that «refactoring»
  • I promise we will do it later

As a result: Developer suffers from growing incoherent code-spaghetti and nobody cares about it.

Chief technical officer: Agile is hideous! We will never use it again! Waterfall model rules!


Developing a special version of product release to set up on the Boss’s computer. For example, Boss-build can include endless list of special fonts, colors, sizes and different locations of control elements, which change every few days.

James Bond Interface

Contract is well-defined and well-documented, but in reality nothing is implemented


Avoidance of object-oriented design when it is actually preferable and even desirable.

OOP, Over Oriented Programming

It means usage of five class levels, when one is already enough.

Bukazoid documentation pattern

The description is useless and does not help with any code-related questions. One can use any non-existing words instead of bukazoids.

* Bukazoid manager is a manager to manage bukazoids.
public class BukazoidManager extends SomeOtherClass {


The Perkov Method

The Perkov Method — a programming style based on commentaries in form of preudo-code and assumptions to ensure that there is no missing functionality when someone decides to do code reviews or implementation. By the end, commentaries can be 4 times more detailed than it was actually needed in the first place. Example: regular implementation of Hello World:

class Program
static int Main(string[] args)
Console.WriteLine(“Hello World”);

The Perkov Method implementation:

class Program
static int Main(string[] args)
// at this stage it really should be displaying any text to the
// console. we must take into consideration 78 character maximum line length
// and make sure that we employ Environment.NewLine for line endings.
// in the perfect scenario there should be multi-region language support and UTF-8 /
// UTF-16 encoding.

ship in the bottle

Ship in a bottle – an API that is so over-simplified that it is just too difficult to use.

To see an illustration of this, in the beginning there is well-written polymorphic code, then we get rid of all the derived classes, and put a state bag in the base class that keeps all information that used to live in the daughter classes. For a good illustration of this in hardware, imagine a remote control with only one button that requires you to enter commands in Morse code.

ping pong

Ping Pong Development Methodology

Hit it hard until it doesn’t bounce back
Also known as “using your end-users as QA”… quickly write some raw code, see if it is working for your users, if it does not, code some more, rinse, repeat

Darwin/Experimental programming – keep changing the code (randomly or deterministically) without the understanding the meaning of the changes until it finally does-the-right-thing. Very useful, for instance, when deciding between + or – inside a function. This can be highly productive if one deals with external APIs without proper documentation.

tech debt

TDDD: Technical Debt-Driven Development

Development driven by technical debt, e.g. when a developer constantly puts fixing and cleaning code on hold.