Live data from Hacker News

An Introduction to Class Warfare for the Software Engineer

medium.com

231–240 of 353 posts

Re: An Introduction to Class Warfare for the Software Engineer

#231

Earlier quoted context omitted.

I truly cannot see the connection between ESR's criticisms in that essay, and the subject matter of the OP article. Can you you please add some clarifying context?

Let me just quote it for you: " If we fall away from meritocracy – if we allow the SJWs to remake us as they wish, into a hell-pit of competitive grievance-mongering and political favoritism for the designated victim group of the week – we will betray not only what is best in our own traditions but the entire civilization that we serve". s/SJWs/Marxists/

I'm not seeing the connection between the specific ideological groups Raymond is criticizing, and anyone in the OP submission. Are you bucketing the author of this article with the people Raymond is criticizing? That connection seems so broad that anyone calling for any systemic change of any kind in the tech space could be likewise bucketed, which seems unreasonable. Aside, I don't think that was Raymond's intent with the essay, where he employs some very specific examples of what groups/ideologies he is criticizing.

I'm asking for context, one quote from the article I already read is not providing it. It's only confusing me further. I did not understand your perspective after reading that article, so you quoting one line of it that seems especially salient to you from your perspective is not helping me understand you.

Breaking down the acronym in his essay, I don't really see the connection between the "social justice" advocacy he is specifically criticizing, and the advocacy in the article for worker rights / class equality.

And to be clear, I'm really doing my best not to voice any opinion for/against Raymond's own views in that essay or the author's views in the OP submission - I just truly cannot understand why you are drawing this comparison between the subject matter of each article.

Re: An Introduction to Class Warfare for the Software Engineer

#233
I'm curious how the mass layoffs play out when the large tech outfits find themselves needing to fill difficult positions.

My expectation, unfortunately, is that for the biggest players it won't be much more than "we have to pay more for talent to be willing to work for us."

However, for some it may play out as it did for the survivors of the early-00s dot-com bust. I know of one company, in particular, that narrowly avoided bankruptcy by laying off about half of their staff. They did this in the ugliest way possible (at the time) ... having people sent to rooms to receive either "you're safe/new job" letters or have their badges taken from them and walked -- en mass -- out the door after an apology speech delivered via video.

Unfortunately, this company was located in a market that even in the worst economic times never broke 1% unemployment for devs/engineers. When the need to expand/fix what fell apart came, they found it impossible to hire mid-level and above programming and support positions[0]. After discovering an unusually low number of referrals (despite large bonuses offered) for programmers, they polled staff and found that the issue was the reputation of the company among the staff's professional network... and being a (still) large employer in the area, that represented the overall reputation of job-seekers in the area[1].

