Why a Senior Dev?

Old developers can bring a lot of under-appreciated value to firms.

I just turned 37, which makes me somewhat old compared to most devs in the Bay Area. The only thing I have going for me is that I’m self-motivated and have a lot of experience, which can often be overlooked by young San Francisco firms, which will hire 20 year old devs with a few weeks of bootcamp training under their belt for critical roles, simply because the devs are very familiar with latest stack. There’s a lot of risk there though.

Let’s teleport back a few years and imagine a 6-week bootcamp which covered the following tech:

• Backbone.js
• Underscore.js
• SVN
• Dojo
• YUI
• Mootools
• Dart
• Require.js
• jQuery

At one point all that tech was bleeding edge and very popular. I vividly remember the Mootools/Dojo/jQuery war, and I feel bad both for the people who invested in Mootools, and worse for the people who picked YUI. I also wish Dojo had won, but they made one small mistake and lost everybody in a matter of weeks. I vividly remember “DHTML” — yes that was also cutting edge and everybody was doing it (hint, it’s just JavaScript).

I think we can agree that all the above were simply fads and were replaced by other libraries that made a few small improvements over existing tech and labeled themselves “the answer”. So if someone graduated that bootcamp as an expert at any or all of those libraries, how long would he/she remain useful? At the current pace of rotating technologies, probably 3–6 months. Other skills would have to come into play: how quickly the dev can learn new tech, abandon old tech, collaborate, and retain/apply common concepts and patterns which are tech agnostic for starters.

That’s quite a lot to ask of someone with a month and a half of experience. In my personal opinion, the best developers have learned through struggle and failure over time. Lot’s of struggle, and lots of failure. We’ve been burned by bad decisions, swiss-cheese docs, flaky dependencies, environment variances, and varying, poorly-communicated expectations from non-tech-savvy key stakeholders to whom we report.

So what comes from all that struggle and failure that can bring value to a firm which can’t be matched by a bootcamp grad?

Planning

I believe in TDD and iterative development. I understand the need for “demo code” before “production code”. If we can understand and agree that no code is ever permanent, and that any code could and should be able to be refactored at any given moment, it drastically changes our approach to how the code gets in the system in the first place.

All devs have coded in haste at some point(s) and have gotten too deep in the weeds before realizing that a particular logic branch is doing the wrong thing. Something needs to be changed to make the system more efficient, or it handles X and Y, but not Z. Well, does changing that one thing break other things? Will several other unrelated files need to be updated to reflect new paths or parameters? Does a dependency neglect Z completely?

That sucks.

The senior value? A senior dev went through this phase years ago, probably a few times, and has eventually learned from it — we just don’t do it anymore because it’s painful and unproductive. Drawing things out on a white board or in a notebook can save hours and hours of “undoing” code that was written before planning. Yes, coding is more fun, and yes white board sessions are really boring, but I can personally vouch that they work. I have a family and enjoy my evenings away from the computer, so getting it right the first time (while at work) is important to me. Coincidentally, it’s important to the firm too; both for costs and delivery expediency.

Hesitance

Senior devs are like that one friend we all have who has the worst luck with romance. That friend who has put his/her heart and soul into every new relationship only to be cheated on, lied to, and worse. That friend becomes untrusting of your match-making abilities and keeps new prospects at arms length until hearing the full story. “Doesn’t like dogs? Not wasting my time!” It’s good to learn those pitfalls early on, amirite?

When starting a new greenfield project, I see time and time again the young devs pick their stack off NPM like they’re window shopping for the hottest holiday toys.

Senior devs were young once and blindly trusted new libraries too; and then those libraries betrayed us. They weren’t ready for production. They made breaking changes in every update and left pull requests neglected for weeks at a time because the libraries were written by one person and not actually “maintained” by anybody.

We experienced the struggle of trying to replace broken libraries with new libraries, but the new libraries were the same old story, and it seemed like we just couldn’t win, until we realized that the older, more stable libraries which didn’t necessarily offer all the bells and whistles allowed us to polyfill our own bells and whistles (which could be swapped out if/when they became available in the core).

Those libraries didn’t make breaking changes often (hence stable), and provided deprecation warnings for several releases to give us time to prepare. Stable libraries will almost always deliver an MVP to a 1.0 audience with the least dev headache for the best ROI to the client.

Senior devs aren’t afraid to learn new things — we simply have some insight as to what libraries and tech appear eerily untrustworthy and have learned to trust our gut instead when it comes to deciding what new tech is worth incorporating.

Adherence

