DEV Community: Malik Moazzam

How Word Games Turn a Random Set of Letters Into Meaningful Words

Malik Moazzam — Wed, 21 Oct 2026 16:14:23 +0000

How Word Games Turn a Random Set of Letters Into Meaningful Words

Have you ever looked at a group of scrambled letters and wondered how many words you could make from them?

Word games make this process look simple. You enter a few letters, and within seconds, you might find several possible words. But behind that simple experience are interesting problems involving data structures, search algorithms, and user interface design.

Understanding these concepts is useful if you want to build a word game, a vocabulary application, or a small browser-based puzzle.

Let's look at how the process works.

Start With the Problem, Not the Interface

Imagine a player enters these letters:

A E R T

Depending on the game's rules and its dictionary, possible answers include:

EAR
EAT
ARE
TEA
RATE
TEAR

The first challenge is deciding what counts as a valid answer.

Does the game accept only common English words? Are proper nouns allowed? Can a letter be used more than once? Are two-letter words acceptable?

These decisions matter because they determine how the game should search for answers.

A useful word game needs a clearly defined set of rules before the algorithm is written.

Understand the Difference Between Permutations and Anagrams

A permutation is an arrangement of items in a particular order. An anagram is a word formed by rearranging the letters of another word or letter sequence.

For example, the letters in LISTEN can be rearranged to form SILENT.

A simple approach to solving anagrams is to generate every possible arrangement of the input letters and check whether each arrangement exists in a dictionary.

However, this approach quickly becomes inefficient.

For a sequence of six distinct letters, there are 720 possible arrangements. For ten distinct letters, there are 3,628,800.

Generating every arrangement is often unnecessary because many arrangements will not be valid words.

A better approach is to search a dictionary of known words and compare their letters against the input.

Use Letter Frequency to Find Anagrams

One practical technique is to count how many times each letter appears in a word.

Consider these two words:

LISTEN

SILENT

Both contain exactly one L, one I, one S, one T, one E, and one N.

Because their letter frequencies match, they are anagrams.

In JavaScript, you could create a simple function to generate a normalized signature for a word:

function getLetterSignature(word) {
return word
.toLowerCase()
.replace(/[^a-z]/g, "")
.split("")
.sort()
.join("");
}

console.log(getLetterSignature("LISTEN"));
console.log(getLetterSignature("SILENT"));

Both outputs will be:

eilnst
eilnst

The function converts the input to lowercase, removes characters outside the English alphabet, sorts the letters, and joins them into a string.

Two words with the same signature are anagrams under these normalization rules.

For a larger application, you could improve this approach by using letter-frequency arrays or maps instead of sorting every word repeatedly.

One limitation is that this example handles only the English letters A to Z. Other languages may require different normalization rules.

Choose a Suitable Data Structure

Suppose your application has a dictionary containing thousands of words.

Checking every possible arrangement is usually wasteful. Instead, you can preprocess the dictionary and group words by their letter signatures.

For example:

const words = ["listen", "silent", "enlist", "rat", "tar"];

const groups = new Map();

for (const word of words) {
const signature = getLetterSignature(word);

if (!groups.has(signature)) {
groups.set(signature, []);
}

groups.get(signature).push(word);
}

console.log(groups.get(getLetterSignature("listen")));

The result will contain:

["listen", "silent", "enlist"]

This technique is useful when an application needs to answer many anagram queries against the same dictionary.

Instead of rebuilding the search from scratch for every request, the application can reuse the groups it has already created.

For a production application, the dictionary should be loaded and indexed once rather than rebuilt every time a player submits a word.

Make the User Experience Part of the Solution

A technically correct word solver can still be frustrating to use.

Imagine entering a set of letters and receiving hundreds of results without any explanation or organization.

A better interface should help players narrow down the results.

Useful features include:

Filtering results by word length.
Showing shorter words before longer ones.
Ignoring accidental spaces around the input.
Displaying a clear message when no words match.
Explaining whether repeated letters are allowed.
Making the interface usable on mobile devices.

