In my time working with and managing teams of developers, I've continually added to a mental list of traits and behaviors that make someone a great teammate. I decided to write them down.
Somewhat surprisingly, it has less to do with coding ability than you might think. Below is a list of 10 tenets that all of our new developers are introduced to on their first day at Eastern Standard.
1. The user comes first
It's easy to lose sight of the needs of the user when you're grappling with deep code issues. Sometimes, finding any solution feels like a win, even if it presents a suboptimal user experience (or accessibility concern).
Our team spends a lot of time researching, testing, and reviewing best practices user experience to inform our design decisions. The implementation must follow this same user-first directive, both in terms of how a website or app functions on the front end, and, for CMS projects, what the experience of content managers is like.
If a technical challenge is preventing us from delivering the level of user experience or design integrity that our clients expect, our job as developers is to step back and truly solve the problem from both sides. We have to avoid the temptation to justify suboptimal UX/UI because of implementation difficulties.
2. Don't blame the platform
We use a variety of tools (whether Drupal, WordPress, Laravel, React, or something else) to prevent us from having to "reinvent the wheel", and to allow us to leverage the efforts of the open source community.
However, the out-of-the-box functionality of those platforms should be a starting point, not an end point. For example, if we need the CMS to do something it doesn't already do, our charge is to extend and enhance the platform; we can't forfeit the requirement because the platform doesn't make it easy on us.
Put simply: we customize these platforms to meet the requirements of our projects; we do not change the requirements to suit the platform.
3. Don't blame the last developer
"The last developer was always an imbecile, even if the last developer was you." —Unknown
We've all inherited projects of varying age and quality. Even inheriting your own project from last year can be a cringe-inducing moment. Never have I seen a developer inherit a project and proclaim "the last person who worked on this sure was a genius!" Part of being a developer is being adaptable, and that means being able to work with code wherever it rests on the continuum between "almost unreadable" and "godlike."
"This needs to be rewritten from scratch" is rarely true. You can almost always refactor and reorganize in sections and begin to make sense of what you're looking at. Breathe, explore the code a piece at a time, and try to build a model of the existing architecture in your head. You can make decisions around what to keep, throw away, or refactor, but try to avoid pointing fingers or conflating "this isn't how I would've done it" with "this is the wrong way to do it".
4. No shrugging
Our clients trust us to flex our problem-solving muscles no matter what comes our way; it’s why they hire us in the first place. When things get deep, difficult, and complicated, that's where we can prove why we're valuable, and why we're better than the last vendor or the vendor they didn't choose for the project.
When it comes to meeting a requirement or diagnosing a problem, simply giving up ("shrugging") isn't an option. Escalate the problem, collaborate with co-workers (even non-developers, trust me), or talk it through with your cat. Even escalation should come with ideas though: "I was thinking the next step would be maybe X or Y, but I don't know enough to know whether that's just a dead end."
5. Be clever in troubleshooting
When it comes to code, nothing is magic. Remember: the answers are in front of you -- it's just a matter of figuring out where to look. Break the problem down into manageable chunks and attack them individually. Eliminate variables. Tear through your local copy until you've isolated the problem. Take a break. Ask a colleague for input. But don't let yourself start believing that the solution is unknowable. The answer is there, waiting for you to discover it.
6. Design is critical
UX and UI designers spend countless hours working through the details: padding, line height, font size, font family, animations, hover states, etc. When all of these things come together in conjunction with the back-end implementation, it makes the site or app feel solid and reliable. It's easy to write off those details as "trivial" but doing so will almost certainly degrade the experience from something that feels polished and professional to something amateurish and brittle.
7. What you're used to may not be what's best
Always challenge yourself to try something new if the requirement dictates it. Don't assume that any methodology, tool, or pattern is set in stone; if the best move is to deviate from what you did last time on a similar requirement, then deviate. But be measured in your architecture/approach decisions: know what the risks are; and make sure you feel comfortable defending your choices in terms that suit the client and the end user.
8. Check for existing solutions before embarking on your own
We never want to suffer from "not invented here" syndrome; it's almost always a dark road of scope creep and missed deadlines. Make sure to use Google and your fellow developers as a resource before embarking on a ground-up feature build that might be retreading old territory. Even if you think you can improve on what's out there, remember that what's out there has likely been tested and vetted thousands of times over; your solution will be full of fresh problems. It's almost always better to contribute to an existing project before starting a new one.
9. Deadlines are important, prioritization is key
Part of being a good developer is understanding how to prioritize your time. If deadlines have been set and are looking like they'll be challenging to meet, part of your challenge as a problem-solver is to know how to work within the timeframe. If things are looking grim, ask for help and support early. Pushing a delivery date should only be pursued if we've exhausted all other practical options. In fact, think of the timeframe as you would any other technical requirement or user story.
10. Leave your ego at the door
Whether you're the most senior or most junior developer in the room, there's never a reason to be arrogant, snide, or aloof when dealing with any other member of the team or with our clients. Almost every developer can run circles around you in some aspect of programming -- maybe they're a frontend wizard but don't have much backend experience, or vice versa. And don't underestimate the client's teach team: they might be completely inexperienced when it comes to web development, but spend their days speaking at national network security conferences. So stay humble.