Comment by austin-cheney

I was a full time JavaScript developer for 15 years. I still write personal software, but the corporate world killed my spirit for doing this for employment. I blame the exceptionally high insecurity of my prior developer peers, the extraordinary lengths businesses will go to in order to avoid correcting for that, and the diminishing expectations that follow. I will not go back to that. My own bias though is irrelevant to my comments here though as the identified trends and business terms apply the same irrespective of any such bias. Its all about the numbers.

As for advertising that is what's considered transactional revenue, or revenue generated upon the traffic from some other unrelated engagement. Nobody goes looking for advertisements intentionally. They just happen to appear on a site a user visits and eyeballs on that site thus generate revenue in consideration of some contracted term.

Transactional revenue is interesting because it generally has very low associated expenses which all associated revenue is far more closer aligned to profit. It is also insidious in that it tends to get in the way of what users actually want and will over time tank an associated product/brand unless the product/brand is so compelling that it drives substantial repeat traffic. That is the fundamental distinction between media and e-commerce. In media they can throw as many advertisements at you as they want because repeat traffic is deterministic and you are the product. With e-commerce, on the other hand, there exists actual products users must purchase. That purchase process is called conversion and over time advertisements erode the frequency of conversion. As conversion tanks over time users have less reason to access the associated website and so then advertising revenue also tanks.

With regards to sales and revenue developers still have no role in that relationship even in respective to advertisements and transactional revenue. Sales are literally money paid by an outside party directly to your business. Transactional revenue is indirect so it does not qualify as a sale. Even if it did quality the sales people are the ones negotiating the corresponding contracts and revenue terms, which is still not the developer.

I once wrote an advertising pop under for Travelocity from the homepage. The change in presence increased ad click-through impressions upon that placement from 0.3% to approx 14% at approximately 1.1 million page impressions per day. That is a massive revenue boost, but the customers hated it. Part of the massive traffic increase was change of visibility and part of it was content intentionally shifting low quality traffic off site. Stuff like that really killed the business.

In my 15 years of doing that work most of the time employers couldn't tell if a solution were original or not unless it was something they specifically requested. Even then most of the original work was in context of original content messaging, user interaction, and the measurements there of.

Where employers in the past really cared is in the speed of delivery. Typically speed of delivery was faster using a framework solution only if the exact solution were already written and available as an extension. In absolutely every other case software originally written in house was always faster to deliver back to the business. This is because with original software the developers are not limited by prior existing conventions. It always comes down to the prior experience and confidence of a given set of developers.

The business knows this before assigning the tasks to the development team, and that awareness (more than anything else) determines the opportunities for developers to identify their own speed of delivery. Most development teams are entirely unaware of just how thoroughly their performance is measured from a business perspective. That should be painfully obvious, because developers only cost money, and those costs go straight to the bottom line.

Have you even written an original essay, article, or research thesis? Those thoughts are entirely of your creation or finding from evidence as well as the organization thereof. Original software is no different in that you are writing both the solutions and the architecture.

It sounds like this originality should be slow and of great challenge. It isn’t. With practice the words just appear in the correct order as fast as they are typed.

In the overwhelming majority of full stack jobs that level of originality does not exist. Most of these jobs, and the developers filling them, are utterly reliant upon large tool sets of prior formulated architectures. These large frameworks rob the developers of the practice necessary to become faster in their solution delivery and cripple their ability to consider answers of their own design.

As an example consider state management. That is an astonishingly simple problem to solve, essentially saving a result of modification for later artifact generation. With these large frameworks, however, the solution becomes a complex science to compensate for modularity considerations introduced by the frameworks that do not otherwise exist. For developers that have never written an original application without one of these large frameworks the simplicity of the solution is almost impossible to fathom, thus resulting in solutions of complexity outside their control and no ability for consideration of alternatives.