Why These Four Developer Debates Are A Waste Of Time
source link: https://hackernoon.com/why-these-four-developer-debates-is-a-waste-of-time-p01033zl
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.
Why These Four Developer Debates Are A Waste Of Time
@zachflowerZachary Flower
Impostor.
I’ve never been a particularly confrontational person. In the workplace, I would much rather maintain good relationships with my coworkers than engage in endless debates over something that doesn’t actually benefit the product or the team.
Unfortunately, software developers love to argue. Whether it is about style, tooling, or entire operating systems, we are stubborn, intelligent creatures with the misfortune of believing our opinions count as facts (spoiler alert: they don’t).
The flame wars don’t matter, and while some debates can be healthy, there are four in particular that I wish would just end already.
1. Indentation Styles
Probably one of the more contentious — yet least valuable — debates on this list, indentation styles are a nightmare to talk about. Tabs. No, spaces. 4 of them. Or maybe 2.
Seriously, kill me now.
Highlighted in an early episode of Silicon Valley, the tabs vs. spaces debate is a self-centered one that completely ignores the realities of language and framework patterns, best practices, and long-term project maintainability. Everybody has a preference — personally, I like spaces (also known as soft-tabs, for those of you that think preferring spaces means I hit the spacebar ten-thousand times a day) — but my personal preference has no place in a team setting.
Code, like writing, should read like it comes from a singular voice. That means regardless of what you prefer, the code that you create should adhere to the standards of the project. What it doesn’t mean is that you have to actually change your coding habits. When it comes to consistency, automated guardrails are your friend. Projects like EditorConfig exist to apply consistency to your project’s formatting. Spaces, tabs, newlines. Whatever you prefer is fine, because in the end the guardrails you implement can take care of the details.
2. Tools
In 2013, I accepted a job at a well-known hosting company after spending the previous two years at a very early stage startup. Excited to learn what I could from a larger, better funded organization, I was instead greeted by a barrage of technological gatekeeping. One of the first “conversations” I had with one of my new coworkers — and onboarding buddy — was a backhanded review of my editor of choice.
“You’ll never be productive with Editor X,” he said, “we only use Editor Y here.”
Three months later, I quit for decidedly greener pastures.
Whether it is Vim vs. Emacs, IDE vs. Text Editor, GUI vs. CLI, or some other arbitrary “this vs. that” debate, the tools we use as developers largely don’t matter. When you claim that you are better at your job than someone else because of the tools that you use, then you are admitting that it’s not you that is doing the job at all. As the saying goes, “a good carpenter doesn’t blame his tools.”
3. Technology Stacks
If I have to hear one more argument over which programming language or database technology is best, I’m going to lose it. Don’t get me wrong, I’m a firm believer in using the right tool for the job, but sometimes we have to accept that we simply don’t know which tool is right for a particular job yet. But we, as developers, often confuse what we understand and are good at with what is “best.”
C++ is no better or worse than Java.
Ruby on Rails and Laravel each have their own strengths and weaknesses.
NoSQL and Relational databases are not one-size-fits-all.
Whether it is due to time or budget crunch, more often than not the choice in technology stack is less important than the outcome. Why let perfect get in the way of good? Pick the right choice for right now, and recognize that technology is always changing. You will be able to evolve your product alongside it, but arguing over which stack is better than the rest will get you nowhere.
4. Operating Systems
Remember the old “I’m a Mac. I’m a PC.” commercials?
I do. And I hate them.
They imply that your operating system of choice makes you an inherently better or more productive person, which simply isn’t the case. Preference is exactly that: preference. It’s what works for you. On any given day, I use all three major operating systems. I’m comfortable jumping from Windows to macOS to Linux and back, because the operating system that I use doesn’t matter nearly as much to me as it used to.
Unfortunately, that doesn’t stop die-hard OS enthusiasts from re-sparking this debate.
But the reality is that we live in a world where cross-platform is now table-stakes. Nearly every development tool that we use works across just about every operating system you can imagine, so no one operating system is any more productive than any other. Hell, thanks to containerization, even development environments are becoming more consistent across operating systems.
The only thing that working in macOS, Linux, or Windows proves is that you have a preference for a certain style. Whether it is DIY, plug-and-play, or some combination of the two, the operating system that you use is no better or worse than what someone else uses; and before you join into the next flame war about it, I can guarantee that as productive as you are in your own environment, your opponent is just as productive in theirs.
Previously published at https://flower.codes/2020/05/04/tired-developer-debates.html
Create your free account to unlock your custom reading experience.
Recommend
About Joyk
Aggregate valuable and interesting links.
Joyk means Joy of geeK