Introduction

Throughout my career, I've worked on teams across the effectiveness spectrum. I've encountered relatively few developers I would consider truly "effective." By "effective" in this context, I mean developers who: spot problems others miss, foster cooperation that makes everyone's work easier, and benefit the entire organization beyond their immediate projects. I'll describe three key behaviors I've observed in these exceptional individuals: taking action beyond boundaries, embracing open communication, and practicing with clear purpose. Some of these behaviors I practice myself, while others I've witnessed firsthand. I'll also highlight behaviors that developers often think help them, but actually limit their effectiveness.

Being Active vs Passive

At first glance, this seems rather obvious. Being active means speaking up, asking questions, and engaging in your work—versus silently accepting tasks, fulfilling bullet point lists, and clocking out for the day. Of course, the former refines requirements better, ensures you build the right thing, and can even change the course of the work you pick up. This is a fundamental trait of being effective. But I'm referencing going one step beyond that.

All too often, I've seen people notice problems and do nothing about them. For instance: "This pipeline takes forever, but we don't have permission to edit it," "The other team keeps making breaking changes to this library," "These tickets always make no sense." Such problems are often auxiliary to your day-to-day work—they'll be raised in a "retro" and be actioned months down the line, if they ever are.

In these situations, I find effective individuals don't wait for a retro, don't shy away from reaching across organizational boundaries, or hesitate to enforce a new means of working to overcome problems. They just do it. They don't ask for permission (within reason, of course) and if they need cooperation from someone, they ask—even if it's someone they've never spoken to before. They'll ask the DevOps team if they can take ownership over that pipeline, they'll inform that person who keeps raising PRs on that library making breaking changes and come up with a solution, they'll figure out the right people who should be writing those tickets.

This is all to say, effective developers do not constrain themselves to "their lane." They take full ownership and impact the whole development process, spanning teams, business, testing, deployment, and beyond. Crossing these perceived boundaries and taking action where others see barriers is what truly sets them apart. They understand that effectiveness isn't confined to "their lane"; it's defined by improving the entire system.

Embracing Open Communication

I used to always communicate behind closed doors. If I had a problem, I'd directly message someone I thought could help. Sometimes this results in " person ping-pong"—"you should ask X," X says "you should ask Y," and so on. If life looks upon you favorably, you eventually get the answer! Whether you're caught in person ping-pong or struggling to get answers at all, both outcomes are problematic because your communication has limited visibility. I have found that often this knowledge is useful for an entire team, or someone you've never even heard of sees something wrong in the answer you've been given.

On a project, a developer told me, "Just ask in the project channel, it's better." It's such an obvious, simple thing to do, and it overcomes all the issues with private one-on-one communications. It spreads knowledge and utilizes the collective intelligence of everyone who sees it.

I don't see many developers do this, but every effective developer I have worked with has done it, which I never noticed until this experience. I encourage anyone reading this to default to open communication in this way.

A caveat here is that private conversations do still hold value for intense discussions or sensitive information. Your organization's culture may also not support this approach, but leading by example in this way can promote this culture (another trait of effectiveness).

Developing Through Purposeful Practice

Frequently developers upskill themselves via various means of katas, books, and side-projects. I've met developers who practice in these ways religiously, yet they're extraordinarily ineffective—in fact, sometimes downright counterproductive to a team. This is because they do not practice with purpose.

The Kata Trap

Some people swear by coding katas. They'll do one every week, or they'll do the same one 20 times and experiment with different solutions ("patterns"). Katas, while not entirely useless, train a very specific set of skills: problem solving, data structures, and technologies (languages, libraries, etc.).

Katas are very useful for starting to learn a language or developing your problem-solving skills in a particular area. However, you must practice them with a purpose, otherwise you don't develop yourself in a meaningful way. I've witnessed many developers get enamored with katas, only to still get stuck and lack confidence in themselves when it comes to real work.

Books and The "Coding Philosopher" Pitfall

There are many books written on software development. They can contain useful or thought-provoking information, however, mindless consumption can hold you back. Some of the worst developers I have ever worked with could implement unnecessarily complex solutions to simple problems (like this satirical enterprise FizzBuzz implementation), explain every part of it, and unironically relish in its "elegancy."

Their code is hard to understand, change, and read without being clued in on all their computer science theory. Talking to them can also be difficult due to their use of esoteric terms or very specific definitions for otherwise vague terms everyone commonly uses. In the end they develop intricate, overengineered systems that are difficult to maintain—all justified by theoretical "best practices."

Theory without grounded application leads to complexity for its own sake. Effective developers balance knowledge with practicality. They value clarity, simplicity, and maintainability over intellectual grandstanding. Be careful when consuming opinionated media—back it up with your own experience. Put into practice what you consume to enforce an opinion in yourself, and do so in the context of real-world application.

Pick Projects That Matter

The best developers I know build projects that matter, and they build many of them. These projects should matter to you or someone who uses them; this ensures they solve a real-world problem. This is by far the most practical way to develop skills.

Building solutions from concept and design through to deployment gives you a well-rounded skillset that provides real value. You'll encounter real problems, need to develop real solutions, using real problem-solving techniques you'll develop. You'll feel the value in pipelines you build, tests (if you need them), and any technology or methodology you choose to adopt. You will be exposed to genuine challenges: incomplete requirements, real user feedback, performance bottlenecks, deployment issues.

It is important to note that this is not required to be an effective developer. But it dramatically rounds out your skillset in all the areas that matter when developing solutions at scale.

My key recommendation here would be to focus on building projects and ignore katas unless it is a very targeted exercise to learn a very specific thing. I recommend against doing katas for design patterns, since the benefits of such patterns cannot be seen or even understood at such a small scale. While reading books, articles, and other resources, always keep a critical mind and don't get carried away on semantics or computing word salad.

Conclusion

These three behaviors—taking action beyond perceived boundaries, embracing open communication, and practicing with genuine purpose—represent just some of the ways effective developers stand out from the crowd. While not an exhaustive list, they are behaviors I've consistently observed making a significant difference in developer impact.

Effective developers don't wait for permission to fix problems; if they can provide value, they just do it. They keep their communication open and public, benefiting the entire team rather than hiding knowledge in private conversations. And when developing their skills, they focus on meaningful projects that solve real problems rather than isolated exercises disconnected from reality.