Solving a problem with another one.

What if we are making a great mistake? Finding value where there is some.

2019-04-20

I started writing code (for web development) in 2002; HTML, CSS and JavaScript were still embryos compared to today, Front end development sucked a lot, because every browser had it's own specific API, and they were still lacking of a lot of things that nowaday we love, so it was hard to deliver something beautiful for our customers.

Nowadays we have ES6 and TypeScript for our codebase, webpack for bundling stuff, Angular or React or Vue for web applications and web sites development, Redux and similars (with the whole related ecosystem) for "state" management and we can rely on thousands of libraries for everyday need.

We have a standardized CSS/HTML5 API all across the browsers (and it will be better in 2020/2021 thanks to Microsoft for ditching IE and for using chromium in Edge), we have dozen of services for delivering content, creating our restful APIs and hosting our applications.

It's the golden age of Lego® Software, you just need to collect your bricks, combine them and deliver stuff.

Technically speaking it's all rainbows and unicorns, but for software development it is not.

Lot of developers are missing something, which in my honest opinion should be our mantra: the value in our work is not to be found in solving our technical issues, we are paid to deliver something useful for our customers.

Out clients do not care about technological stuff because they just want a product which cost less than others, adds value to their business and help them to make a profit.

Profit.

Repeat with me: profit.

In IT business, code is a cost. A lot of developers do not often remember this or worst do not think about it.

Over engineering is behind the corner thanks to our technical onanism, we are more often introducing it and it is harder to avoid.

Code value < delivered value

We are taking great care of our code, and this is partly good: good coding leads to lower maintenace costs, better quality and obviously, more stable software. What a lot of developers is not focused on is delivering it. Delivered (and paid) is better than perfect.

A lot of devevelopers, particularly on the front-end side, stop at this point. There is the belief that developer's work should only consist in knowing syntax, frameworks, last coding trends (ugh, this sounds awful, but you know, redux everywhere) and more hopefully data structures (not always, but this is another matter).

This leads to find perfection where perfection is not needed, and leads devs to prove themself with highly complex codebases when there is no need to have complexity. Technical onanism again.

Our work is to build valuable working stuff, and remember, the customer does not care if we use the latest trendy UI library or latest front end framework; the customer want it delivered with any sort of problems.

We are responsible for our front-end aplocalypse.

How to survive this front-end apocalypse

Well, there is no way to survive.

Really.

Until we will have a better support for custom elements, and until lot of developers will know libraries and frameworks better than the native platform, there will be no way to escape the apocalypse.

What I always suggest to younger devs, is to keep is simpler as possible, and to put more effort on data structures and patterns than on coding and adding libraries.

Another suggestion is to remember that until your code works, is clear enough and it does not need more than minutes to refactor, it's great code, who cares if it's written in 2002 javascript or if you use old libraries.

Testing.

Do not test everything. Test only what you really need to test. 100% tests coverage is a unicorn: everybody love unicorns, everybody know how they look like but nobody as seen one before, so stop complicating your life.

Stop using the latest trendy libraries.

This is the hardest part, but if you and your team feel safe using a library, stick to it until it will be really old (angular.js anybody?). Remember that you have to deliver, so keeping the focus only on a small set of libraries will help you, your team and newcomers to write faster and in a better and safer way.

Keep it simple

If you come from java to typescript, stop reasoning like if you are writing java. If css in js does not give you a real advantage, use old plain css. If you have to build a landing page, do not use vue or react, write HTML, CSS and javascript. It will be faster, safer and cheaper. If you struggle finding a good way to organize your code, maybe you are over-engineering.

Do yourself a favor: do not solve a problem introducing another one.