Performance also matters. A search that takes several seconds may interrupt the flow of a casual puzzle game.

If the dictionary is large, consider indexing it in advance and avoiding unnecessary calculations during each search.

Test With More Than One Example

Testing a word game with a single example is not enough.

Try inputs containing repeated letters, such as LEVEL, as well as short inputs and combinations that produce no valid results.

Also test how your application handles:

Empty input.
Uppercase and lowercase letters.
Leading and trailing spaces.
Repeated characters.
Unsupported characters.
Words that are absent from the dictionary.

These tests help reveal problems that might not appear during normal use.

It is also worth remembering that a dictionary is not the same as a universal definition of a valid word. Different games may use different word lists and rules, so your results should match the expectations of your intended audience.

7. Explore Different Ways to Solve Word Puzzles

Once you understand the basic algorithm, you can experiment with more advanced features.

For example, you could build a game that provides hints instead of revealing every possible answer. You could add a timer, award points for longer words, or create daily challenges using a fixed set of letters.

If you enjoy experimenting with anagrams and rearranging letters, LetterCracker is another place to explore word-solving ideas.

The important thing is to understand the problem your tool is solving and make the experience useful for the people who need it.

Final Thoughts

Word games are a good way to practise programming because they combine familiar problems with real technical decisions.

Anagram matching teaches you about string normalization and data structures. Dictionary searches introduce performance considerations. Input validation and result filtering demonstrate why user experience matters just as much as the underlying algorithm.

Start with a small dictionary and a simple matching function. Test it with different inputs, measure its performance, and improve it when you identify a genuine limitation.

You do not need a complicated algorithm to build a useful first version. You need a clear problem, a sensible approach, and enough testing to make the result reliable.

The Secret Code POWs Tapped Through Prison Walls (No Radio, No Ink, Just Knuckles)

Malik Moazzam — Wed, 23 Sep 2026 12:51:19 +0000

In 1965, US Navy pilot Charles Boyd was shot down over North Vietnam and taken to the prison later nicknamed the "Hanoi Hilton." Guards forbade any talking between prisoners. What they couldn't stop was tapping.

Boyd and fellow POWs used a system that traces directly back to Morse code, adapted into something called "tap code" — a 5x5 grid where letters are represented by a pair of knock counts (row, then column). No dots, no dashes, no equipment. Just knuckles on concrete, or a spoon on a pipe.

Why a Grid Instead of Dots and Dashes

Standard Morse relies on two clearly different signal lengths — short and long. That's easy to send with a key or a flashlight, but nearly impossible to send reliably by tapping, since a "long tap" and a "short tap" sound almost identical through a wall. So POWs (the method is credited to Air Force Captain Carlyle "Smitty" Harris, who'd learned a version of it during survival training) swapped duration-based encoding for count-based encoding: tap, pause, tap-tap = row 1, column 2 = the letter "B."

It's a small but clever engineering trade-off — same underlying goal (compress the alphabet into a physical signal) as Morse code, but re-optimized for a completely different channel with different noise characteristics. Anyone who's worked with signal encoding will recognize the pattern: the "protocol" changes shape depending on the medium, even when the information being sent is identical.

Prisoners used tap code to share names, warn each other about interrogations, and — perhaps most importantly — to simply stay sane and connected during years of isolation. Entire conversations happened one knock at a time, through walls, without guards ever noticing.

Trying It Yourself

If you want to see how the grid system actually maps letters (and how it compares to standard dot-dash Morse), there's a breakdown of it here: Tapping Morse Code — How It Works. You can also cross-reference it against the full Morse alphabet, or run text through a live Morse translator to see the dot-dash version side by side.

Wild that a wartime survival hack from the 1960s and a 19th-century telegraph encoding scheme are, underneath it all, solving the exact same compression problem.

Morse Code Isn't Dead: A Developer's Look at the Original Binary Encoding

