As I write this article, I am putting the finishing touches on a septendecuple-boot system. Yes, septendecuple - 17 distros of Linux on one box. I swear I have logical motivations, which I'll get to in a minute, but the fact is, I've had about half a dozen people this week ask me the same question in one form or another.
Why aren't you just using virtual machines?
Now, I'm no stranger to virtual machines - I've used them extensively for nearly a decade. When I started on this little project, I considered, and rejected, the idea for my purposes. I knew I was going to get that line a lot, and I tried to prepare myself for it.
That preparation did zip to keep the irritation at bay.
The "Joys" Of Unsolicited Advice
I'm absolutely NOT closed to advice, new information, or technical recommendations from others. I learn a lot of cool things that way. However, more often than not, I find myself getting innundated with the same inane pieces of advice, over and over. For example...
- "Why are you using C++? It's so old fashioned! Language X is the way of the future!"
- "Why write your own data structures? Just use
std::orboost!" - "Why build a site in pure HTML5 and CSS? Javascript Frameworks are the Answer To All Your Problems Ever™!"
- "OMG, you use Vim? Why aren't you using Emacs? It's so superior!"
- "Apache2? Seriously, Nginx is the way to go!"
- "Who even uses Python for app development anymore? C# is so much better!"
...and, of course, the aforementioned advice about virtual machines. On, and on, and on, and on, and....well, you get the idea.
Pardon my primal scream for a moment.
YAAAAAAAAAAAAAAAAAAAAAAARRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRGGGGGGGGGHHH!
Ahem
News flash to everyone who feels the need to say any of the above to me: In the 8+ years I've been coding, I haven't just been sitting around writing "Hello, world" in BASIC. I am an intelligent, capable, reasonable human being. I make careful decisions based on hundreds of factors, not least of all the appropriateness of the potential solution vis-a-vis my goals.
And I am not alone.
What Goes Into a Decision
An early step in any project is to decide on what tools and methods you're going to use. Any reasonable human being is going to evaluate three Fs.
Features
Will the solution meet all the needs of my project, relatively out of the box? This also includes performance, compatibility, documentation, license, and community factors.
It is very important to remember that only the actual project members know all the features they need. Too often, I see well-meaning (or otherwise) people assuming they know more about the project than the person organizing it. In my Field Guide to Common Nerds, I call people who regularly make this assumption "Programmaticus Takeitovericus".
Familiarity
How much time will it take me to learn something New, compared against the time saved or the quality added?
For example, I often use Python over C# because I know the former. That doesn't mean I won't ever learn C#, but it does mean that if I want to produce something with decent quality fairly quickly, I don't want to be messing with a language I do not know.
Now, we will always need to learn new things, but bear in mind that we only have so much mental bandwidth. I may pick up something unfamiliar for a project when its Features (and possibly Fun factor, see below) align with my time and desire to learn it.
Right now, I'm packaging a game using AppImage, which means I need to test it on multiple operating systems. This is what first drove me to install 17 operating systems on one laptop, but I was further spurred onward by the possibility of playing with and learning a bunch of unfamiliar Linux distros! Besides that, the challenge of actually installing 17 OSes on one HDD was kinda thrilling. Will I ever need to do that again? Probably not. Did I enjoy it? You bet!
At the same time, I chose not to include Arch Linux or Gentoo on my list of distros to install. I do not presently have the mental bandwidth to install or learn either. (I'm using Antergos instead, for testing on an Arch-based system.)
Fun
Am I going to be enjoy working with this technology? No, fun is not the first priority, but it is an important factor! If you enjoy the tools, that will help drive you through the rough patches. Conversely, when you despise the tools you're using, you have no incentive to keep going.
This is one reason I use Vim instead of Emacs. I know for a fact that Emacs is a fantastic editor, but I just don't like it. I enjoy Vim's features, its keybindings, and its interface. If I forced myself to use Emacs, the added annoyance could actually prevent me from wanting to work on that project.
Now, YES, there are times we have to use things we hate, but this is all the more reason to keep Fun a factor! If we can cushion the blows of an otherwise unpleasant project by using our favorite OS, editor, language, toolkit, or whatever, or, if we can keep our side-projects fun, it prevents burnout.
Lastly, Fun is a factor because we may intentionally chose the hard path for the challenge, thrill, or enjoyment. We already know there's an easier way! In that situation, unsolicited advise feels like mocking a marathon runner for not using a motorcycle to get to the finish line faster.
Check Your Motives
So, if you're seeing or hearing someone solving a problem in a way you don't think is ideal, how do you approach it? Do you just keep your mouth shut, even if you think you could save them a lot of time?
Not necessarily, but first, you should first ask yourself "Why do I feel compelled to suggest X?" As much as we'd like to believe it, our motives are not always pure or altruistic. Here's a few motives I've caught in myself over the years:
The Primadonna
Are you wanting attention for your alleged brilliance?
Remember, true humility involves recognizing both your strengths and weaknesses; if you are humble, you do not need to announce either (with the possible exceptions of job searching, or using yourself as an example or case study).
I find that pedantic arguments usually fall into this category. I once found myself in a pointless discussion, wherein the other person resorted to meticulously mis-defining certain words with the express purpose of belittling my reasons for using a language, and downplaying my intelligence as a person. In eight years of observing programming communities, I have seldom observed earnest pedantic arguments as being anything but a means of public preening. (Contrast that with pedantic arguments in a deliberately humorous context.)
This does not mean you don't share your knowledge, but if one of your major goals is to appear brilliant, it'll usually be best for you, the other person, and all observers, if you keep that knowledge to yourself.
The Evangelist
Do you just want the satisfaction of "converting" another user to your favorite technology? Sometimes we get so passionate about the technologies we use, we want everyone else to use them, and we find ourselves overselling it to everyone we meet.
It often helps to remember - virtually every technology has its place! Even those technologies we have knee-jerk repulsions towards, be they C, FORTAN, COBOL, Visual BASIC, or PHP, have important and valid use cases. Someone, somewhere, successfully created a viable project in that language.
It is also important not to belittle the use cases of technologies you dislike! I have gotten sick to death of hearing the same stupid line...
C(++) is a painful language only useful for systems programming, and really, who even does that anymore?
I can give you the email addresses of at least a dozen people who do systems programming, and at least two dozen who happily and successfully use C++ in application development, creating solid, stable, and maintainable projects in it! (Not that I would give you those email addresses, for reasons of anonymity, privacy, et cetera, but you get the idea.)
C++ may not be a language you like, or need to use, but that does not devalue or invalidate the wide variety of projects old and new that DO use it, nor the pure enjoyment that programmers like myself derive from using it.
The Consultant
Are you acting out of a feeling that you could run the project better than the other person? We can so easily slip into this, especially when interacting with people who have less experience than us.
The funny thing is, there are many times where you probably could run the project better, but then you'd be depriving the other person of a learning opportunity.
Besides that, I've learned from training interns that it is easier for someone to dig themselves out of their own hole, rather than one I dug for them.
The Mind-Reader
Are you assuming you can predict the other person's preferences and needs, or that they're the same as yours?
No matter how much experience you have, you actually don't know that much about anyone else's projects. Programmers, like people in general, are a vast and varied lot. Everyone is unique! Where one person thrives with Emacs, Java, and Ubuntu, another person is happy writing Go in Atom on macOS. And, where one person may be able to create an interface in Electron in a weekend, it may take someone else a month; the latter person may, in turn, be able to create the same interface in Qt over the weekend!
The Battle-Weary Soldier
Are you being blinded by your own negative experiences with the approach they're currently taking?
Like anyone, I have a long list of things I have used, or seen used, and been stung by, including...
- Java
- Javascript
- Windows
- Visual Studio
- Visual Basic .NET
Does that mean those things have no place in the world? Absolutely not! As I mentioned above (see "The Evangelist"), every technology has its place.
Now, I do have specific, objective technical concerns with most of the things listed above. I may, at times, bring up those concerns if they appear relevant, but I try not to let my personal dislike of a technology blind me to its potential usefulness.
There is one important point of balance here: there are rare occasions where a specific library, program, or framework is so utterly bad, the best thing anyone can do is warn others away from it. Perhaps it contains malware or tracking code, has severe memory leaks in performance-critical code, or is so convoluted in its architecture that one can never hope to accomplish anything decent.
For example, I worked with an ERP system on one job, and discovered that its inheritance structure was so horrendously, unacceptably bad, by EVERY accepted standard of computer programming. I wound up writing a scathing technical review of the system, and that review successfully warned off at least one other corporation from starting down a road with no end.
However, be careful with this caveat! Ultimately, all you can and should do is warn with objective, verifiable technical information. Leave the final decision with the other party, respectfully and humbly, and trust her or him to evaluate their options without further prompting. Again, it is better for them to dig themselves out of a hole they dug, rather than one you dug!
When To Share
Once you've weeded out any corrupt motives, you need to evaluate whether your advice is actually wanted!
The easiest situation is if the person has asked about that specific thing: they are explicitly inviting you to share your advice and knowledge.
However, not every question is an automatic invitation for advice! I see this all the time on StackOverflow - someone asks how to accomplish X in Y, and half a dozen people come out of the woodwork to bash the OP over the head with admonishments not to use Y, but rather to use {insert technology here}!
Even worse, if you're writing a tutorial, StackOverflow answer, blog post, or dev.to article about one way of solving a problem, uninvited criticism can sometimes feel like a punch in the gut.
Worst of all, if someone is describing how they've accomplished something they're proud of, it is indescribably rude to retort "You're Doing It All Wrong"!
Again, this doesn't imply that we should never speak up about alternative, or even seemingly superior, methods of doing things. But we need to be mindful of how we will be perceived if we just start talking.
How To Share
If you do feel you have some information worth sharing, there are four very simple rules you can follow to keep your advice from turning into the rain at a picnic.
1: Get Permission
When in doubt, ask permission. Don't assume you know something the other party doesn't. If you feel you have something to add, ask if you can suggest an alternative. For example...
Can I suggest a GUI toolkit that might make your project easier?
Notice how that is phrased: it is assuming the other person is intelligent, and that your suggestion isn't necessarily the One True Solution.
Sometimes, however, asking is impractical to the medium or conversational flow, in which case, just double down on #2...
2: Ask Questions
Ask questions. I did have one friend ask me about my septendecuple-boot project, in a way that wasn't hurtful at all. He simply said...
Out of curiosity... Why are you septendecuple-booting a system anyway?
Note how he's asking. He's not assuming that I just don't know about virtual machines, nor is he just starting out with his idea. He is asking for the logic behind my present approach, and he's leaving room for him to learn something.
In another instance, I was asking for help making an algorithm more efficient. One of the people helping me started out by getting more information. Among his questions was my personal favorite...
What are you trying to accomplish?
I ask this question often, before I even venture to share advice or opinions. I recognize that I don't have all the details, and I need to know more before I can be of any use.
3: Remain Objective
If you do wind up sharing your advice, be sure you keep your feelings about the person, their project, and the technologies in question out of the mix. Stick with the facts.
In pursuit of this, be careful of weasel words. Phrases like "scripting language," "outdated," "best practice," "industry standard," "hard to maintain," and many similar ones are good indicators that you may be resorting to flimsy, strawman arguments.
For example, I was consulting on a project where Java was one of the languages being considered. I recommended against it, primarily citing performance and licensing concerns, as they applied to this specific project. My opinion of Java did not matter. Ultimately, the project leads selected a different language.
Meanwhile, on the same project, I supported a choice to use tabs over spaces as the standard, even though I invariably prefer spaces. I recognized that my opinion was based in preference, not objective fact; since the overwhelming majority of the core developers preferred tabs, I recommended they standardize what they preferred, despite the fact I'd have to use it too!
4: Respect Boundaries
Give your advice in brief, and then wait for the other person to follow up with questions. Don't push, nag, or pester them to listen to you and your "wisdom". Make yourself available for questions, but let the other person decide if they want to pursue your approach.
Ultimately, the decision is still up them. If they decide not to go with your suggestion, no matter how right you think you are, let it go.
Conclusion
In a world with dozens of operating systems, hundreds of programming languages, and thousands of libraries and frameworks, choosing the right tools for the job can be daunting. Many "holy wars" have been fought over editors, languages, and standards. Tabs v. Space, Vim v. Emacs, Windows v. Linux...these battles rage on, and for what good? We cannot force others to adopt our way of thinking and working, nor should we automatically bend to everyone else's advice.
In the end, every person is responsible only for their own workflow and projects, no one else's. We can learn so much from each other, but we have to learn that our ideas are not the end all. Virtually every technology has its place, whether we like it or not.
And yes, that may mean that ten years from now, someone will still be starting a vibrant new project in PHP for a Windows server...and that fact just made several readers shiver! We are inherently uncomfortable with the idea that people are happily building healthy and vibrant projects in technologies we hate. That fact has a way of gnawing at our gut.
But why should it? Maybe we're just uncomfortable with the idea we could be wrong. If we're brutally honest, we're just hungry for some schadenfreude at the expense of the hapless users of those Inferior Technologies we dump on.
But seriously, what harm would it do me if the next decade brings a revival of Visual Basic .NET? Let them have the language they love.
And I'll still be happily hacking away with Linux and C++.
P.S.
I hear you! You're still shouting "Hey, Jason, what's with the septendecuple-boot system?" Here's a few reasons:
- I need to build and test on a ton of different Linux operating systems, especially for making AppImages.
- I'm running out of room on my main computer hard drive, and I want to pare back on what I'm storing there. VMs take up a lot of room!
- I wanted to play with a bunch of unfamiliar distros.
- Hard-drive Linux installs usually perform better than virtual machine installs on an average computer.
- My computer tends to lag when running VMs, making it hard to multitask.
- Someone gave me a laptop with 3GB RAM, and I wanted to do something cool with it.
- I felt like it. So sue me. ;-)
Top comments (7)
It's helpful to treat people's suggestions as requests for information. If somebody asks, "Why didn't you use X?" or says "I'd use X in such a situation", I interpret that to mean: "Interesting, I'm familiar with X, which appears to solve a similar goal, and am curious as to why you chose Y. It'd help me better understand both X and Y if you could explain a bit"
Give people the benefit of the doubt; some people just don't express there requests well, due to culture, language, typing speed, or whatever. Others may just be scared of new tech, or having outdated knowledge, and thus are automatically defensive of what they do. By ignoring the tone, and assuming a genuine request it let's you respond in a positive manner, share information, and ensures you actually think about the question.
That said, had you just used Gentoo you could have easily installed all 17 VMs from within Emacs! :P
This is exactly what I was thinking while reading this. Communication can be hard, so the responsibility for making it clearer lies on both sides. If you mean to ask a question, ask a question! Don't phrase it as a statement. It can be as easy as adding ", right?" to the end of your sentence. For example:
That word at the end indicates you've considered the possibility that your statement might not be right, and would like to discuss it further.
But as the recipient of such a message, it's indeed a good idea to give people the benefit of the doubt as well.
Good points, both of you! I absolutely agree. In this article, I addressed the suggester's side of the exchange; if I had addressed both sides, this would been too long.
In my talk, A Field Guide to Common Nerds, I cover your points precisely. I'll work those into another article as well.
I've bookmarked the talk, because it looks really interesstin!
I enjoyed the reading, mostly because this happens to anyone in any level, it's relatable and important to try to get this culture. I am a student and I'm still trying to figure out what languages and tools fit with my working style, and people love to be "the evangelist". Thanks for the tips, I hope this come to my mind when I am part of a dev team.
Nice graphics. I wonder if the situation would be improved or worsened by people actually reading those books? 🤔
I really liked the book titles! Of course everything else was all wrong! :P