How to be a Successful Software Engineer

I imagine it will be fun to look back in, idk, 10 years and write the senior's response...

Introduction: Exposition of my Authority

Navigating the complex manifold of interpersonal relationships within the workplace in order to exact your will and achieve prowess within your business is a necessary skill that must be honed and sharpened daily. Your ability to quip, diffuse, disarm, distract, and persuade must be exercised like regular muscles lest they grow stiff under dormancy, and you be compelled actually deliver any value to the stakeholders of your employer.

As an entry level software engineer (a Prince), I have completely comprehended the numerous moving parts at play in the corporate machine and am well-informed and positioned to impart my wisdom and critique of the sage grey beards of functional-programming-land, the arcane viziers of strongly-typed-language-ville, and the ascetic scholars of obscure CLI incantations (that one guy who just knows the sed man page by heart). For all their years of feature implementation, production code deployment, and industry experience - few have anything to show for it, really. In almost all cases, these "superiors" have raised zero venture capital, founded zero companies, and built nothing that exceeds the utility of a [money, messaging, media, spreadsheet] application but evil, actually. Instead, they have cultivated delusional fantasies of a Butlerian jihad scenario in which they elope to the countryside to pursue ornithology as they have grown scared of the cruft and swell brought about under the tenure of their own sorry careers.

Make no mistake, this profession is a travesty; it's considered a good thing to delete tens of thousands lines of codes, and degree of skill is measured by one's ability to minimize the blast radius of jank introduced by such a purge. Each passing year surrounded by artificial problems created by the last generation of engineers, or worse –your past self, from the sprint before last– which demand even more nonsensical solutions. "Phrases dreamt up by the utterly deranged," etc. etc. The senior engineer becomes so removed from reality, protected by an exoskeleton buffer of bullshit ideas, language, "requirements," and academia that she or he is insulated from any threat of being held accountable for harbingering the singularity, building good technology, or touching grass.

Nay, the perceived naiveté of the junior developer uniquely positions him (me) to write confidently about his knowledge of the interworkings of the corporate structure. The jaded "senior" engineer may write this off of as superciliousness, an intentional rhetorical countermeasure which enables me to proffer my insight publicly. It is from this throne of excess (Herman Miller ergonomic pro desk chair), adorned in patagucci, penned from the most obnoxious mechanical keyboard (cherry MX blue because I hate my coworkers and am employing tactics of psychological warfare against them) that I address my brethren, my fellow entry level developers. Fresh out of college, hairless, spineless, and –as the enemy would have you believe– brainless.

Rule 0: Software Engineering vs. Programming

First, an obvious but important distinction must be made. Oftentimes, programming is conflated with software engineering, and this is one of the first mistakes that a new engineer might fall trap to.

Programming is not software engineering. Programming involves problem solving, building useful tools and applications, and using technology to advance the project of human civilization. Software engineering is devoid of any likeness to this admirable goal.

Software engineering is one of the rawest forms of manipulation that man has tasted. And ever since man struck sand with lightning to form the transistor (colloqially referred to as The Great Mistake), and further decided to organize labor around the delusion that this practice is "innovative" or generally worthwhile, junior developers have been honing in their clandestine ability to exist without adding anything of value.

"Never attempt to win by force what can be won by deception"¹

While masquerading as a highbrow occupation in order to filter out those who might be too adept at giving off the impression of productivity without achieving very much, it is important to remember that software engineering is the business of problem creation rather than solution. Many green engineers may still hold onto the idea that what they are doing might be particularly difficult, or unique, or even important. This is simply a means of making themselves feel better about struggling to find romantic partners. It is imperative for the aspiring Prince to cast out this idea, and dedicate his time to mastering the art of Software Engineering.

Rule 1: Never Underestimate the Intelligence of your Foe

The first and only freebie I offer to my foes is that they should not underestimate my intelligence.

"The fundamental cause of the trouble is that in the modern world the stupid are cocksure while the intelligent are full of doubt." ²

The Prince then must confidently disseminate his wisdom, and make manifest his ideas for the observation of other junior engineers. It is only through the evangelism of his success that others might overcome the disease (created by senior engineers) of imposter syndrome and start causing a raucous in their own organization.

All warfare is based on deception. Hence, when able to attack, we must seem unable; when using our forces, we must seem inactive; when we are near, we must make the enemy believe we are far away; when far away, we must make him believe we are near.³

That was from Sun muthafuckin Tzu's The Art of War, and make no mistake - war is precisely what you are engaged in. From the moment you rise at 6:30 in the morning and gulp down a bottle of soylent, to 3:30 AM when the handful of adderall you took for your daily exertions wears off, you are at war.

Do not confuse for malice what can first be attributed to incompetence.

