Why do we hack? (opens in new tab)

But one that cuts to the core of a deep problem in computing and sticks out to me is;

   "customers don't care about X"

Developers have never known what customers want. Customers don't know what customers want. Because software is not a supply-demand business based on reasonable a-priori expressed preferences. It never has been.

For the most-part people accept what they get and define their understanding of technology and its possibilities accordingly. The limits of their horizons are arbitrary, the product of fumbling evolution, fads and fashions, science-fiction and fantasies, endless copying and reconfiguration of features, educational pre-requisites to access and understanding - and all happening within a rapidly changing world of social and hardware change.

The conceit of the programmer as a "master-chef", lovingly creating a dish to the exact delectation of a discerning customer is nonsense, and I have always taken pronouncements about "what customers want" to be naive, grandiose and out of touch.

This reminds me of my first FAANG interview, about 2 decades ago. I was already accomplished, and I assumed it would be a normal software interview, which pretty much always went very well. But once in the interview, they wanted me to write some code on a whiteboard, which I'd only seen once before, and to talk as I'm doing it. OK, I'll try that. (I actually hadn't slept the night before, for unrelated reasons, and I'd unknowingly eaten something that makes me feel queasy, but I knew my way around whiteboard analysis and design, and I guess I could code on one.)

Right before then, I'd been working on an (introvert-powered) meticulous coding style, so I adapt that style to this unfamiliar interview format. I was time-slicing my attention between focusing on the code, and explaining my thinking process for some stranger's mental model (plus the social context awareness overhead).

While I'm coding on the whiteboard, I see that I have a variable that will end up getting set redundantly sometimes in a loop. As I quickly correct that, I verbalize what I'm doing.

And he interrupts me with an order, "Don't prematurely optimize." No clarification -- like that he thinks I'm barking up the wrong tree on algorithm approach (plausible), or that he doesn't know that meticulous coding can be super-effective and not a barrier to also seeing bigger picture, or that he just knows "premature optimization" is a thing. I should've asked, but I was thrown by interruption of my flow, and the tone of voice.

In any case, that set the tone for the interview, and I didn't get an offer, somewhere that otherwise seemed made for me. I ended up going instead to a career path much less lucrative than 2 decades of FAANG, so that might've been an extremely expensive waste of whiteboard marker.

Today, people who use the term premature optimization had better be using it well, or I will secretly think glares at them.

- If you come across something you don't understand, don't just unblock yourself with stack overflow or asking me, try to grok the problem. Take time out to play with the idea.

- Try to understand what you're doing, never cargo cult program. Dig a level deeper than you need to. Foster your curiosity. Understand HTTP now? Great, now look at TLS and TCP.

- Focus on quality of life scripts and tools. Don't ask permission, if a bash script will save us time to do repetitive task X, do it. Resist the constant pressure to deliver the ticket quickly at all costs.

- Do you really need that library? Try as hard as you can to avoid it, even if it adds a bit more work.

- For 10% time, free you mind to work on things and ideas that excite you. Don't let the perceived business objectives pressure you.

Etc...

The truth is, it's a balancing act but I do very much agree with the sentiment of this post. I struggle with the cognitive dissonance of having to think in these two ways at once, and push, as hard as I can justify, away from the 'ruthless pragmatism' route. As ever, it's all difficult trade-offs.

From a business point of view, if you have to sell it, the above produces better engineers and, therefore, the business benefits from higher quality and velocity ultimately. Obviously there is an upfront investment...

However, I have become a bit more defeated and jaded. I have honestly just come to the realization over time that if I want to scratch my hacking itch, then I will just have to do it on my own time with my own projects. My employer and coworkers do not care. Much like others' experiences, my employer actually frowns upon such ventures.

My employer wants things done as fast as possible, with whatever library, with us not reinventing the wheel, etc.. That's what they pay me for, and I suppose that is what I am obligated deliver.

I feel a lot of empathy for artists and musicians and the struggles and compromises they have made in order to "make it." I feel like us hackers must do the same.

The single worst piece of advice that I consistently see repeated.

If you're product is a bunch of APIs, you're a user not a maker.

I don't get it. Even when I'm working on a hobby project of no practical value with no deadlines. Premature Optimization is something I'd still like to avoid. I feel like PO harms code maintainability. It's far easier to optimize bottle necks in well written code than do refactor code complicated by PO in my humble opinion.

Edit: Newline

"Product" is the problem here, right? A product is a

1) Finished complete shrink-wrapped thing

2) that someone else can't have unless they give you money for it.

Both of these characteristics strike me as part of an incredibly bad model for "making good software."

Maybe it's the result of too many years of freelancing.

"we" are not necessarily interested in having a girlfriend. We could be interested in having boyfriends. One or several. Or none at all. Or someone not specifically characterized by a gender. Or by another gender not listed here.