Being a Better Developer Is Not About the Framework

Illustration of collaboration among a team

Sometimes developers get stuck in a rut. And sometimes we are seen by those in the creative world as dream killers. There’s a way out of both problems: You have to stretch yourself and look for a solution.

The rut comes with always doing the same thing the same way, and sometimes it comes from fear of the unknown. This can kill collaboration with others by causing you to stay with the safe solution and say it can’t be done. If you do that, you’re also not expanding your skills as a developer. Language-wise, trying to learn something new to use later also can be wasted time; it’s hard to predict the future. And when not driven by a deadline, we might not push ourselves to comprehend new things as well. Below are some tips that really have nothing to do with the technology, but more about your approach to growing yourself as a developer and collaborator. Though this is written from the view of a developer, it is applicable for all disciplines that work in collaborative teams.

The Silo Simplex

Though developers are not supposed to be siloed, they are. As experts in their field, they become so “heads down” that, by nature, they end up siloed. An art director may not have all the technology chops, and a developer likely will not have all the aesthetic chops. Doesn’t matter, though. They typically look at the same problem from different perspectives. So we have to become both great teachers and great learners. To be truly collaborative, we must have a universal starting point and then grow from there. We have to educate every time and learn every time. By doing this, we become not just part of the solution, but truly a go-to person for that particular project. In turn, future projects could mean more time in the “Dreamer” role vs. the “Doer” role.

The “No, But” Solution

Another collaboration-building trick is the “No, but” solution. Instead of being the person who says “yes” and “no” to a creative idea, you actually politely reframe it into a solution within the limitations of what you can achieve within a given technology. Saying “no” enough to someone can damage trust or rapport, so you have to learn to craft a compromise that makes others get some of what they want, while also getting you some of what can be done given the constraints. It becomes “our” solution, and that is the point.

Get Uncomfortable

This is probably the fastest way to becoming a more solution-minded person. As developers, we are sometimes asked for something that either we have never done or we don’t know if it is even possible. You have to have faith in your skills and your ability to improvise. Say “yes,” and then discover a way to do it. You will learn new tricks, languages and workflows along the way. By putting yourself on the hook, you will certainly have more commitment than if someone had tasked you with it. You will also learn new languages pertinent to the project and be able to react to the changing technology/frameworks without straying too far beyond. You won’t become an expert in one thing, but more of a jack-of-all-trades. If you can take that to the bigger group, you will make the team and the product better.

Final Product

These are some suggestions to get you going down the path, but one of the main components should be your drive to constantly get better. If you have been in the development game for a while, then you know that you have to keep learning or risk becoming irrelevant. So keep learning. The result is a more confident you. And, in the end, the collaborative process is stronger and likely will lead to awesome ideas that then become actionable ideas.

Less Is More: Anticipatory Design to Simplify User Choice