I don’t belong in tech

I understand the author's frustration, and I don't think it's misplaced, but the "world of tech" is wide, and the description, while veridical, is perhaps a little narrow-sighted, or confined to too small a portion of this industry.

There are fields (we all know what those are) where, indeed, "if you aren’t embarrassed by the first version of your product, you shipped too late." Those fields are recognized for anything but quality, and this attitude is precisely why LinkedIn is the profitable (for a handful of people) but despised piece of shit that it is. If your aim is to get as rich as Reid Hoffman, by all means make that a credo. Otherwise, ignore them and the people who think there's any value in that sort of thinking.

In the meantime, there are a lot of other fields in "tech" where if you're embarrassed by the first version of a product, that's usually a sign that it's going to be scrapped because getting it on the market RIGHT NOW is going to get someone killed, literally, and it's in such a bad shape that by the time you patched it up into a state where it doesn't kill people, no one is going to need it anymore.

Not that blunders don't happen (eh, Toyota?), not that this always results in beautiful code that would make Knuth himself weep tears of joy. Like with everything man-made, there's a lot of room for imperfection, but perpetually shipping beta-quality software (oh, sorry, I meant continuously deploying and improving software delivered as a service) is not cultivated.

There's a lot of "ugly code" in these things as well, but for different reasons. "Beautiful code" isn't pursued for its intrinsic aesthetic qualities, it's a result of the pursuit of quality design, of "proper" engineering. It doesn't happen because programmers have a thorough understanding of beauty, it happens because they're encouraged to understand the problems they're solving from many angles, to come up with solid solutions that are going to work two years from now, too (upper management not having selling the company for a decent price within the next 18 months as their main objective helps a lot here) and so on. Certainly, having time to properly implement code helps as well, but most of the super Agile shops I've seen couldn't produce ten lines of good code even if they had an ice age and a half for it. Not because their programmers wouldn't have time, but because they're constantly battered to ship code whose only virtue is that it can be quickly patched up to The Founders' latest whim. Unsurprisingly, when you optimize for things without technical value, you end up with code that's technically crap.

There is a place in tech for people who think that products that sell for their intrinsic quality, not just their smart timing, are both possible and a goal worth pursuing, or for people who want to work on things where quality is a prime concern. There are companies that try to pursue that as well, even though, like everywhere in the Western world, their main objective is to make money. The idea that the two are somehow mutually-exclusive is popular, but not universally revered, and companies that don't adhere to the "move fast and break things" mantra need programmers, too.

Reading this was thinking, this doesnt apply to healthcare tech. Mistakes are not encouraged.

I definitely identify with this post. I love figuring out each and every bit of the product I work on, how it interacts with other code or products or whatever, before inevitably getting frustrated when the focus is on shoving more features into the product haphazardly instead of fixing existing issues or getting a better understanding of the feature and how it best fits in the product.

I think I've begun to figure out how to use that to my advantage though. Ultimately any product is driven by business concerns, and you have to use that same skill of understanding of how code pieces fit together with how business pieces fit together. "If I improve this interface then the code will be more modularized" isn't going to make much waves with a product manager but "If I invest five man-days now, we'll save ten man-days per year and here's why" absolutely will. It's very tough as business and human concerns are much less structured and easy to understand than algorithms, but it is an important step in being an engineer and not a computer scientist.

As a journalist-coder, I sympathize with the author's feelings, but I've come to understand that even as much as truth is ingrained into the work of journalism, that there is a lot a journalist doesn't know and can never know about their story. This feeling is most evident in obituary writing, where you're asked to sum the essence of a life in 500 words of someone who until the day of assignment was a complete stranger to you. Once in awhile I've had readers who were close to the deceased write and thank me for revealing things that they hadn't known about the deceased...which is natural, because even close friends have angles and aspects they don't reveal directly to one another. But then I wonder, what makes me think that I, the outsider, got it right?

It sounds like the author is less disenchanted with tech and coding than she is with product development, because there are many ciders and engineers who care as much about the truth but conflict with CEOs and managers. This is no different in journalism, where the saying goes: an editor's job is to sort through the wheat and the chaff and keep the chaff.

To me, the truth that can be found in code is a refuge from the inherent unknowability of the real world that journalism attempts to describe. I tell journalists who aspire to code that as hard as programming may seem to be at first, it's by far less complex and confusing than the real world.

Every industry requires you to change and grow. Sometimes you find an industry that allows you to grow in the direction you want to grow. Sometimes you don't, but you should. It's up to each individual to find their niche.

People who cannot process their emotions should not try to build a startup.