On Being Indispensable
I write at a fairly &quot;advanced&quot; level. My code is well-structured, incredibly well-documented, and a blue-assed bitch to grok. It&#x27;s not &quot;lowest common denominator&quot; code for junior devs. It&#x27;s usually a hideous bouillabaisse of techniques, ranging from patterns that were around before I started (over 30 years ago), to ones that the language just began supporting, a few months ago.<p>It also works pretty well.<p>I&#x27;m putting the finishing touches on a fairly ambitious app, that has been in the works for eighteen months (frontend native app), and an additional seven months (backend server). It also leverages another server that I wrote, that has matured over a decade (and is now in the hands of a pretty capable team of high-functioning engineers). That server is a worldwide infrastructure that Serves thousands.<p>This means that, if anyone will take over my code, they need to be fairly experienced and capable.<p>You know, expen$ive. Also, they might be ... <i>old</i> ... Gah!<p>It&#x27;s fairly likely that a new dev would toss out the app I&#x27;ve been developing, wholesale, and replace it (and the two backends) with dependency-laden garbage. They would probably do it fairly quickly. It&#x27;s also likely that their code could be maintained by a staff of fairly low-skilled, inexperienced, coders.<p>Which is good, because it would probably need a lot of maintenance.<p>Now, a short-sighted, next-quarter-is-the-end-of-time manager might find the &quot;new way&quot; attractive. &quot;The programmers are cheap, and we can fire them, as soon as they turn thirty!&quot;, they might say. But each of those programmers probably makes a decent chunk of change, and a lot of them, is a lot of change.<p>One cranky old prima donna is quite likely to be a lot cheaper, and you won&#x27;t suffer brand damage, from shipping crap.<p>Brand damage&#x2F;reinforcement is <i>incredibly</i> expensive&#x2F;valuable, and many short-sighted folks don&#x27;t appreciate that. It can make or break your company.<p>Keep your good engineers happy. It&#x27;s OK, if they are indispensable. If they are happy, paid well, and -now, this is important- <i>treated with respect</i>, they can be more valuable to the corporation, than a whole bullpen full of n00bs. I ran a team like that for 25 years.