Why these developer job titles are ridiculous and shouldn’t exist
So you’re interested in Growth Quarters? Then join our online event, TNW2020 , where you’ll hear how the most successful founders kickstarted and grew their companies.
Similarly to the nobility in the Middle-Age who loved enslaving poor villagers to make lords and knights rich and powerful, we, software developers, love titles.
A glimpse at one’s title and you’ll know exactly what the developer is capable of, and how much value he’ll bring to the company. How useful! How magical!
We don’t have lords, kings, and buffoons in our little Software Development World. However, your favorite recruiter, CTO, COO, CEO, or whatever C-level manager, might enjoy calling you “coder,” “programmer,” “developer,” “web developer,” “front end developer,” “software developer,” “software developer engineer,” “devops,” “architect,” and even “consultant.” They might use more exotic terms too, depending on the creativity of your management.
These titles aim to describe your role in the company. If you’re lucky (trust me, you’ll be), they will be prefixed by a beautiful “Junior,” “Senior,” or “Wizard,” showing your rank and your greatness to your peers.
People holding these titles will share some common features. They are technical people who know how to code, and who will more or less spend their days coding. Consultants should not do that though, but it’s another subject.
We’ll see, in this very profound, thought-provoking, and mind-bending article:
What are the meaningful titles you’ll encounter?
Why millions of them are useless, and what other possible titles should we use?
What are the titles which will catapult you to the bottom of your favorite company’s organizational chart?
I can see that you can’t wait to answer all these crazy questions! How do I know? I’m a Senior Developer: I know everything!
To be honest with you, I can’t wait either! Let’s begin.
Title as a role
The meaningful titles
Some titles can give you an overview of your work if you hold them. Don’t expect to be enlightened though, they carry very basic information.
1. The frontend developer
This special specie of developer will deal with everything the end user can see or interact with, when the crazy software will be available to the populace. Typically, he’ll code using some good old CSS, HTML, and often JavaScript.
Managers might venerate them, amazed by so many buttons, colors, and little dogs flying all over the software. This can be a blessing, or a fatal curse.
2. The backend developer
The mortal enemy of the frontend developer, the backend developer is a troglodyte who deals with everything nobody sees. He’ll put together the gears and cogs of a software, if you will. Try to open your car’s hood: it looks boring and complicated, but without it your car would have difficulties to move around.
Most people won’t understand what backend is about, not because everybody else is stupid, but because nobody cares. As a backend developer, I definitely respect that. I don’t care about cars, either.
3. The web developer
A web developer is somebody coding anything which can be fetched using the amazing World Wide Inter Web. If you lived under a rock the past decades, it’s a mess of websites, linked all together with hyperlinks. A big corporation mostly controls what website you’ll see and consult. Its name begins with a “G.” Can you spot it?
The web developer is often opposed to a more “traditional” kind of developer who develops desktop applications. These applications are not executed by a resource-intensive browser but by an OS (Operating System). Why somebody would do that? I don’t know. Performance, maybe?
The titles which should exist
Except for the titles described above, titles describing some roles won’t give you any clue what the company really expects from you. You’ll spend some time coding in some wonderful offices, of course. After that, your fertile imagination can let you create the most amazing role which will disrupt the whole industry, the whole world, or the multiverse itself.
What’s the point to be a “software engineer” instead of a “developer’? Nobody agrees, because nobody really knows.
Since I have a whole article to write, let’s forget these titles and, instead, let’s describe the real roles you can have in a company.
These roles can be mixed. For example, a company might search a developer who’s 70% code monkey and 30% lonely coder.
1. The code monkey
If you care about development and the impact you have as a developer, you will thrive to be a code monkey as much as a fish will thrive to be in the Sahara.
As a code monkey, you’ll spend your time with your mouth shut and your finger producing billion of lines of code. You’ll be only there to follow blindly every decision taken by your superiors. Your name will be engraved in a scary and strict organizational chart.
For your managers, a developer is a worker on a production line: you have a plan, you follow it by the letter, and BAM! You have a software which will make everybody rich (except you, of course).
As a Code Monkey, you don’t think. You produce.
These companies have often a pretty poor company culture. It can be seen as an expensive experimentation to show how much scientific management (or Taylorism) is not a good idea for knowledge work.
Because of the strict hierarchy, expect the waterfall management style to be used, even if the company claims to be agile because of a whole array of ceremonies they carefully put on their Google Calendar: stand ups, retrospectives, you name it. Despite these ceremonies, the mindset of agile software development itself will be highly misunderstood.
You need to expect a high level of entropy regarding their projects, too.
Companies that want code monkeys might use fear and pressure when they won’t have the results they expect (and, trust me, they won’t). They will then impose infinite death marches to eventually burnout everybody.
After enough time to deplete your hopes and dreams, bankruptcy might be their ultimate fate, especially if we speak about startups.
If you are a code monkey, follow Gandalf’s precious advice: flee, you fool!
2. The lonely coder
Can you picture the end of countless old westerns where the hero, while the sun is going down, turns his back to the camera to go on new adventures, with his only friend, his horse? Then, the screen transition to black forever.
The lonely coder is alone too, but, contrary to the cow-boy, he has no horse, and the screen never fades to black. Loneliness stays till the end of time.
He’s the only developer on his project or, worst, in his company.
He has no chance to learn from anybody, nobody can back up his mistakes, and he has to endure every single crash and bug, without any shoulder to cry. What about feedback? Forget it.
The life of the lonely coder is full of sadness. Avoid this situation as much as you can.
If you work for a young startup (or a startup that is not growing), you’ll be likely to be the lonely coder. In that case, the risks could be acceptable when the potential benefits have more weight.
If you choose this path, you need to have a good experience as a developer, in the technologies the company uses, and in the business model of the company itself. In short, you need to know in what electric plug you put your fingers in.
Keep in mind though (and explain it to your management) that more than one brain on a project, which can support each other, is way, way better. We are all humans, we all do mistakes. No way around that.
3. The ultimate coder
The Ultimate Coder is the best of the best. He needs to know everything the other developers of the company know, plus the stuff nobody heard of.
He’s a human-Wikipedia-machine which can answer every question about random topics, a possible winner of “Who Wants to Be a Millionaire – Developer Edition.”
Infinity is not enough to speak about his knowledge and skills.
I see many companies searching for the ultimate coder. They are the Saint Graal in our industry. The ultimate goal of many recruiters out there.
Often, it doesn’t matter if they can work well with others, have good communication skills, or good soft skills in general. No: they need to be touched by the Light of Technical Knowledge, the Finger of All Technical Skills, the Breath of Every Technical Concepts.
Do you think many companies need this crazy amount of knowledge? Nop, not at all.
Very often, good-enough-code will serve companies better than more-than-perfect-software-which-will-be-still-shining-in-20-years-but-takes-two-years-to-have-two-functionalities.
If you cross managers who want The Ultimate Coder, you can be sure that they have no idea what kind of skills they really need to, to fulfill their goals.
There could be different reasons:
Their goals are never really defined.
Their goals change every two weeks.
It’s really common in the startup world.
It’s even more dangerous if they sacrifice soft skills on the shrine of purely technical skills and knowledge. You can end up with very good technicians who work in isolation, arrogant, with egos going through the roof. As some studies found out (including the famous Rework from Google), individual skills don’t really matter. The team dynamic and the complementary skills of each member do. It’s called collective intelligence.
The ultimate developer is essentially a myth, anyway. This title is often awarded to the developers who prepared the best for interviews.
Most of the time, if the company think they found one of this pearl, they might not even bring what the company really need.
4. The ultimate God
This is a funny variant of the ultimate coder. Not only he has every technical skill you can ask for, but he’s as well a talented designer, a magnificent project manager, a wonderful customer care member, and he knows everything about UX.
Searching a fullstack developer can be a conventional way to be on the quest of the ultimate God. The job description will often go into a lengthy list of technologies and skills the future employee needs to have.
After all, it makes sense: when you can have 10 employees in one, you reduce many costs.
Unfortunately, if the ultimate coder is a myth, the ultimate God is a scientific impossibility. Companies in quest of these ultra-dimensional beings will push any human, who can’t possibly be good in everything and anything, into burnout hell , before going themselves into a wall.
Runaway from this position, even if the salary is astronomical.
5. The fooled developer
Some companies are masters in the art of illusion. Most of the time, they even succeed to fool themselves.
The fooled developer is the unfortunate programmer who thinks that he’ll work for a company with a good culture. On the paper, he’ll have interesting responsibilities, he’ll be trusted, and, ultimately, he’ll find happiness 8 hours a day.
Instead, even if great and attractive principles will be thrown during the interview (they might even be displayed on the wall), the fooled developer will end up as a code monkey, an ultimate coder, or any other role nobody wants.
When you’ll speak, your superiors will node their heads in approbation, listening to every single of your idea. They might even begin to take action, but the result will be always the same: nothing will ever change.
Sometimes, the management will honestly project their dreams on the company, blind to the actual reality. It will make them passionate, convincing, and, accordingly, even more dangerous.
It can be as well a short term tactic to find or to keep developers when hiring is difficult and human resources scarce.
Being a fooled developer is never a good surprise. If you understand that your management won’t let you experiment and take your ideas into consideration, your motivation might take a slap in its face.
Again, try to find something better.
6. The valuable developer
A company searching a valuable developer understood that developers are not on this planet to code blindly, alone in their cubicles.
They are useful to understand problems and solve them using, most of the time, automation. You know, what software is usually good at.
A valuable developer brings value to a company, in form of money and/or time, not lines of code or other feel-good metrics.
They have a whole array of soft skills they might have learned with their experience. Even if they are beginner, they understand that communication, team effort, compromises, mentoring and healthy debates might be even more important than pure technical skills.
They are not only working with other developers, but are curious about many facets of the company, since they might affect the software’s features and the way they build it. Design, customer care, UX are taken into consideration.
The valuable developer, ideally, might have as well some knowledge about the mindset necessary to work iteratively. He’s not afraid of experimenting and going out of his comfort zone. He likes to test features quickly with real clients, to have the feedback necessary to see if everything is going in the direction the company wants to take.
The valuable developer is afraid of eternal meetings and developing huge features that can easily transform his life into an infinite death march, with late feedback and, therefore, no guarantee of any positive impact whatsoever for the user.
He likes metrics and studies to backup his ideas, avoiding the “everybody-does-it” and “it-is-known-that-this-is-the-way-to-do-it” arguments.
A company searching valuable developers will support them with good company culture: no blames and relative freedom, as soon as the work makes sense and is done.
They will be trusted, at every level, knowing that they like their work and, therefore, will thrive to do it correctly.
We should all aim to be the valuable dev, and we should all aim to find companies that understand and support this concept.
Title as a rank
Junior vs Senior developer
Let’s see now another side of this wonderful subject: the titles used to rank your potential and capabilities.
These titles will determine what position, in the company’s hierarchy, you have as a software developer. Don’t be a fooled developer: even if you’re working for a startup with a “flat hierarchy,” it’s commonly less flat than it pretends to be. Often, nobody took time to drew the organizational chart, but it exists anyway.
1. The junior developer
Every developer has been called “junior.”
You’re “Junior” if you don’t have “enough” years of experience in the software industry. You’re the rookie, the newbie, the unskilled mistake-maker. Congratulation!
It implies as well that you have less knowledge and skills than everybody else who has more experience than you. Therefore, you’ll be, in general, less useful, providing less value.
All of that stays pretty vague. If you look a bit closer, you begin to see some flaws.
First, how can you compare two developers who have a different experience and/or knowledge in very different areas, but still related to software development? Is a developer who studied cryptography still “Junior”, compared to somebody with 20 years of experience programming WordPress websites, without any knowledge in cryptography?
It’s difficult to compare the level of knowledge and skills. We mostly all learned differently our craft. The same amount of experience can translate in very different skills too, depending on the content of the experience itself.
Even worst: many years of experience don’t mean that skills improve. If a developer spent 10 years repeating the same mistakes (10 years of as a code monkey or as a lonely developer can produce this kind of expert beginner ), we can’t really speak of improvement.
Consequently, a “Junior” Developer can be better, more productive than our 10 years veteran.
Being a “Junior” has another monstrous flaw: many companies will use it to play on the impostor syndrome of our poor developer.
Somebody beginning in the industry won’t necessarily have a big self-confidence, and even if he has crazy problem-solving skills, a huge interest, and a superior will to learn than every other senior developer in the company, he’ll still be “Junior.” A “Junior” bringing a lot of value, but still not considered and paid as much as the others.
That’s another problem with this title: it will decide how many zeros your payslip will have. You’ll understand easily that many companies are eager to call everybody “Junior.”
To go against this tendency, as a “Junior” developer, you can show your results with metrics, diagrams, and whatnot to prove that yes, you’re bringing value to the company.
I won’t lie to you: this “Junior” concept is very strong in the common wisdom. It will be difficult for managers and developers to understand that you can be paid more than legacy-code-producers called “Senior.”
Finally, even if you have less knowledge and experience than more experienced developers, you’ll have a fresh approach to many problems and situations more experienced programmers won’t. This is an important quality of a beginner: not being stuck in old habits and wrong mindsets, which are difficult to unlearn.
If you didn’t understand yet, I don’t like to use “Junior” as a title. I prefer “beginner.” The difference is subtle, but to me a beginner is somebody who doesn’t have much experience, and that’s all. His value in a company can be as high as anybody else, and it should be the only metric deciding on his position and his salary.
2. The senior developer
If you’re not a senior developer yet, let me narrate you what will happen, someday.
You’ll wake up and you’ll hear a beautiful whispering in your ears. The whispering will soon become the most beautiful symphony you’ll ever hear. The music will be crystalline, flowing from the sky like the purest water would quench your thirst. You’ll be able to touch it, with all your senses.
The light around will intensify and envelop your soul, procuring an infinite feeling of joy and warmth. It will be like millions of comfy pillows surrounding your whole being. Then, it will be shown to you The Path to your Fate and the reason why you’re on Earth.
Fantastic Muses will give you all the knowledge you need and the self-confidence you lack. You will be blessed by the Perfection: no error will ever spoil your code again. Your software will become instantaneous masterpieces and commercial success. Praise, glory, and fortune will always be on your side.
This is how you’ll become a Senior Developer.
Unfortunately, I have the impression that some folks out there are still waiting for their enlightenment to happen, too insecure to call themselves “Senior.” Now, the reality: transitioning between “Junior” and “Senior” developer will be similar to a dice roll in our role-playing life. It can be after one, three, ten years of good and loyal services in a company, or by transitioning between one company to another. At that point, you might decide that, yes, you’re a senior.
In short: it’s random.
For many companies, being a “Senior” Developer is very similar to be The Ultimate Coder (see above). The “Senior” Developer should know a lot. He can answer any random question during an interview, and solve any weird challenge nobody heard of before, except the interviewers themselves. Most of the time, these tested skills will be useless for the actual, daily work the company needs to get done.
Theoretically, a “Senior” Developer is somebody who has a lot of experience and, therefore, who’s skilled. Practically, he’s somebody who can prepare well for twisted interviews .
Most of the time, he needs to know what the interviewer knows, or the “Senior” title will stay unreachable. These interviewers will claim that if the Senior Developer doesn’t know this or that, he’s not a Senior developer .
As we saw above, everybody can have a very different set of skill and knowledge. Somebody can be “Senior” compared to somebody else in one set of skills, but totally “Junior” to another one. We use the title “Senior” Developer as an absolute state, even if it’s a relative one.
Even worst: if a company searches exactly the same skills as every other developer they have, they won’t be able to learn a lot from each other. A team should thrive to have members with complementary skills, not clones. Otherwise, your collective intelligence, as a team, will stagnate.
Is the candidate a Valuable Developer? That’s what the interviewers should ask themselves. The industry is changing so fast (on the surface, the good old foundations stay the same), being able to learn quickly should be more important than what we already know.
Companies know as well what skills they need for their projects and recruit accordingly, instead of throwing again a fizzbuzz-like test to the face of their candidates.
The magical stealthy ninja warrior of the crown mounting a dragon
Did you see someone using a ridiculous title like “Rock Star,” “Ninja,” “Wizard,” or similar? Don’t lie. I’m sure you did.
Ninja! Wizard! That’s what I wanted to do when I was 8 years old. Unfortunately, my mom destroyed my dreams long ago. “These are no real jobs!”, she claimed. Little she knew! Mom! Look at me! I’m a Ninja now!
These titles will be thrown around to look cool and nerdy, most of the time by recruiters who have no clue what your actual job is about.
Ignore these. They are lame. I feel always embarrassed when people use them.
I’m sorry if you did use them to qualify your favorite developer (or to keep him in your company without increasing his salary). I need to remind you, however: we’re not 8 years old anymore.
Wrapping the titles up
What did we learn in this article?
Most titles are meaningless in a general context. Two companies searching for a Software Engineer can seek very different skills. Some titles are however meaningful, but they won’t give you a lot of information. We can however isolate some patterns of skills and mindsets the companies really seek and put funny titles on it.
Titles can be used to describe your role, but as well your rank in a company. Are you a “Junior,” a “Senior,” a “Wizard?” I vote for a “Fooled.”
Company’s managers who have a clear vision of what they want and where they want to go is always what you should seek. Otherwise, how can you add value to something which has no solid foundations?
From there, don’t trust the title they want to give you and try to see what they want and what they need.
As I was writing some months ago, if you want to change the company, try to do a trial day for them first. You can then learn about the managers’ intentions and the company culture.
Your technical skills are important, but they are only a mean to an end, not an end in themselves. If you’re a developer thriving to get better , with the mindset of a Valuable Developer, your knowledge will grow as a result, and your efficiency too.
There are millions of companies out there, and many of them are interesting to work with. You simply need to find them.
This article was written by Matthieu Cneude and was originally published on The Valuable Dev , a blog focusing on the important and timeless concepts in software development. You can read the piece here .
How to make small talk remotely — without sounding like a weirdo
Saying good morning, in person, to a coworker you don’t know is perfectly normal. Sending a private message to a coworker you don’t know to say good morning is…weird. If not downright creepy.
Look, that’s just how it is. I don’t make the rules.
Seriously, though: the difference between these two interactions is real, which is part of why remote work is lonely. There’s also not really any context for serendipitous small talk — you won’t run into anyone in the hallway, for example. All of this makes it hard to connect with coworkers, let alone make friends with them.
But that’s not to say it’s impossible. I’ve been working from home for over a decade. Learning to reach out to the people I work with is a key part of how I’ve made it work. The conversations keep me sane when things get hard. The connections give me more reasons to care about what I’m doing. And the friendships I’ve made along the way have lasted much longer than the jobs themselves. But all that only happens if you reach out — without being weird about it.
Why reaching out can feel weird
Let’s get back to saying “Good morning.” Why is it so different to say that in a direct message, as opposed to saying it out loud in an office? The weirdness, I think, comes down to choice. Saying “Good morning” out loud is reflexive because we’re conditioned to do it. You saw a person, it was morning, so you said good morning like a normal human person.
Typing “Good morning” and sending it as a direct message, meanwhile, isn’t reflexive at all; on the contrary, it’s an active decision you made. You looked for that coworker, clicked their profile, then used your fingers to type a message. That effort, small as it is, changes the context and meaning of the statement. Even if the literal words are only “Good morning,” the context creates the expectation that you want…something. That can feel weird. The good news: we now understand why this is weird, which means we can make it less weird.
The solution: explain why you’re reaching out. It’s really not any more complicated than that.
Don’t say hello without context, and don’t ask someone if they “have time to talk.” Always give a reason why you want to talk to someone.
Reach out to team members and offer to help
Whenever a new person joins my team, I like to reach out and tell them I’m around if they have any questions.
I do this to be helpful, first and foremost, but it’s also a great opening for a conversation. I’ll ask how people are finding the job so far, then maybe ask some questions about where they live. Remember: you’re not going to run into new employees in the break room, so you’ve got to create these sorts of conversations yourself. It can feel a little weird, but it’s the only way these chats will happen.
Respond privately to comments made in public channels
Another way to start a conversation is to respond privately to something someone said in a public channel. My Zapier coworker Katie told me a few ways she’s done this over the years, and I think it’s a great list.
Katie actually reached out to me a year ago with one of these strategies.
It turns out I really like being told I’m funny, because now we talk regularly. I’m not sure what that says about me.
Be vulnerable
Another idea is to share something about yourself. My coworker JC calls this offensive vulnerability, and it works.
It’s also okay if you can’t think of a reason to talk: Just explain that all you want to do is say hello. I find this is enough to remove the weirdness of just saying “hi,” especially if you frame it using a little humor. That’s my general strategy.
Don’t take delays personally
Did you reach out to someone? Good. Now go do something else.
It can be tempting to leave the window open and wait for a response, and sometimes people will respond immediately. But sometimes they won’t, and that’s okay. Everyone at your company has things to do, and that means not responding to every message right away. This can be a bit of an adjustment if you’re accustomed to in-person conversation, but it’s important that you get used to it. It’s nothing personal—just the nature of online communication.
You, presumably, also have things you should be doing. Do them! You’ll hear back eventually.
Respect the back-and-forth
The best in-person conversations are not one-sided—they have a natural give and take. Online conversation also works best this way, even if it doesn’t happen in real time. If you want your conversations to feel natural, you need to respect this back-and-forth. This means asking a question, waiting for people to respond, and only following up after that happens.
Do not, under any circumstances, send a trickle of messages to someone you only kind of know. That is going to be weird for everyone involved.
Don’t make it weird. Send one message, then wait for a response. Assume that your coworker saw the message and will respond, or not, on their own time. Don’t follow up on the same day (unless you actually need a response, for work reasons).
There’s always the chance that someone legitimately didn’t see your message, or saw it and forgot to respond. If you think that’s the case, it’s probably okay to send another message, ideally the following day. But if someone continually doesn’t respond when you reach out, please: take the hint. Some people won’t want to talk to you outside a work context, and that’s okay. Sure, it would be nice of them to be transparent about it and let you know they’re not interested in chatting, but regardless, don’t press the issue.
Respect people’s status and set your own
Apps like Slack let you set a status, which is a great way to let people know that you’re doing focused work or that you’re otherwise unable to respond. Pay attention to these and don’t reach out to chat when someone is busy.
For example, I try not to use Slack while I’m writing, so I set my status in Slack to “Writing,” complete with a typewriter emoji.
My coworkers know that I won’t respond quickly when they see this status.
You should also set up a status for yourself. You can do this manually, or you make it so your Slack status changes automatically based on your calendar, time tracking app, or to-do list. Either way, it helps your coworkers know when you’re available to chat and when you’re not.
Small interactions matter
Working from home can be lonely, but it doesn’t have to be. It’s just a matter of learning how to communicate in a different environment. And you should take the time to learn this skill because small interactions throughout the day matter—and they can lead to lasting relationships.
We’re all human. We want to be seen by others, and to see others clearly. We need connection. There’s nothing weird about that. Just take the time to learn how to best do this online, in ways that make everyone comfortable.
Speaking of weird: the above screenshots where I was being all creepy were staged.
Just wanted to clear that up.
My memory sucks — but it’s made me a better leader
Boris is the wise ol’ CEO of TNW who writes a weekly column on everything about being an entrepreneur in tech — from managing stress to embracing awkwardness. You can get his musings straight to your inbox by signing up for his newsletter!
For years now, I have been skiing with the same guide in Chamonix, and if circumstances allow, I’ll ski with him again this year.
I look forward to skiing with him, but there’s one particular moment that fills me with dread every year…
At some point, he’s going to start talking about the three steering elements — as he’s done every year I’ve visited Chamonix. Steering is an essential part of skiing, so if you want to become a good skier you need to dedicate a lot of time and attention to mastering these three techniques.
That’s why every year I spend a whole day practicing each of them under my ski instructor’s guidance.
Now, you might be wondering what the three important steering elements are… but I wouldn’t be able to tell you, even with a gun to my head.
Weird, right? But that’s just how my mind works.
I’m not stupid (or at least that’s what I’d like to believe), but my mind is very picky about what it chooses to remember and what it doesn’t.
My theory so far is that I’m focusing on his advice, as a whole, and applying this directly to my skiing without actually thinking about the detail or his exact words.
I have a similar thing when it comes to remembering stuff during the day. Here’s what usually happens: I do something and decide to remember it for later. Later, I will remember that there was something I was supposed to remember. I just don’t know what .
But that’s okay, because usually there’s a faint emotion somewhere, lingering in the back of my mind. I then find my way back to the thing I’d forgotten by tracing how the emotion was associated to it — and voilà! — I remember.
For example, if I remember I have forgotten something — and it has left me feeling good and excited — I’m reminded of that ice cream I made and put in the fridge earlier. Or, if the emotion was dread and discomfort, it reminds me I meant to remember to buy toilet paper…
Turns out I’m not alone in having a weird way to remember things. Over time I’ve started to notice all the small memory tricks people around me have.
One trick I’ve seen people use is to associate memories with rooms in a house. They’ll store a phone number in the hallway, a birthdate in the bathroom, and a meeting they need to remember in the attic.
Other use colors or songs. One way to remember things is to make a drawing while you try to memorize it. Looking at the picture will bring back the memories you stored.
My conclusion is that everybody stores their memories in their own unique way. And once you realize that, it becomes easier to make people around you take notice of what you want to convey to them.
It basically boils down to two tips.
First up, instead of just telling them something, it helps to realize we all remember and absorb information differently — so cater to this .
Suppose you need to make a presentation and make people remember the information in it. In that case, you might try using colors, images, music, or anecdotes to say the same thing in different ways — or allow people to take notes, draw, or stare out the window while you do it.
The second thing you could do is… well I’ve forgotten it. But don’t worry, I feel great just thinking about it — so it must have been a great point.
Can’t get enough of Boris? Check out his older stories here , and sign up for TNW’s newsletters here .