Malik Moazzam — Wed, 23 Sep 2026 12:33:07 +0000

Before ASCII, before Unicode, before a single bit was ever flipped in a computer, there was Morse code — arguably the first widely-used binary-ish encoding scheme in human history. As developers, we spend our days thinking about encodings, compression, and signal-to-noise ratios. Morse code nails all three, using nothing but a switch and a wire.

The Original Variable-Length Encoding

If you've ever implemented Huffman coding, Morse code will feel oddly familiar. Samuel Morse and Alfred Vail didn't just assign random dot-dash patterns to letters — they assigned shorter codes to the most frequently used letters in English. That's why E is a single dot and T is a single dash, while rarely-used letters like Q and Z get four symbols.

This is the same core idea behind modern entropy coding: minimize the expected message length by weighting symbol length against frequency. Morse code was doing this in 1836.

Timing Is the Real Protocol

The dots and dashes get all the attention, but the actual "protocol" is in the timing:

A dot = 1 unit
A dash = 3 units
Gap between symbols in a letter = 1 unit
Gap between letters = 3 units
Gap between words = 7 units

That's it — an entire messaging protocol defined by a single ratio. It's self-clocking, works over almost any medium that can be turned on/off (radio, light, sound, a tapped pencil), and degrades gracefully under noise — which is part of why it's still the backup communication method taught to sailors, hams, and pilots.

Where It Still Matters Today

Morse code hasn't been required for a ham radio license in most countries for years, but it hasn't gone away either:

It's still the fastest way to send a message with almost no equipment (a flashlight, a radio carrier wave, or literally tapping on a wall)
It's used as an accessibility input method for people with limited mobility
SOS (··· --- ···) remains the universally recognized distress signal, precisely because it needs no shared language to decode

Playing With It

If you want to actually see the encoding/decoding logic in action rather than just read about it, I put together a free translator that converts text to Morse and back in real time: QuickMorse. There's also a breakdown of the full alphabet and timing chart if you want the reference table, and a page specifically on tapping Morse code by hand (useful if you ever want to try the "tap code" variant without any equipment at all).

Would be curious if anyone here has built a Morse encoder/decoder themselves — feels like a great weekend project for playing with signal processing or Arduino/audio APIs.

How Morse Code Works: From Dots and Dashes to a Browser-Based Translator

Malik Moazzam — Mon, 21 Sep 2026 12:43:32 +0000

Morse code is one of the simplest communication systems ever created. It represents letters, numbers, and other characters using combinations of short and long signals.

The basic symbols are:

. = dot

= dash

For example:

A = .-
B = -...
C = -.-.
S = ...
O = ---

This makes SOS:

... --- ...

Although the basic idea is simple, building a modern Morse code application involves much more than replacing letters with dots and dashes.

Understanding Morse Code

Morse code assigns a unique pattern to different characters. A complete system can include letters, numbers, punctuation, and special communication signals.

If you're learning Morse code for the first time, this Morse Code Guide provides an overview of how the system works and how the different patterns are structured.

One interesting thing about Morse code is that the system can represent the same information in several forms. A person can read dots and dashes visually, hear Morse as audio, or send it using physical signals such as tapping.

How a Morse Code Translator Works

A basic text-to-Morse translator can use a JavaScript object containing character mappings.

For example:

const morse = {
A: ".-",
B: "-...",
C: "-.-.",
D: "-..",
E: "."
};

The application can then:

Read the user's text.
Convert it into individual characters.
Find each character in the Morse mapping.
Replace the character with its Morse equivalent.
Join the results together.

For example:

HELLO

becomes:

.... . .-.. .-.. ---

The reverse process can be used to decode Morse back into normal text.

You can experiment with both directions using the QuickMorse Morse Code Translator.

Morse Code Is More Than A-Z

A useful Morse application should not only support the English alphabet.

Morse systems can also represent:

