What is my problem with third party tools and tools suggested by coworkers or friends? [closed]

Question

Closed. This question is opinion-based. It is not currently accepting answers.

---

Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.

Closed 4 years ago.

Improve this question

I am a 4+ years experienced C#, ASP.NET MVC5, Flex, Actionscript, Html, css, jquery, php developer.

I have a passion for developing and I'm not scared about learning new things. In fact I read technical books about what I know to get a deeper knowledge and dive also into new things like learning how to work with a raspberry, electronics, new programming languages (I recently began to read about python and got excited about it).

But I have a visceral hatred for some things.

Just to mention a few: Linux, Apple products, anything *nix based, and frameworks in general.

I often end up in arguings and little fights with co workers or fellow programmers about tools and other things.

Just to say the last two:

There is a fellow who is trying me to convince that I hate linux because I can't use it. I did some assistance in the past and I had to fix various problems on linux computers.

Every time has been a major pain in the ass, and even my co worker, which was much more expert with linux, was still defending it and saying it's me whom can't use it, while loads of errors were just keeping popping up in that bash shell.

Another arguing was about log4net with my current coworker. I prefere in every of my project to use a simple and straightforward library that I wrote (less than 80 lines of code) which pretty much logs everything to a file and does it damn well.

I said him unless it's a requirement or a big project, I don't like at all log4net as it's cumbersome and annoying with all the xml config, all his weird namespaces and so on and that I prefer to use my simple library or write a quick easy logger on the go and that I will never use it. He was defending log4net talking about standards, that's better because everyone use it so you don't have to examine custom logging code (what kind of programmer gets in trouble reading an 80 lines logger who just writes to a file and implements a quick verbosity system?? A freshman maybe...)

Everyone tries to convince me that I should use this or that because it's better and everyone does it and acts like I'm stupid and stubborn and says that I don't like anything so it's useless to show me things because I will never like anything.

I learned a lot of new things, MVC5 by Microsoft was a pleasant surprise though I don't like some things of it (crappy validation system and other things) and i like to try new libraries or other things but, really, what's the problem with me?

I feel myself very selective, I need to test thing deeply and then just weight them on the scale to see if it's worth or not.

If a log system starts to need xml to be configured, calling weird methods in which you have to pass formatting keys or that just to add the date to the file name needs bloated xml configs it's just not for me. I'll rather write 100 lines of code for my custom logger and in 10 minutes and I'm ok for the rest of the project.

I don't put out log4net at all, I understand that all its features are right for a big project, but for the rest it's just an overhead for me.

I TOOK LOG4NET just as an example, there have been various discussions about a lot of frameworks, libraries, OS, design patterns and so on...

What's wrong with me, if there is anything wrong at all? I am lazy? I am not a real programmer because I don't experiment and adhere to the standards? What?

Answer 1

You are definitely a real programmer. I've yet to meet any tech head who doesn't have very strong opinions about some technology or another. I have my own list of rants about technologies I use or shy away from. I wouldn't let yourself get self-conscious cause you don't agree with "Bob in Network Infrastructure".

But there is one big valid issue your teammates are bringing up that you probably need to consider. Standards exist for a reason and their value is often less technology based as much as it is teamwork based. If you have a team of 20 developers working on a project, you really need to get them all on the same page. Otherwise at the end of your project you may have working software but I can guarantee it is going to be a nightmare to maintain. (Trust me on this... I just inherited an SOA application where there was no standardization and now my team of 4 developers has 30+ new proprietary pieces of technology to learn, many of which perform the exact same function. We are spending all of our time refactoring rather than building new functionality).

The team benefit of using an agreed upon logging library (or middleware, ORM, etc..) is that everyone on the team is going to have a relatively consistent approach to a similar problem. This translates to less time required to troubleshoot, less money required to hire resources (now you don't need a Java guy and a PHP guy and a .NET guy), and ensures better team coordination working towards best practices for a central technology.

From a personal development perspective, working from a standard library as opposed to building your own will help you build experience on a piece of tech that can almost be guaranteed to be transferable if you decide to move to another shop. If I own an application and I need to hire a new developer, I'm most certainly inclined to hire the person with experience with the 3rd party dependencies of my app then I am the guy without this experience (because he always used his own non-standard technique). And if you really have a desire to write your own solutions, why not contribute to some of these open-source libraries online and build upon other developers work? If you think you can solve a problem better than the accepted standard... try building on that standard and let the community vet your work (it's another great way to get your name out there).

TLDR - At the end of the day there is nothing wrong with wanting to do things your own way, but remember that most often you are going to be one developer on a larger team. Conforming to the team standard is almost always going to be preferable than "going it alone".