Many confuse Hanlon's Razor to be a warning to temper judgement, but it must be the guiding mantra for the junior developer. As a new hire, your goal should be to act so maliciously incompetent that other engineers avoid you, freeing up your calendar for rabble rousing.

Rule 2: Your Foe is Always Wrong (that is why they are your foe)

The second rule of being a successful software engineer is that Senior Engineers are largely to be ignored. Their visions of abstractions, design patterns, and orchestration layers are indicative of the fact that they have lost and instead must retreat from the foreground of boldly striking down asinine ideas, they must hide behind made up concepts. You may have heard the phrase "A monad is a monoid in the category of endofunctors." The tongue in cheek secret passphrase of their elite club. No, a monad is an artifact of propaganda to distract you from exacting your ends.

Rule 3: Win Every Conversation

Conversations in the workplace are to be won or lost. The notion of a water cooler chat is a fiction, a rare invention of the indolent.

The workplace is a zero-sum game, defined by repeated interactions with other agents. In order to succeed, you must extract points from the other players. Misguided models of the workplace call for a cooperative strategy. These strategies fail when employed against uncooperative agents, like the Prince you are. After just a matter of hours in any workplace, even the least adept junior developer will quickly realize that few of his coworkers have a winning strategy against an opponent that is not cooperative. Don't hate the player; hate the game.

Rule 4: Empathy is the Enemy

Empathy is appropriate only as a means to your ends.

"But, your highness, doesn't this make you a sociopath?" to which the prince cooly responds, "how do you like being poor."

Empathy does not a good software engineer make.

Your goal is to harvest the quiet quitters. They are like expendable units, pawns to be maneuvered against your combatant colleagues. Many engineers have extensive experience with StarCraft, or XCOM, or other RTS games. The workplace is pretty much exactly the same as Simulacrum. While there is no Nexus to be captured in the workplace (if your office has a nexus, please reach out to me directly at once), the office environment follows the structure of a war of attrition. You must simply outlast your opponents. (If you consume enough stimulants, health bars may appear over the heads of senior engineers). You have the advantage because, oftentimes your foes will not even realize that they are at war, and you may be free to whittle away at their resources, sabotaging their efforts, being delinquent, and insubordinate, but polite enough to remain employed.

A huge advantage that the junior dev has over his senior assailants is that the junior dev is nigh invincible. The least competent among our ranks still holds such an advantage over the senior, that the competition between these two warring factions is almost unethical. It is nearly impossible for the junior software engineer get fired.

Rule 5: Deadlines are Not Real

Your greatest assets as a junior developer are the expectations set by your coworkers. Rarely will you have to deliver on any meaningful tasks, or tight deadlines. Collectively, junior and senior engineers have agreed to lie about how difficult their work is to product managers, the common enemy of the software engineer. It is not the place of the junior developer to break this cycle.

The senior engineer's favorite activity is to complain about how their day is filled with meetings impeding their ability to get any work done. This is a joy to the junior engineer. Until they realize that the true battleground is not the Git history, but rather the conference call, you need not be concerned about the senior's efforts. Furthermore, as a junior developer - your calendar is far less busy than the senior fool's - allowing you ample time to complete the tasks allotted you and spend the bulk of your workday introducing seemingly benign lines of code that are liable to detonate when your foe is already crippled by your facade of chipper obliviousness.

Rule 6: You Need to be Taking Stimulants

Most people (conventional psychoactive scientific consensus) believe stimulant substances to act as "amplifiers" on a user's personality. That is, an outgoing and productive person will be even more outgoing and hard working through the abuse of a ritalin prescription. Similarly, the quiet loner will retreat further within his own mind palace, chapping his lips and vibrating in his chair till the cows come home. However, both of these conceptions are mistaken.

The astute junior developer is ever striving to reach the orthogonal state of being I like to refer to as "cocaine brain." In this state, the Prince is able to fully compartmentalize both his own emotions, ambitions, desires, and ideas - but more importantly, the emotions, ambitions, desires, and ideas of his coworkers. This is particularly useful when these ambitions obstruct the junior dev from pursuing his goals. The ability to construct a thorough ad hoc inventory of your coworkers' entire beings at a glance is first necessary to dissect and avoid the tiresome affectations like "what they did this weekend," and "how their kids are doing." Usually, a lot of things other than grinding leetcode and blogging - pathetic. Without a wholly deviated septum and a perpetually upset stomach from the stringent diet of amphetamines, caffeine, and soylent - it is very easy for an aspiring developer to let empathy cloud his judgement. To master his attitude and outlook, the Prince must first master the amphetamine.

I'd rather laugh with the sinners than cry with the saints, the sinners are much more fun.

Billy Joel is one of the most successful Junior Developers of all time. A fool (Senior Engineer) once said "There is no cocaine in heaven." However, the devil seems like a cool dude, and I'd rather hangout with him.

...