The company I worked for (or, at least, the company that we merged with) had a similar problem, though had a much larger pool of engineering talent to pull from (and I'm not sure they ever did "door #1/door #2" style lay-offs). It was a big problem for them for a few years, but was managed by increasing offers and accepting less qualified candidates (which are realities for large businesses with a lot of bureaucracy, anyway).

[0] I know of several cases where they paid employees to move across the country in order to fill needed positions. It was always puzzling to me why they didn't just hire remotely, but they had a reasonably centralized operation.

[1] My buddy continued working there after they laid off most of his coworkers; apparently the environment improved, dramatically, about two years later but the hiring problem persisted until he left a decade later. I suspect it's better by now. I don't even know if the company has the same name.

Re: An Introduction to Class Warfare for the Software Engineer

#234
post #28

Earlier quoted context omitted.

> Do not help those who seek to devalue you Excellent statement. The rest only applies if you can confirm that your company is seeking to devalue you. That is becoming more common but I don’t think it’s universally true.

All companies seek to devalue their workers. It is the nature of the profit motive. The less a company can pay for labor, the more it reaps as profit.

Most for profit companies seek to devalue their workers.

Re: An Introduction to Class Warfare for the Software Engineer

#235
post #39

> Engineering culture encourages workers to collectively improve the company’s effectiveness. It encourages them to share knowledge with one another. To train each other. To build tools for one another. To bring new workers up to speed, and review each other’s work. To speed the company up. To seek out weaknesses in the company and fix them. / Engineers do this while they’re doing their actual job, the one the compan…

Please note the topic is "Class _Warfare_ for the Software Engineer" and NOT "Fulfilling Your Expected Role as a Software Engineer" This is the author's opinion of how Software's Labor can "fight back" If you're not in an adversarial relationship with your employer then this advice will not be particularly useful/advantageous.

Seems these people are in an adversarial relationship with doing actual work. They advocate for doing noting beyond the absolute minimum you are directly instructed to do.

So essentially taking out all independence from work and making it a dull box checking job.

Re: An Introduction to Class Warfare for the Software Engineer

#236

The problem with this article is that one does not need capital to start a tech company. This very website, sneered at in the article, is littered with examples of people who have built something at the side. I'm not sure knowledge workers can make the same complaints about class struggle that mechanical labourers can. We tend to get more valuable with age and experience.

depending on the scale of what you want to do, you might not need to have a lot of capital to get some online service up and running. however, you might find it difficult to have access to the same advertisement resources, you can be cloned right away, you can be blackmail-bought, you may find limitations put in place by hardware makers or by the ecosystem owners and you might have to share your revenues with those g…

Yet you have much better chances and much higher freedom than in any other sector.

Try starting a logging business, when other people have already laid claim to the forests. Try agriculture when other people have laid claim to the land. Try contracting with the government, when the rules say you need to prove previous government contracts to be eligible. That's real world issues.

Cloning and blackmailing of online businesses are not such big threats that they can effectively stop somebody from making a good online business. If you're honest, have a good idea, and put in some hard work you have a fair chance of success. In some other sectors, those factors can amount to nothing - and all the threats you listed apply to offline businesses as well.

Re: An Introduction to Class Warfare for the Software Engineer

#237

Earlier quoted context omitted.

This did not change the inherently adversarial nature. It just obscured it by adding a veneer of "see? our interests are the same as your interests!", despite this being true of just one (small) aspect of the union of all interests.

Well then any kind of trade is adversarial as it's beneficial to defraud your trade partners. Something something prisoner's dilemma Nash equilibrium tit for tat.

No, the dilemma with employers and employees comes from the differing numbers thereof.

The fact that there are (relatively) few employers, and that these employers have already chosen to seek their fortune (or that of their shareholders) by tapping the excess value of their employees, means that it is much easier for their interests to all align, without coordination.

However, the vastly greater numbers that make up the employees have no natural alignment, and tend to be too diverse in their own personal agendas to align even deliberately.

This asymmetry is the principle reason why unions, though imperfect, are a great idea. They attempt to gloss over the vast range in the agendas of individual employees by forcing employers to deal with an aggregate. The alignment of interests among the employees may not be perfect with a union, but it is a lot closer than it would be otherwise, and can offer (sometimes) a real balance to the easily aligned interests of employers.

Re: An Introduction to Class Warfare for the Software Engineer

#238

Earlier quoted context omitted.

Let me just quote it for you: " If we fall away from meritocracy – if we allow the SJWs to remake us as they wish, into a hell-pit of competitive grievance-mongering and political favoritism for the designated victim group of the week – we will betray not only what is best in our own traditions but the entire civilization that we serve". s/SJWs/Marxists/

I'm not seeing the connection between the specific ideological groups Raymond is criticizing, and anyone in the OP submission. Are you bucketing the author of this article with the people Raymond is criticizing? That connection seems so broad that anyone calling for any systemic change of any kind in the tech space could be likewise bucketed, which seems unreasonable. Aside, I don't think that was Raymond's intent wi…

I am not bucketing, but showing analogies, using the most prominent and at the same time controversial idea from OP that engineers should deny teaching their peers and lower-grade engineers, writing documentation and otherwise undermine the whole meritocratic makers culture.

Re: An Introduction to Class Warfare for the Software Engineer

#239

Earlier quoted context omitted.

I'm not seeing the connection between the specific ideological groups Raymond is criticizing, and anyone in the OP submission. Are you bucketing the author of this article with the people Raymond is criticizing? That connection seems so broad that anyone calling for any systemic change of any kind in the tech space could be likewise bucketed, which seems unreasonable. Aside, I don't think that was Raymond's intent wi…

I am not bucketing, but showing analogies, using the most prominent and at the same time controversial idea from OP that engineers should deny teaching their peers and lower-grade engineers, writing documentation and otherwise undermine the whole meritocratic makers culture.

Can you please explain your analogy, then? What do you view as analogous between these two commentaries and why?

Edit: I think you provided half the analogy in this reply, but I can't perceive the connection to Raymond's article or understand why you are drawing that connection. To reuse your quote, what is the connection between engineers refusing to "go the extra mile" as described in the OP, and the creation of "a hell-pit of competitive grievance-mongering and political favoritism for the designated victim group of the week"?

Re: An Introduction to Class Warfare for the Software Engineer

#240

Earlier quoted context omitted.

Please note the topic is "Class _Warfare_ for the Software Engineer" and NOT "Fulfilling Your Expected Role as a Software Engineer" This is the author's opinion of how Software's Labor can "fight back" If you're not in an adversarial relationship with your employer then this advice will not be particularly useful/advantageous.

Seems these people are in an adversarial relationship with doing actual work. They advocate for doing noting beyond the absolute minimum you are directly instructed to do. So essentially taking out all independence from work and making it a dull box checking job.

So kind of like outsource workers but one might argue this has a social guided justification.
Post reply on HN