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
Our company spends a lot of time researching, testing, and reviewing best practices user experience to inform our design decisions. Our clients expect us to make good on a user-first approach to projects we build.
The implementation must follow this same user-first directive, both in terms of how a website functions on the front end, and what the experience of content managers is like.
If a technical challenge is preventing us from delivering the level of user experience or design elegance that our clients expect, our job as developers is to solve the problem, and never justify a poor UX decision because of implementation difficulties.
2. Don't blame the platform
We use tools like Drupal and WordPress 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 the CMS and its respective modules should be a starting point, not an end point. If we need the CMS to do something it doesn't already do, then we customize the CMS.
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 chunks to begin to make sense of what you're looking at.
4. No shrugging
Our clients trust us to solve problems; it’s why they hire us. 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, there's no shrugging at Eastern Standard. Giving up is not an option. If you need to escalate the problem, that's perfectly acceptable, but escalation should always come with ideas: "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. The answers are in front of you as long as you know where to look. Break the problem down into manageable chunks and attack them individually. Eliminate variables. Tear through your local copy until you've excised the problem. Take a break. Ask a colleague for input. But never operate as if the solution is unknowable. The answer is there. Refer to #4 above.
6. Design is critical
Our designers spend a lot of time working through the details: padding, line height, font size, font family, etc. When all of these things come together in conjunction with the back-end implementation, it makes the site feel solid and reliable.
At no point is any one of these things trivial or secondary to the outcome of the project. The integrity of the design has to be upheld or we haven't lived up to our own standards.
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 the norm, then deviate from the norm. But know what you're doing and what the risks are; be able to defend your choice 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. Contribute to an existing project before starting a new one.
9. Deadlines are real
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 the delivery date should only be pursued if we've exhausted every other option and are admitting defeat.
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 everyone in here can run circles around you in some aspect of programming. 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.