A coworker of mine took a new gig last week. One with increased responsibilities and a job title bump that put them into a more senior position as a company about the size of PMG or smaller.
I gave him three pieces of advice.
1. Do Code Review, Not Style Review
Worrying about coding style guidelines during a code review is a waste of time. Sometimes it can come up to fix some wonkiness, but often it shouldn’t.
Why? Because a computer can do that stuff better than a human. Instead of focusing on style issues in a code review, use tools that can do style fixes and linting automatically as part of a build process. Fail PRs that have style issues and have the submitter fix them.
ESLint can fix a lot of things automatically or error (exit with an error code greater than zero) if it can’t fix things. Same with PHP CS Fixer and other tools.
Making those tools part of the build gives more time to focus on real code design decisions or architecture or user experience — things that matter more in the long run.
2. Read More Code, Not Just Docs
One trend I’ve noticed as a lead and senior developer is that I get very few pieces of real, critical feedback in code reviews. Sometimes that’s because other developers feel unconfortable giving critical feedback — that’s a culture thing we’ve worked really hard on at PMG. It has to be okay for anyone to give honest feedback. Sometimes it’s simply a lack of experience on the reviewers part. Maybe a lack of overall experience or a lack of experience with the specific libraries or techniques under the microscope.
That’s okay, but it means that senior developers have to find that sort of thing — new patterns, new techniques, new ideas — those things have to be found elsewhere.
Reading the code of open source libraries is a nice way to do that. Especially when combined with looking at the git blame and figuring out why things are done the way they are. Does that one line seem weird? Maybe it was to fix an edge case.
Dig deep into the libraries that an application uses. Figure out how they work and steal ideas from them mercilessly.
3. Use New Technologies in Production (Sometimes)
One of the most fun things about being in technical leadership is the ability to make decisions about what sorts of technologies to use.
As any developer knows, it’s important to keep up with new stuff. It’s also important not to go crazy with it. Eventually someone will have to maintain this code, probably the person writing it! So be careful which new things make it in.
That’s not to say that the bleeding edge should be avoided, but rather to make more conservative decisions about what new things to use. Looking to learn a new front end system? Maybe don’t try to fit every single new thing in at once. Instead pick a single new library and see how it goes.
Innovation tokens are a great way to think about this.
Wrapping Up
The overall message here is not new: focus time and energy on things that matter. Things like real code reviews and technology choices that stay out of the way.
Balance that with being wary of stagnation. Without real, critical feedback and someone else making technologies decisions about new things to learn it’s far to easy to fall into a rut. A senior developer can still have mentors (of course!), but it’s important that they push themselves as well.
Christopher Davis 