Words Don’t Compile

I wrote my first line of code at ten. It was either a small tweak to a WordPress plugin or a little C++ program I copied from a thenewboston video. The exact file is long gone, but the habit stayed. Since 2010 I have kept typing. For years, “writing software” for me meant working alone: class assignments, weekend hacks, half-finished web apps. Growth was easy to spot, the code spoke for itself.

That changed during my Google Summer of Code project with Apache. My mentor kept repeating one idea: show your work. Write a blog post, record a demo, tell people about it. I wondered why any of that mattered. Surely the code was proof enough. He disagreed, and the lesson stuck. I grew a habit to showcase my work, talk about it, share insights.

Types of Software Engineers

After joining my first company, as I was observing the software engineers around me, I could distinguish and categorize them into broadly four categories:

1. The talkers

2. The doers

3. The Talker & Doer

4. None of them (the worse of all, out of scope for this essay)

This is more of a spectrum; however, people often fall more or less in one of these categories.

As you might expect, being both a talker and a doer is the best place to be. That is where you really grow fast. What surprised me, though, was how much quicker the talkers moved up compared to the doers. I saw people who were just really good at looking busy, using all the right buzzwords, and acting like they always knew what was going on. They outgrew the quiet builders. I remember talkers getting promoted faster than the doers, and I could not understand it at first.

The Talkers

I wanted to understand this talker persona more. As I kept watching, a pattern started to emerge. Software engineering is complicated, and most managers have no real way of knowing what is actually happening. They have to trust what team members tell them. If you are great at talking, it works in your favor. You can claim you worked on something even if you just sat next to someone else while they wrote the code. Impact is hard to measure in software. Sometimes the smartest work is just choosing the right library and finishing a task in one day, but it is easy to make that same task look like a week’s worth of effort with the right words. You can make simple things sound much more complex than they really are.

You might say it is the manager’s job to notice this, to figure out who is just talking and who is actually building. I agree, sometimes it is their responsibility. Still, I started to see the talkers almost like scammers. If you are good enough at talking, you can get promoted and collect all the rewards without really doing the work.

There is a problem with relying only on talk. Sooner or later, you cannot talk your way out of every situation. I have seen this play out more than once. Eventually, things will catch up with you. If all you have done is talk, you will get stuck. Maybe there is a production issue, and the person who did the real work is no longer around. You end up exposed, unable to fix the problem.

Even among talkers, I started noticing two broad types. Some are fully aware of what they are doing. Others are completely delusional. The second type is the most dangerous. Delusional talkers honestly believe they are doing a great job. They always have a reason or excuse when things go wrong, and they are rarely at fault in their own minds. This is dangerous both for the individual and for the company. Hiring someone who is a delusional talker is probably the worst thing you can do to your team.

Grow Fast

What worked for me might not be exactly what will work for you, but I want you to pause and really ask yourself, which one are you? Are you someone who talks enough about your work? Are you actually talking enough? Be honest.

Are you mostly a talker? If so, that is not always easy to admit. The hardest question of all: are you a delusional talker? This one is tough to see in yourself, but try to be brutally honest. Put yourself in the right category.

The goal is simple. You should aim to be both a talker and a doer.

If you are mostly building and not talking, you need to change. Start sharing what you have done. Show your impact. Write a blog post about your project. Share updates in a Slack thread. Make your self-review detailed, listing every achievement. Keep regular notes about your work. In your one-on-ones with your manager, talk clearly about what you did and how it helped the company.

If you are mostly a talker, remember that success is often temporary if there is no substance behind it. You are walking a very thin line. Take those buzzwords and back them up with real work. Deliver results. I promise, it will be much more satisfying in the long run.

Most people fall somewhere in between. Some talk more than they do, and some do more than they talk. Every engineer is different, but if you want to grow quickly, you need both. You have to do the real work, and you have to make sure people see the value of what you have done.