Dealing with Fanboys [closed]

We’ve all probably met someone like this, that developer who just knows that his language is the one true language and won’t shut up about it. How do you deal like someone like this? I don’t want to offend anyone (especially since the fanboy in my workplace is the senior developer). But I want to be able to use my own choice of scripting language when I have to write a throwaway script that never makes it to the repository and no one else need know existed.

Thoughts that I had to dealing with this:

Laugh it off – “Haha yeah maybe language X is a bit easier, I guess I’m a masochist!”
Go with it – I’d really prefer to avoid this as I can’t afford the drop in productivity associated with picking up a new language.
Hide my language – Become a closet programmer and hide my monitor whenever I’m scripting or automating something.

What would you suggest for this situation?

Few things are jumping out of the question.

Is it really a throwaway script? If it is, it’s strange that it’s
being discussed.
Are you sure throwaway script will stay as is? A lot of production
stuff has been a throwaway script at some time.
Are you going to rewrite the script if it’s promoted and needs
integration in the system?
Is the language choice purely syntactical or is it a language from
another sphere?

I kinda understand the fan-boy part, because from one side, I am behaving kinda like a fan-boy sometimes, while protecting my few languages of choice. And I’ve also dealt with other fan-boys who try to bring new stuff in.

My view on this situation is like this:

If it’s a new language, it belongs in a garbage bin.
If it’s an industry proven language, it can be used if it’s
specialized for the task.
If it’s a very unpopular language, it belongs in a garbage bin, even if
it’s super cool and super fast.

It’s because no one knows how to write safe and fast software in an unknown language, and it has all the gotchas developers have to learn. The stupid script will have to be supported over 20 years or rewritten. Over 20 years, at least 50 developers change in an average shop. If each one writes few fancy scripts in a new language, you need 50 language runtimes, 50 different expertises on the team, and the codebase has buggy code in 50 languages. And some of the languages are no longer supported on Windows or Linux. And needs that unpatched 10 years old custom server, with no spare parts available, 24/7.

Also, no one really wants to support dead languages like VB, Silverlight, D, etc., when the code-base will probably outlive the language itself.

Does he decide what you use based on company policy? Appeal your case to him; if he still decides against it, shut up and do your work with the tools your boss says you should use.

You work there, not play there. Ultimately it’s out of your hands.

Even if he’s not your boss, I would consider all the angles here. Would you like it if he knew Fortran and one day you inherited all his code. You’d have to learn a brand new language from scratch on the fly, that’s terribly stressful. Now picture his side, you might write your scripts using Cobol and he may not know Cobol.

Use something the majority of your team knows.

“2. Go with it”

This is the only reasonable answer. You have a great opportunity here.

Use the senior programmer’s comments to encourage your company to pay for time and/or a course and/or certification to learn the new language. Worst case scenario: the certification and the language will both improve your resume, you may get a good recommendation for being a team player, and you can laugh all the way to a better job somewhere else.
I have gained valuable insights about programming from every language I learned. Even the least practical language (cough XSLT cough) had its sweet spot and was chock full of interesting learning opportunities (and paid my bills for several years). Constant learning is one of the great benefits of being a programmer.
All the cool projects probably use the senior developer’s favorite language. Knowing that language puts you in the pool of talent who can work on those projects.
Someone is presumably paying you to do certain work a certain way. Any other response is probably insubordination and is likely to end badly.

The senior developer/architect normally chooses the primary language used at a shop and ensures that everyone uses that language. This way, a company builds a knowledge base in certain technologies so that one employee (you) can take vacation and someone else can pick up your code and fix it while you’re gone. Also the company can bring in relevant training talent and the HR department will know which buzzwords to look for on resumes.

By learning his language and using it for work, you accumulate the political capital you need to effectively advocate for your favorite language. Many companies have an official infrastructure language and an official scripting language for reports. Prepare a pros and cons list showing where his language excels and where yours does, also where each falls short. You need to keep this list in the context of a specific application, such as the reports you are writing. Plan a time with him to privately and respectfully show him the list and discuss it with him. Write down his objections, research them after the meeting, and if you have good counter-arguments, plan a follow-up meeting.

Good luck!

Show that in a specific context, another language is a more pragmatic choice.

If the person is passionate about C++ and you’re working on a web application project, it wouldn’t be too difficult. In the same way, some contexts are very inclined towards functional programming and using a non-functional language would be not very wise.

Notes:

Avoid situations where both your and his preferred language are very similar.

For example, I would hardly imagine a context where Java would be “better” than C#, or C#, “better” than Java.
Remember that the choice of a language is very often subjective and is explained more by the previous experience of a developer rather than some evidence-based elements.

For example if I’m asked to do an application relative to financial sector, I would still use C# rather than Haskell, even if I find Haskell more appropriate and truly exciting. The reason of this choice is that I have years of experience with C#, but when it comes to Haskell, I’ve only read a few tutorials and never used it professionally.

The answer is 2) Go with it.

The only way to shut the fanboy up is to become fluent (to some degree) in his language of choice.
The loss of productivity is not an issue. You are doing as requested by your senior, so productivity changes must be accommodated by the project.
Learning a new language will make your brain function better.
Learning to be open about learning new languages will do you even more good.

It’s win-win-win-win. Enjoy!

The answer is you do not deal with it. Arguing with them just drags the arguer down to their level (where they beat you with experience) and is ultimately unconstructive because they are close minded.

Ignore any arguments they give for or against their language and make up your own mind. Use the usual techniques like avoid eye contact, answer monosylabically and move onto a new subject when silence ensures. Train them to annoy the person next to you instead.

The challenge here is the fan boy associates the language with his or her identity and any negativity associated with that language is personal. Do not attack or defend. Just ignore.

Very few things at a job are truly throwaway scripts. I wind up putting many such things on the wiki or in the repository anyway in case needed again.

Even things I think are beneath the level of sharing, my teammates often feel differently. For example, I have a rgrep alias in my .profile. It’s just a find statement with a parameter since I don’t have access to real rgrep on that server. A teammate got wind and wanted it on the wiki.. Yes, the one line statement. Obviously we didn’t have a debate about implementation language – it had to be UNIX. But it highlights the need to do things others on the team can understand.

Another spin is that it is possible the senior developer has a reason you don’t know about for using that language. Have you asked?

Maybe try making the same script in both languages once to show why yours is better.

You should try fogging. This means to agree with everything the fanboy says (in part or whole), but do your own thing unless explicitly instructed to do otherwise.

Passive-aggressive options 1,3 lead to more emotional distress, so give me a 2) take it on the chin.

Some general advice for the road: 4) If you don’t get any smarter listening to your senior, do your own study in language/compiler design. Pick a language and learn what thoughts went into it. What the tradeoff is between features, performance, and expressive power. What other options are there. This alone will grant you inhuman programming superpowers. Learn NBL even, it’s going to be huge.

Asserting oneself by pushing opinions on others inhibits productivity and communication. People may think giving up to the emotional urge is helpful, but it’s a mere band-aid on their insecurity.

Being humble and kind with advice, and improving yourself will do wonders to express your gut feelings on a technical level. You’ll feel better and see things for what they are, because you’ll be able to reason. Hard to get mad when you externalize criticism to a technical context.

Filed under: softwareengineering - @ 07:14

Thẻ: language-choice, programming-languages, teamwork

Thiết kế website giá rẻ

Danh mục

Dealing with Fanboys [closed]