Re:Snap is laying off about 100 engineers
by austincheney on Wednesday March 07, 2018 @10:30PM
(#16542079)
My previous employer had way more than 10000 software developers. There was some justification for many engineers given the size of the business in that they did business in many different countries, owned many different brands, and had a major division that was completely divested.
Those qualities are completely valid business justifications for the swell, but the swell was largely unnecessary. If the technology were written well and scaled appropriately they could have easily gotten by with several hundred developers.
The most immediate problem in that industry is legacy technology. The technology is universally Java and it is often poorly written. Java is bloated enough on its own, required boilerplate, but bad software forces a multiplicative effect. Maintenance takes far more effort than originally authoring software in the first place, so a legacy Java application that is still being enhanced with new features can be scary massive.
Worse still is that this was a web-based business and historically very few people have understood web technologies well. If you go back far enough you will find that JavaScript was too slow to do anything and nobody took HTML seriously, so absolutely everything ends up in Java. Java isn't a web technology and would induce rabid insecurity into crappy developers who spent way too much on their education to qualify their insecurities. You quickly end up with really crappy code and needing 5-10x people to maintain it.
Eventually JavaScript got fast, so the business had the bright idea to offload everything in JavaScript. In the past nobody (well very few) wrote JavaScript well, because web technologies were slow and nobody took them seriously. Now there are still very few people who understand web technologies well and everybody else lives behind multiple frameworks and abstraction layers.
The horrid bloat before you had with Java... well now you have that in JavaScript too but you are continuing to develop and maintain on both sides of the fence so you need thousands of engineers just to keep the lights on. Oh, but wait it gets worse.
By now you should be asking yourself how the hell there are so many bad developers in the world and why hasn't the big corporation solved the bad developer problem. It is in their financial interest to solve this problem.... right? No, this is a cultural problem in the corporate world and so long as profit outpaces spend there isn't any financial incentive to fix anything particularly when fixes carry risks.
That cultural problem is that training and mentoring are rare in the corporate world. Furthermore, most developers aren't properly motivated to want to improve substantially enough to solve for valid business concerns. You have to understand that programming is a skill and like any skill the only valid discriminator of competence is deliberate practice (developers with initiative to takes risks to do innovating things). Most developers DO NOT want to take risks. They want to be employed.
Many developers want to go to work to perform only assigned tasks in their comfort zone, like in a factory, and then immediately turn their brains off as they go home according to a set time-frame. Personally, I would rather earn more money and have the freedom to easily move between employers if the need arises, which is only a common reality if you are more competent (more skilled) than other developers.
Ok, so, many developers suck because they aren't motivated to do wonderful things, and therefore you need A LOT of developers to compensate for the bad code (and as they continue to write bad code). The next logical question is why aren't the big corporations doing a better job of motivating their people.
Counter-intuitively, this problem is not solved by increasing compensation. If you increase compensation under the agreement that teams of developers will solve drastically more ambitious problems in more original (innovative) ways you are introducing risk to the developers' career. What happens in the case where a developer accepts higher compensation and yet fails to perform to the higher expectations? Remember that most developers want to keep their jobs. Employment is almost universally preferred to increased compensation others everybody would be entrepreneurs and nobody would be employees.
People capable of appreciating and accepting risks are self-motivated. This means such people tend to identify risks with their own initiative and are self-motivated to solve for the risk without awareness of an immediate reward. This is where increased practice becomes important and the resulting benefits aren't immediately clear, such as increased job security or a future promotion. This is also a behavioral quality much of the corporate world isn't willing to produce, so they leave it to the marketplace. Increased risk acceptance isn't the sort of quality that drives favorable annual reviews in much of the corporate world, as annual reviews reward quantitative performance metrics.
Talented people (people with the proper combination of practice, personality, and accomplishment) are rare and they take time to produce. It is so much cheaper to hire 5 times the crappy developers at 15 times the price than to wait for the golden unicorn to appear when you have work that needs to be performed RIGHT NOW. At least that is the common perception. There is also the common perception that many hands make light work.
I am of the mind that technology failures don't exist. There are only natural disasters and really bad decisions. One person's bad decision is another person's comfort blanket.
Those qualities are completely valid business justifications for the swell, but the swell was largely unnecessary. If the technology were written well and scaled appropriately they could have easily gotten by with several hundred developers.
The most immediate problem in that industry is legacy technology. The technology is universally Java and it is often poorly written. Java is bloated enough on its own, required boilerplate, but bad software forces a multiplicative effect. Maintenance takes far more effort than originally authoring software in the first place, so a legacy Java application that is still being enhanced with new features can be scary massive.
Worse still is that this was a web-based business and historically very few people have understood web technologies well. If you go back far enough you will find that JavaScript was too slow to do anything and nobody took HTML seriously, so absolutely everything ends up in Java. Java isn't a web technology and would induce rabid insecurity into crappy developers who spent way too much on their education to qualify their insecurities. You quickly end up with really crappy code and needing 5-10x people to maintain it.
Eventually JavaScript got fast, so the business had the bright idea to offload everything in JavaScript. In the past nobody (well very few) wrote JavaScript well, because web technologies were slow and nobody took them seriously. Now there are still very few people who understand web technologies well and everybody else lives behind multiple frameworks and abstraction layers.
The horrid bloat before you had with Java... well now you have that in JavaScript too but you are continuing to develop and maintain on both sides of the fence so you need thousands of engineers just to keep the lights on. Oh, but wait it gets worse.
By now you should be asking yourself how the hell there are so many bad developers in the world and why hasn't the big corporation solved the bad developer problem. It is in their financial interest to solve this problem.... right? No, this is a cultural problem in the corporate world and so long as profit outpaces spend there isn't any financial incentive to fix anything particularly when fixes carry risks.
That cultural problem is that training and mentoring are rare in the corporate world. Furthermore, most developers aren't properly motivated to want to improve substantially enough to solve for valid business concerns. You have to understand that programming is a skill and like any skill the only valid discriminator of competence is deliberate practice (developers with initiative to takes risks to do innovating things). Most developers DO NOT want to take risks. They want to be employed.
Many developers want to go to work to perform only assigned tasks in their comfort zone, like in a factory, and then immediately turn their brains off as they go home according to a set time-frame. Personally, I would rather earn more money and have the freedom to easily move between employers if the need arises, which is only a common reality if you are more competent (more skilled) than other developers.
Ok, so, many developers suck because they aren't motivated to do wonderful things, and therefore you need A LOT of developers to compensate for the bad code (and as they continue to write bad code). The next logical question is why aren't the big corporations doing a better job of motivating their people.
Counter-intuitively, this problem is not solved by increasing compensation. If you increase compensation under the agreement that teams of developers will solve drastically more ambitious problems in more original (innovative) ways you are introducing risk to the developers' career. What happens in the case where a developer accepts higher compensation and yet fails to perform to the higher expectations? Remember that most developers want to keep their jobs. Employment is almost universally preferred to increased compensation others everybody would be entrepreneurs and nobody would be employees.
People capable of appreciating and accepting risks are self-motivated. This means such people tend to identify risks with their own initiative and are self-motivated to solve for the risk without awareness of an immediate reward. This is where increased practice becomes important and the resulting benefits aren't immediately clear, such as increased job security or a future promotion. This is also a behavioral quality much of the corporate world isn't willing to produce, so they leave it to the marketplace. Increased risk acceptance isn't the sort of quality that drives favorable annual reviews in much of the corporate world, as annual reviews reward quantitative performance metrics.
Talented people (people with the proper combination of practice, personality, and accomplishment) are rare and they take time to produce. It is so much cheaper to hire 5 times the crappy developers at 15 times the price than to wait for the golden unicorn to appear when you have work that needs to be performed RIGHT NOW. At least that is the common perception. There is also the common perception that many hands make light work.
I am of the mind that technology failures don't exist. There are only natural disasters and really bad decisions. One person's bad decision is another person's comfort blanket.