All devs have coding preferences. Everything from tabs/spaces, 2/4/* character indentation, casing of variables and file names.. the list goes on.

Senior devs are able to let go of personal preferences when working on a collaborative project. They will vote for them if applicable, but if there’s an established codebase, they typically adhere to the existing standards.

For example, I prefer camelCase, but if the file I’m working on uses underscores, so do I. In JavaScript I prefer assigning anonymous functions to variables or constants instead of using the function keyword. If the file uses it though, you better believe I do to. I also prefer to align stacked property assignments on the colon — I think it reads more clearly; but if I’m adding to a file that doesn’t do that, neither do I.

This might sound silly and obvious, but believe me it’s not. It actually takes a lot to win the inner conflict of wanting to take ownership of your code, while at the same time not being upset that it’s “not the way you’d do it on your own project.”

All bad code was recommended code at some point. Why else would it be supported in the language? We learn and improve at different paces, and some clients aren’t ready to skip ahead to the latest patterns. And that’s perfectly ok.

Senior devs have learned over the years that there is no correct way to code. There are trade-offs in every area: performance vs readability vs intuitiveness. In my personal opinion, the best code is that which is most easily understood by the dev team. Period. If something needs to be perf-tuned or do something unintuitive to accommodate some edge-case, it’s abstracted out into its own named function so the story still flows as intended and the weird stuff isn’t mixed in with the expected stuff.

Since each dev is used to coding a certain way, each project will have different “most easily understood” syntax. And that’s also ok.

Adherence doesn’t just apply to the code itself. It carries over to all steps in the workflow of a team. I do a lot of consulting and team-augmentation roles, and every single team is different. Some use Jira, some use Pivotal, some use sticky notes. Some use Git, some use Perforce. Some have daily scrums, some pair, some stick you in the corner in a cubicle and expect you to learn everything on your own.

A senior dev understands and accepts these unique workflows. The trick is to simply comply — be a part of that team. We won’t be the “this is how we did it at my last job” dev. If there are meetings where we bring up workflow improvements, we might bring up some alternatives that have worked out well in the past, but we always keep in mind that “what worked well” at a previous team is not guaranteed to work well for the new team. Keep in mind, we’re still human, and we still get frustrated; we’ll just keep our venting out of earshot from the client and the supporting dev team, and maybe do a little meditating to let go of that which we cannot control.

I typically have OCD with unit test coverage and aim for 100% with my Jasmine specs. I recently worked on a project where the team had <10% coverage and some even failed so they just skipped the tests when deploying. It wasn’t my job to overhaul the workflow, and since the client made it clear to me they didn’t want to pay me to write tests, I didn’t write tests. It killed me inside writing untested code, but the client is paying for a service so it doesn’t matter what I want. I simply made sure to avoid mutability and kept my functions ridiculously concise.

Balance

All high-performance devs burn out. We work so hard on code because it’s like art to us. Solving problems in the most elegant way possible doesn’t always come to us in an 8-hour shift. However, most senior devs I know have a healthy work-life balance. We’ve figured it out. It took trial and error and lots of years, but we’ve learned how to deliver top notch code in a promised work day.

Unplugging after a shift means we’re charged and motivated the next morning. We’re not Facebooking throughout the day and reading hacker news because we’re working on exactly what the client wants us to work on.

Iterative development philosophies allow us to write “working code” which isn’t “finished code”. Since end-users shouldn’t experience any differences between the two types of code, it allows us to deliver quickly and comfortably manage our technical debt behind the scenes. Ironically, countless times I’ve had specs change on me based on customer feedback and A/B testing, and the “finished code” became irrelevant and was removed from the back log.

Remember, all code is throw-away code. Some just might last a little longer in the repo.

While part of being able to maintain balance as a senior dev certainly comes from being able to deliver at a high velocity, part of it also comes from being able to set realistic expectations with clients. We’ve learned which types of tasks appear “quick and easy” in a Jira ticket but actually require a lot of boilerplate behind the scenes that goes unmentioned.

We don’t typically agree to tasks which would require us to put in 70 hours a week because we’ve learned that end-users usually don’t care about every roadmap feature being available in a 1.0 release. Sometimes we have to, but it rarely comes to that. Many of us have also learned that a broken 1.0 with hastily-written or untested features is disastrous. We’ve also learned that delaying features yields better profits and retention for most sites anyway, as it gives a reason for the sites to repeatedly reach out to existing customers with announcements of “new features.”

Agnosticism

Many senior devs have worked on so many projects over the years that we’ve had to learn completely unique languages unrelated to our daily skill set and apply them with a sense of comprehension. What we’ve learned is that most languages do most of the same stuff, just with a slightly different syntax and a slightly different rule set.

Iteration is iteration, lists are lists, variables are variables functions are functions. The first couple “new languages” are scary. Most new devs in the Bay Area are neck deep in JavaScript because of Node so they can be full stack, which is very limiting in my opinion. There are also frameworks like Titanium and React Native that allow JS devs to build mobile apps, and even Unity has a crappy JS API. So much focus on JS is ok but we need to remember that JS can’t do everything, nor should it be expected to.

There comes a time when Titanium or Cordova or React Native just can’t deliver; the UI is choppy or the available hardware API is limited to one device. Maybe Titanium offers microphone monitoring for Apple devices but not for Android. Titanium in particular offers modules to be built in Objective C or Java for the respective build, but with enough modules being built to comply with the feature set, it might make more sense just to build it natively instead of using a hybrid framework. Having a senior dev who can understand how to quickly read docs and apply core programming concepts without much struggle is extremely valuable to tech firms.

This value can also be applied to version updates of core technologies. Keeping JavaScript as an example, ES6 is gaining a lot of traction but it really does the same thing as it did before. We still have functions but they treat scope slightly differently. They now behave more like other languages. JS now has constants, but that’s nothing new in programming. ES6 also has a lot of classical support, which after coding functional JS for years seems completely backwards and silly, so I won’t be adopting it voluntarily.

A senior dev can apply a relaxed transition from ES5 to ES6, or from Swift 2 to Swift 3, etc. I remember when PHP 5 came out and offered a full-blown object model. It was drastically different from PHP4 but since I had coded Java a lot of the new features immediately made sense. I think had I started with PHP4 and never expanded, that shift to PHP5 would have really set me back. It’s like Angular 1 vs 2.

The real takeaway here is that a senior dev understands that languages are just tools on a belt. Some are better at some things than other things. We will recommend the best language for the task. It might not be our favorite to code but it’s the one that will be the most appropriate for its intention.

Final Thoughts

If you’re building a new team or filling a role, consider the value that experience brings, because today’s “everybody is moving to this” technology is tomorrow’s “why are we still using this?” technology. Having someone on the team who has gone through those phases and can calm all the kids down and make sure the tech decisions are in the best interest of the company is a really, really good idea.

If you liked this, please click the 💚 below so others can enjoy!