Every industry has its slang and its buzz words. The tech industry just takes it to extreme levels.
The latest buzz word is vibe programming. I’m not going to write about that today, but it did lead me down the rabbit hole of interesting programming terms. And after chasing down the rabbits, I came up with ducks.
Unless you’re a farmer, you probably don’t think about ducks very often. If you ever attended course on our premises, you might have seen the ducks on the koi pond. Lewis still feeds the one last duck – and the wild geese and moorhens that have made themselves at home.
It’s a duck!
Most programmers will know the term duck-typing.
First a simple explanation for the not-so technical. In programming, you have to know what the type of a piece of data is. If it is a number, you can multiply it, but you can’t convert it to uppercase. If it is text, you can convert it to uppercase, but you can’t multiply it (except in Python, but let’s not go there). It’s like the format of a cell value in Excel.
This is important in coding, so many programming languages are very strict about it. You have to decide up front what kind of data you are working with.
But some languages use duck-typing, which is a more relaxed approach to types. The term comes from the saying: “If it walks like a duck and talks like a duck, then it’s a duck.” It’s a great feature – unless your duck turns out to be a chicken in disguise.
The duck feature
I have never heard of this before. But I read it on the internet, so it must be true! On a more serious note, I can imagine it happening on some projects.
A duck feature is “fake” functionality. Its purpose is to draw the attention of product managers, who will want it removed. This will distract the product manager from wanting other, more challenging, changes.
Here’s an explanation from one contributor on Reddit:
*It’s called a duck, from a legend that allegedly comes from Interplay’s Battle Chess…
It was well known that producers (a game industry position, roughly equivalent to PMs) had to make a change to everything that was done. The assumption was that subconsciously they felt that if they didn’t, they weren’t adding value.
The artist working on the queen animations for Battle Chess was aware of this tendency, and came up with an innovative solution. He did the animations for the queen the way that he felt would be best, with one addition: he gave the queen a pet duck. He animated this duck through all of the queen’s animations, had it flapping around the corners. He also took great care to make sure that it never overlapped the “actual” animation.
Eventually, it came time for the producer to review the animation set for the queen. The producer sat down and watched all of the animations. When they were done, he turned to the artist and said, “That looks great. Just one thing—get rid of the duck.”*
Talk to your rubber duck
Rubber duck debugging – or rubberducking – is a way of debugging code by talking about the problem.
You may have experienced this. You explain a problem you have to someone, even someone who doesn’t understand the topic. In the process of explaining, you figure out the solution.
Many programmers have had this kind of experience. The idea is to describe a coding problem line by line. It is more effective to explain to an inanimate object – like a rubber duck – than to think aloud without an audience. And you don’t have to interrupt anyone else.
The rubberduckdebugging.com website provides clear instructions:
- Beg, borrow, steal or buy a rubber duck.
- Put the rubber duck on your desk.
- Explain to the duck what your code is supposed to do. Go into detail and explain your code line by line.
- At some point you will tell the duck what you are doing next, and then realise that that is not in fact what you are actually doing.
While a coworker can substitute for the duck, it is often better to admit mistakes to the duck.
There’s some good psychology behind this. Feeling stuck? Get a rubber duck! If you enjoyed this, please share your comments.