As a developer, you’ve no doubt been asked “can you do [insert user request here]” more times than you can count. The answer is pretty much always “yes,” contingent, of course, upon availability, time, and budget. The tougher question these days is “how” … should I use React or Vue on the front end? Should I put together multiple NodeJS endpoints or build a single backend in Laravel? Or maybe we could just do a WordPress site… surely there are plugins already that we could leverage!
Thanks mostly to open-source, there are hundreds of ways to get things done these days. As a developer, you may not have participated in a “this-stack/language/framework-is-better-than-that-stack/language/framework” debate recently, but I’m sure you’ve stumbled across a few. “Versus” comparisons are valid when they’re fact-based, but we’re humans too… it’s hard not to think my way is better (if you didn’t think it was better – or at least “as good as” – it probably wouldn’t be your way in the first place!)
In this post, I’d like to share some of the things that shape my decisions about the “how.”
“Reports of my death have been greatly exaggerated”
Go ahead… search on “is PHP dead” and see how many hits you get. Or C#, or Java. Unbelievably, I even got a ton of hits for “is Javascript dead” while writing this.
When I started as a programmer in the late eighties, I mostly used COBOL. Well, guess what? COBOL isn’t dead. I don’t necessarily recommend going out and learning it, but the fact is, very few languages ever die. They might fall out of the top five/ten/whatever but they rarely completely go away. Companies often have a huge code base in a particular language, and justifying spending tens of thousands of hours – and millions of dollars – to rewrite everything in something newer and sexier is rarely justifiable.
Popularity certainly isn’t unimportant, but it’s just one factor. Check out the TIOBE Index; if it’s anywhere on there, it’s probably going to outlive whatever project we’re trying to create this week.
The more things change
Perhaps you’ve heard the old expression, “the more things change, the more they stay the same.” That’s the sort of ambiguous adage that can be made to sound right or wrong in most cases. In any tech field, changes come at us with blinding speed, and there’s a balance we must find between keeping up and going bat-guano crazy.
Your own skill set – or that of your team – is a pretty weighty factor. Yes, you can learn something new – and you should, often – but if you try and chase down too many new frameworks and libraries you’ll lack depth in any of them. In the era of Internet search engines, any coder can churn out a “hello world” in any tool, in minutes, but that doesn’t translate into something that will make you an efficient developer. It’s hard to search for something that you don’t even know exists; the more familiarity you have with a particular toolset, the more likely you are to remember that there’s “something” that does what you need in a given moment… then you can search.
Having depth also, in my experience, gives developers a better chance of creating code that meets best-practice standards. I see this often in WordPress development; for example, any PHP coder knows how to collect and process data from an HTML form, but do they know that WordPress wants all form input to come through a single entry point? Processing URL parameters is another 101-level web developer skill, but did you know that WordPress prefers that they be registered?
Jumping around to the next Javascript framework (just wait, there will probably be a new one in a couple of days!) might make you sound trendy when you’re chatting at your next developer conference, but a reasonable amount of depth matters when it comes to doing things efficiently and correctly. We should change, by all means… just not every other day.
Don’t hate me because I’m beautiful
Here’s where popularity matters most: when a language or framework is popular, there are more developers available and the cost of hiring them is less. If you work for a small company or one with a limited budget, this can be a huge factor. I could create a solution that uses a VueJS frontend that makes API calls via a gateway to my array of Go micro-services and my blog posts will get a lot more interesting! But what happens when my client needs someone else to maintain it at some point down the road? They’d be looking for someone who knows that combination of skills, and finding the right person would be more difficult than if I’d, say, coded a nice stable application in Laravel or stood up a WordPress site and wrote a custom plugin.
This is where “popular” takes a turn of interpretation. Which is more popular, Tesla or Ford? The former is sexy, exciting, and prestigious. But how many do you see on the street? The vast majority of people are looking for reliable, affordable cars. Cars that are practical. Cars that they can keep insured and maintained. They still probably want it to be pretty and have amenities, but those are not the most critical factors.
That’s exactly what your employer and/or team want from your code: something they can manage going forward while still satisfying the business needs at hand.
Bleeding edge
Leadership requires strength and the wisdom of experience and self-awareness. Software products can take on these characteristics by virtue of the people behind them.
Mature open-source projects often have corporate sponsors or foundations that steer them. They have committed developers and a strong review process. They’ve been in use long enough for limitations to be discovered and for more-desirable features to be added. They have clear and well-maintained documentation. That, I believe, is a significant difference between “leading edge” and “bleeding edge”.
When going in a new direction with your tech, look at the official GitHub repositories and see how often the product is being committed. Read through the official documentation and see if it’s robust and up-to-date. As you start learning and get stuck, are you finding answers on Stack Overflow? These are all indications of the strength of the tool you’re considering, and they better the chances that the project you develop will be sustainable.
It probably matters less than we think
I for one have been known to obsess endlessly over the “best” choices for a project. No matter what tools we select, there will be things that work just like the docs said they would and other things that make us question our career choice. On one of the latter days, we’ll happen to read a blog post extolling the virtues of something we didn’t choose and boom: buyer’s remorse. Did I make the wrong choice? Is my project doomed?
Here’s the thing: most of us don’t work on sites that do Amazon.com or Google levels of traffic. (Amazon, on average, entertains more than 6.5 million unique visitors per day; if every site I’ve ever made and every site I’ll yet to make got that many visitors in a year, I’d be amazed.) In terms of performance, it’s probably not going to matter a great deal if we chose to write our backend in, say, PHP7 instead of NodeJS. Or if we decided to stay with Angular rather than switch to React.
What does matter is that we deliver the required functionality with good user experience design, that we do so within time and budgetary constraints, and that we stand up a product that is secure, stable, and maintainable. You’re probably best suited to do that by leveraging the tools with which you and your team are most familiar. And if your choices support that, then you’ll be the type of developer that people want on their team.