Ideological Differences

Software development on the surface can sometimes appear to be a cold and methodical discipline. The scientific and engineering aspects it employs can make it appear that there are universal truths and problems with only one solution.

The number of times these things do exist are actually rare, problems generally have many solutions and most perceived truths have caveats.

What enables those of us that work in the industry to make sense of this and find a way forward is having an ideology, this helps us form opinions on what is right and wrong and provide our guidance on how to approach solving problems.

But sometimes ideologies can clash, its therefore important to understand why they exist and how they influence ours and others view of the working world.

Born From Available Skill Sets

The development of most pieces of software can be achieved using different technologies. Mobile has Native, Xamarin or Hybrid web technologies as an example and there are a plethora of technologies available for developing web based software.

With many of these approaches disciples will preach the benefits of one over the other, but its important to realise that its unusual to find people that have equal ability and experience in all available technologies.

This isn't to say that this discounts their opinions, there are advantages and disadvantages to all technologies but it is likely that people are seduced by a technology that means they can apply their existing skillset in new ways.

There is nothing wrong with this, being productive is obviously important for any developer. Instead embrace this in built bias and choose the technology that is right for you not that is right for other people.

Born From Metrics

Many different forms of tooling exists for measuring and analysing source, these tools can produce metrics to cover all sorts of aspects of the code we write.

Sometimes these metrics can be in conflict such that it isn't possible to optimise every measure, placing an emphasis on one will lead to degradation in another. The metrics we decide to measure ourselves by and use to define if our code is healthy is therefore driven by the qualities of code we feel are important.

This will lead to us developing an ideology that promotes the improvement of these metrics at the expense of others, if these are the metrics that you value then this maybe perceived to be producing bad code.

With a discipline as complicated as software development these conflicting views on good and bad are inevitable.

When analysing code its important to understand where the people who wrote it were coming from, armed with this knowledge you can properly asses if you have something to learn from their efforts to improve your own outlook.

To do this you must have an appreciation for all metrics and associated ideologies even if you may choose not to emphasise them. This will enable you to extract the core intent of code and give you the ability to continue to learn from others code whilst still potentially adapting it to match your chosen ideology.

Born Outside of Technology

Software development doesn't exist in a vacuum and neither do the people that create it. Many influences outside of purely technological concerns can shape peoples view on the world and therefore how they choose to write software.

This isn't a place for me to be judgmental about what these influences and views might be but realising that engineers are humans as complicated as the software they produce enables you to apply a filter to the ideology thats presented.

If you don't understand or agree with the arguments being made on technical grounds then maybe its because they are born from other influences.

This will be a common occurrence when operating in the world of open source software where the individuals involved may well feel strongly about the use of the software they are producing and the ideology it represents. 

As with the other sources of ideology that have been presented here the importance is in recognising they exist and using this knowledge to navigate through the potentially overwhelming volume of opinion and views they you will encounter.

Make sure that you don't dismiss potentially valuable insight and learning because you don't agree with the arguments or views in there entirety.

Also recognise that whether you like it or not you are also developing an ideology, this will be shaped by your skillset, experience and views on the world, both technical and non-technical.

Embrace this to ensure that you are able to express it to others and also recognise where it clashes with others to ensure you can get past this and not lose out on potential improvements you can make that you can agree on.

While it would be great to be in a world where all disputes and arguments are won or lost based purely on technical merit engineers are people to and they can't help but have biases and views that will influence their approach.