Numbers
Punctuation
Special signals
Prosigns
Different historical Morse systems

Prosigns are particularly interesting because they are used as special signals rather than ordinary letters. Understanding them becomes important when building a more complete Morse decoder.

Why Timing Is Important

Morse code is not only about dots and dashes.

When Morse is transmitted as sound, timing becomes part of the information.

A dot is a short signal and a dash is a longer signal. There are also specific gaps between parts of a character, between characters, and between words.

The transmission speed is commonly described using words per minute, or WPM.

This means a Morse audio generator needs to control things such as:

Tone duration
Dot length
Dash length
Character spacing
Word spacing
Transmission speed

Changing the WPM changes the timing of the entire transmission.

Building a Morse Audio Decoder

Decoding Morse from an existing dot-and-dash string is relatively straightforward.

Decoding Morse from audio is much more challenging.

A simplified audio decoder might work like this:

Microphone
↓
Audio signal
↓
Detect signal and silence
↓
Measure signal duration
↓
Identify dot or dash
↓
Identify character boundaries
↓
Decode Morse
↓
Display text

Real-world audio introduces additional problems such as background noise, microphone sensitivity, inconsistent transmission speed, and changes in signal volume.

These challenges make audio Morse decoding an interesting browser-development project.

Morse Code and Amateur Radio

Morse code is still associated with amateur radio and continuous-wave communication, commonly called CW.

Radio operators can use Morse for communication when appropriate, and learning Morse remains an important skill for many radio enthusiasts.

This Morse Code Ham Radio guide explains how Morse is used in amateur radio and introduces some of the concepts behind CW communication.

From a development perspective, amateur radio is also an interesting example because Morse can be transmitted and received through real hardware rather than only through a website.

Learning Morse Code

There are several ways to learn Morse code.

A traditional approach is to memorize the dot-and-dash patterns for every character.

Another approach is to learn the sounds and rhythms of the characters so that they can eventually be recognized without consciously counting individual dots and dashes.

Practice is important either way.

A good practice system can randomly generate Morse characters and ask the learner to decode them. It can also work in the opposite direction by showing a character and asking the learner to send or identify its Morse representation.

A Morse Code Practice tool can be useful for this type of interactive practice.

The key is consistency. Short practice sessions repeated regularly can be more manageable than trying to memorize the complete Morse alphabet in one sitting.

Morse Code in Real-World Systems

Morse code has been used in many different communication environments throughout history.

It became especially important in telegraphy and maritime communication and later remained relevant in areas such as amateur radio and navigation.

Morse also appears in aviation-related systems.

For example, certain radio navigation identifiers can be transmitted using Morse code. This Morse Code for Aviation guide explains the relationship between Morse code and VOR and NDB identifiers.

Morse can also be useful as an accessibility and alternative communication concept because information can be represented through sound, visual patterns, or physical signals.

Morse Code as a Web Development Project

Morse code makes a surprisingly good programming project because the basic idea can start very small and gradually become more sophisticated.

A beginner can start with a simple character-mapping system.

From there, additional features can include:

Text-to-Morse conversion
Morse-to-text decoding
Audio playback
WPM controls
Keyboard input
Morse practice exercises
Audio decoding
Responsive interfaces
Accessibility features

This creates an excellent opportunity to learn JavaScript while building something users can actually interact with.

It also demonstrates an important software-development principle: a simple concept can require considerably more engineering once real-world input and usability are introduced.

Final Thoughts

Morse code may have originated in the era of telegraphy, but the underlying concept remains interesting for modern developers.

The basic system uses only short and long signals, yet those signals can represent complete messages.

When you try to turn Morse code into a modern web application, you encounter interesting challenges involving string processing, timing, audio, user interaction, decoding, and accessibility.

That makes Morse code more than just a historical communication system. It can also be a practical project for learning how software turns a simple concept into an interactive tool.

If you want to experiment with Morse code directly in your browser, you can try the QuickMorse Morse Code Translator.