
I don’t belong in tech - ingve
https://medium.com/@saronyitbarek/i-dont-belong-in-tech-3d73d8fd6f34
======
wycats
This post is not about perfection, but rather about a deep, legitimate
frustration that the tech community spends so little time really understanding
the problems it sets out to solve.

Here's a key paragraph:

> I am not solution-oriented. I don’t see a problem and get giddy at the idea
> of solving it, patching it up and sending it on its merry way. I want to
> poke it and ask it questions. Where did it come from, what is it doing,
> what’s its story? I want to take it to tea and hear about its life and
> understand it to its core. And if, at that point, I’ve come to a wholistic
> understanding and am able to solve the problem, by all means, let the
> problem-solving commence! But my instinct is never to solve, but to
> understand.

This is not a statement of perfectionism, but rather a deep yearning for like-
minded people who believe in trying to understand the problems they're trying
to solve.

The RFC process, which has gained more prominence through projects like Ember,
Rust, Swift, and Yarn, operate on the same principle: that we should try to
make sure we understand, not just rush in with the first solution that comes
to mind.

Iteration and contact with reality are important. A desire to understand is
not in conflict with a desire to iterate and work with communities. But too
often, the tech community makes a virtue out of moving fast, breaking things,
and never coming to a deep understanding even in many of the most successful
cases.

I think we owe it to ourselves and our community to get past a knee-jerk
reaction to this post.

~~~
etblg
I was just about to say how weird it was that almost all of the projects you
named were worked on by Yehuda Katz and then I noticed who posted it...

------
dunkelheit
Maybe she should quit doing user-facing stuff and try getting into systems
programming for a change. Or some other area where sloppy solutions lead to
tangible reduction of business value and thus are not tolerated. Tech is big,
no need to quit all of it.

~~~
Slartie
Totally seconding this.

Just trying to "quick fix" apparent bugs, without having understood the
complex problem in its entirety beforehand, is a pretty bad approach in quite
some areas of the tech world. This is true for most server-side work, for
example - you just can't put a band-aid type solution on a problem created by
a weird race condition between different requests processed in parallel,
because you most likely either ruin the performance or don't catch all the
cases in which the bug appears, or even worse: create new bugs, deadlock
situations or similar catastrophes as a result.

I personally work on cash register software. In that area, it's basically this
way for the server and client side of the equation, because if this highly
business-critical piece of technology fails, the user really has a problem and
typically can't do any business anymore. And the software release cycles on
those machines also don't allow for continuous-deployment-we'll-just-test-the-
fix-in-production-so-it-doesn't-matter-if-your-first-attempts-fail-miserably-
style of work, so you have to get your bugs fixed thoroughly, which requires
fully understanding the nature of the problem first.

~~~
Illniyar
"You just can't put a band-aid type solution on a problem created by a weird
race condition"

Oh yes you can, and do, often, in payment processing code. I've done it (with
a simple sleep for x seconds I think), and I can assure you the higher ups
couldn't have been happier.

~~~
Slartie
Oh, so maybe THAT is the reason why one of our customers had funny cases of
thousands of his customers being double-billed on card payments by the payment
processing provider!

As a developer (of the cash register software, which wasn't at fault in this
case), I was kinda amused by the whole thing. But I can assure you, the
higher-up business people weren't amused at all.

~~~
Illniyar
If your using Java, there's a popular apache http framework[0] that
automatically retries a failed request unless you specifically instruct it not
to.

That bit us in the A$$ with double payments a few times.

0- [https://hc.apache.org/httpcomponents-client-
ga/httpclient/ap...](https://hc.apache.org/httpcomponents-client-
ga/httpclient/apidocs/org/apache/http/impl/client/DefaultHttpRequestRetryHandler.html)

~~~
magnetic
If you rely on http to ensure the one-and-only-one type of paradigm, I have
bad news for you (because you won't be able to distinguish failure vs success
case when you hit a timeout: did it not receive the request or did I not
receive the ack?).

You should embed a transaction ID to ensure idempotence of your API call. Then
you can make the request 1, 2 or 3 times without any risk. The receiving end
will realize the transaction ID already transitioned state and won't cause
multiple payments to occur.

~~~
Illniyar
Obviously. But youd be surprised, some gateways don't let you send your own
transactionId. Or at least they ignored it for determining duplicate requests.
Though that was several years ago.

------
rm999
The author makes some great points that I initially wanted to dismiss, but I
think are actually really interesting. Unlike many other types of
engineering/craft, most experienced software developers have settled on an
aversion to perfectionism. A good carpenter wants to build a solid house even
if no one will ever see its frame. Ditto to an auto engineer at BMW, or a
hardware engineer at Apple, or a mechanical engineer at Boeing.

Why do software engineers break this mold? I think it's because building
software is inherently cheap, which means it's easy for a large number of
people to build things without an obvious economic incentive, which means
there's often a product misalignment. When someone builds a house or a car,
they are certain their product will get used. Most software, on the other
hand, never sees heavy use. Probably 90% of what I've built over my career has
never been used, and I've had a productive career.

The most rational thing in software is to ship something functional, then
perfect it _after_ it's been proven to be useful and popular. I can see why
someone with a craftsman's mind would hate this. I feel a sort of disgust with
myself when I ship shitty code, but ultimately I know it's what makes me so
productive and valuable to my employers. This disconnect is real, and it's
worth talking about.

~~~
woah
I'll have to disagree. I used to be a carpenter and the objective is
definitely not to be perfect. Building anything, houses or apps, the objective
is to work within tolerances. The modern system of 2x4 framing and drywall
allows those tolerances to be very loose without affecting the end product,
but I digress. Would you prefer a half-finished house with perfectly cut studs
(that you can't see inside the drywall), or a completed house that has looser
tolerances but has passed inspection?

Even in those fields that people imagine involve a lot of perfection, like
watercolors or fine Japanese carpentry, the perfection is not arrived at by
agonizing over details and overworking the piece. The perfection comes from
the muscle memory of someone who has done it many times. App development
should be the same way.

This economy of effort is intrinsic to any craft and is part of being a good
craftsperson. I used to have an attitude similar to the author, a mixture of
derision and envy towards those who were able to ship. She needs to learn that
if she does not abandon this counterproductive mental handicap, she will never
be a good craftsperson, in software or anything else.

~~~
rm999
There's a huge difference in economics. A house _will_ be used, so looser
tolerances in carpentry are not obviously good and are seen by many as a bad
trend. Sure, you may not die from those lower tolerances, but you'll likely
regret it. See for example
[http://www.mcmansionhell.com/post/150597521816/mcmansions-10...](http://www.mcmansionhell.com/post/150597521816/mcmansions-101-revisited-
aesthetics-aside-why)

The median house will be used for decades, the median software is used for
months (maybe days, or even minutes). This is really what my point is.

~~~
barrkel
I don't think the median software is used for months. I don't think that's
true at all. That really needs some evidence behind it.

I reckon in most companies, software is written and maintained until the whole
system it's a part of becomes obsolete. That typically takes years, sometimes
decades if the system is really useful.

It's really risky to rewrite software, so it typically isn't done; it's
similar with deletion of code. Most people shy away from it because they're
making local changes and don't have enough global knowledge to be brave. So
the code lives on.

Personally, in my professional career, nothing I've written has yet been
retired or end of lifed, and I've been doing it for 15 years. Some things were
experimental and never got released; some things were maintenance for a
subsystem that got buried away; but no whole feature nor whole product has
been discarded other than by gradual overwriting through maintenance.

------
shubhamjain
Most people that complain about shipping the imperfect solution are not aware
how inefficient is striving for perfection in the software world. Personally,
I have never seen rumination on every nook-and-corner of the product yielding
something fruitful. In fact, it invariably results in the opposite — solving
the wrong problems and then, solving the _real_ problems that you never
thought would've existed. Rinse. Repeat.

The author equates imperfection to sloppiness but I'd argue that the case is
quite the opposite. I recall a comment made by Paul Buchheit on Hacker News
about FriendFeed —

"Another interesting detail is that this is roughly the 4th iteration on the
FriendFeed backend since we launched 17 months ago. If you look at the the
graphs at the bottom of Bret's post, you can see that our previous system was
about to die -- average pageview latency had increased from about 135ms to
260ms in less than a month! (not a good trend) This new design also
accommodates some important upcoming features that would have been problematic
in the old system.

This experience reinforces my belief that it's better to be quick than
brilliant. If we had wasted a lot of time trying to build some really smart,
super-scalable system right from the start, it would have inevitably been
over-optimized for the wrong things, since the product and requirements have
changed quite a bit since launch."

~~~
bsg75
Perfection is the opposite extreme from minimum viable product.

There could be a "happy medium" where a ship schedule incorporates a
reasonable level of quality in v1. Minimum viable is too often implemented as
ship as fast as possible, and viable gets perverted into first post release
patch.

~~~
user5994461
Objection! Perfection is the ultimate minimum viable product, as mandated by
the condition to achieve it.

    
    
       (12) Perfection has been reached not when there is nothing left 
            to add, but when there is nothing left to take away.
    

[https://tools.ietf.org/html/rfc1925](https://tools.ietf.org/html/rfc1925)

~~~
threatofrain
I don't understand, don't you obviously want both conditions? Isn't that a far
better definition for minimalism?

Given objectives, constraints, and means, the most fit set of solutions are
the "perfect" ones.

------
jesionaj
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.

------
imagist
I think about problem solving and code a lot like the author. But I don't
think that means she and I don't belong in tech. I think that means we don't
belong in the get-rich-quick scheme that is the present tech startup industry.
Or put another way: we belong just fine in tech; we don't belong in
_business_.

It's not tech that says "move fast and break things", it's business. Business
is the reason the Internet of Things is full of insecure products. Business is
the reason for Web pages made unusable by popovers and ads and unnecessarily
paginated articles. Business is the reason for keeping massive databases on
users. Behind every problem in tech is an MBA trying to make a profit.

And that's the irony: tech people suffer for the problems business causes, but
tech people don't profit from those problems. Sure, tech salaries are good,
but those who determine those salaries unsurprisingly pay themselves more. We
don't get the satisfaction from making a solid product and we don't get the
profit from making a shitty product.

I think the key to being happy in tech is to break that cycle. Either builds
things that make you joy (CRUD web apps bring no one joy), or build things
that make you money (not salary money, but owner money). Don't settle for
building someone else's dream and giving them the profits.

~~~
hartator
"CRUD web apps bring no one joy"?

~~~
imagist
If you aren't bored of writing CRUD apps, you haven't worked as a Web
developer very long.

------
hibikir
Not belonging? Not at all. When I read that article, I see a kindred spirit
who belongs doing either systems programming or maintenance programming. In
the right place at the right time, that very mindset is worth a lot of money.
I for one have made a career out of fixing awful code and awful systems.

Publicly, we praise companies and programmers that get a lot done very
quickly. Do what doesn't scale. Move fast and break things. Those are great
ideas for a while. But eventually, following that alone harms a company, and
might even kill it. The quest for speed needs a whole set of people that are
capable of keeping bad systems running and improve their stability and
scalability while they keep going.

For instance, I currently work at Stripe, making a core piece of
infrastructure that doesn't scale anywhere near as well as we need, and has
been plagued with downtime issues. There's been plenty of attempts to rebuild
and replace, which never had any success, but this year, we've had tremendous
improvements, which are seen by our users every day. This improvements aren't
really about someone getting lucky and rebuilding from scratch again. Instead,
we spent time adding observability features, and understanding how the system
works in practice: Pain points, causes for errors and all that. Only after we
had a good understanding of the major problems we started making architectural
changes to improve the system: Build better interfaces across components, then
replacing the components that needed the most help. After enough time,
Theseus's ship might still have the same name, but it is a far better ship
than it ever was. Then other systems will need more help, and I'll move on to
work on another fire.

There are companies out there that don't value this kind of skillset, and
that's fine: They are either too small to need it, or they will be unable to
keep building new things and fail. Instead, look for growing companies that
realize that they can't just hire commandos, and need people to focus on
lowering risks and maintenance costs.

You don't just belong in tech: You are a key part of tech, you just have to
realize what your spot is.

------
bane
This was great, and well written. As the phenomenon of software and technology
expands to encompass all of human activity (and thus all humans), it's also
going to bring in diverse mindsets, experiences and approaches.

This is a good thing.

When I was young, tech really only existed in the hearts and minds of a very
small, self-selected, few. Most of us had similar or common viewpoints and
experiences. It was very easy to go someplace new, find the local group of
nerds, exchange a few Star Trek quotes to prove your bona fides, and you'd be
in.

But we, and the technology that came from us, was limited to what we could
produce given the limited set of experiences and modes of thinking we brought
to the table. But we also couldn't see this limitation, because our work was a
reflection of all that we could think.

What's happened in the intervening decades is that _our_ technology, the kind
that we literally grew up imagineering, while important, has become a minority
of what humanity needs technology to do for it.

Even today, the fact that somebody from a non-tech background can go take
classes to learn to code, and make a successful business, or have a successful
career with that knowledge feels vaguely alien to those of us from the early
years.

I've come to the conclusion that the notions I had as a child about what
technology was and how it was in my blood, were incredibly wrong. The world of
technology is immense - bigger than just software, or hardware. Writing is
technology, cheese is technology, sewing is technology... As this
enlightenment continues to unroll in my mind, I'm not even sure I know how to
latch a definition onto the word that doesn't ring hollow, but it seems
vaguely associated with anything that uses our minds to make the human
condition better.

The author above, she _does_ belong in technology, it's our insistence on
trying to limit the meaning of tech to the kind of tiny world I grew up in,
that has convinced her that she doesn't belong. Yes, she doesn't belong in
that microcosm of early tech. She belongs in the macrocosm of human
betterment.

------
DanFeldman
This level of attention to detail, perfection, and craftsmanship is found
largely at bigger companies with more to lose with their products. Automakers,
manufacturing, aerospace. When I worked at GM, this sort of thinking was
necessary at every step. Perfection and correctness was written into every
process.

Also, about 40% of the engineers in my group were female (active
safety/autonomous vehicles. We solved awesome problems, but moved slowly to do
it right. Maybe the author should look at companies whose markets demand less
iteration and more safety.

"You get there first, making waves while I sit in last place and watch." There
are companies out there that do not subscribe to this thinking!

~~~
thesimpsons1022
>> Perfection and correctness was written into every process.

you say that but the industries you mentioned have some of the worst code
possible.

~~~
DanFeldman
I agree on their code quality/their coding practices are bad, but that doesn't
matter for this context. They (GM) are not software companies, so they don't
set out to write amazing, clean, modular code.

This isn't about writing great code, it's about the culture surrounding
release.

------
gpsx
This might come down to being a goal oriented person versus a process oriented
person.

I got a PhD in theoretical physics. By the end of graduate school I was really
unmotivated. I decided to leave physics and do something else, as yet to be
determined. In order to go through any of the job interviews through the
university you had to first go to a career counsellor. I had absolutely zero
expectations, but I of course did it anyway.

When I walked in, the first thing the career counsellor said to me was "You
don't look like an academic." I looked like a football player in those days.
He continued something to the effect, "Athletes are usually goal oriented
people. They can put themselves through a lot of pain because they are
interest in reaching an end. Academics are usually process oriented people.
They enjoy working a problem and seeing all the angles of it and they are not
driven by finishing it."

Granted, this is a generalization and does not apply to all academics or
athletes. One of my professors Lenny Susskind, a famous physicist, is also an
athletic guy.

I don't think this changed the way I did anything but it was very insightful.
You can find problems with both types of people and at the same time they both
have their values. For computer programming, particularly in a startup, being
goal oriented is very helpful. Someone process oriented would probably be much
happier doing something else.

------
d0100
Anyone else bothered by her phrasing of "he’s trying to be helpful" followed
by "Bless his little heart"? Why would anyone publicly address their SO in
such a patronizing way? This just bothered me more than it should.

~~~
briansteffens
Also "Sometimes he says wrong things, and then I have to explain why those
things are wrong.."

Sounds more like she just lectures him rather than having actual
conversations.

~~~
thesimpsons1022
yeah and what does that have to do with the article at all? not sure why she
included it. imagine if a man said that stuff about a woman. i'd hear sexism
and mansplaining nonstop.

------
str33t_punk
'I'm not a white male!'

Seriously? This felt incredibly out of place in the article, it seems like its
just pandering for clicks (lets talk about how women, minorities, and 'non-
tech' people don't have a place in tech for the millionth time!). Not to
mention the quote could have worked similarly with 'asian male' and 'indian
male'. Why are you erasing the identities of other overrepresented people in
tech?

~~~
Kenji
Because otherwise the article has no substance. Better write a couple of
preposterous lines and then back off and turn the subject to something
completely different. I know _exactly_ why a person who writes like that does
not belong in tech. Imagine code written like that. Just the imagination is
the pure horror.

~~~
qwertyuiop924
>Because otherwise the article has no substance.

Not true. And trust me, I hate substanceless articles as much as the next
person. But once you get past the opening, the article is about mindsets,
which are much more interesting.

>Imagine code written like that. Just the imagination is the pure horror.

People don't write code the way they write prose. If they did, Steve Yegge and
Yossi Kreinin would have been fired years ago (what makes for good prose
doesn't make for good code).

------
IsaacL
_" I am not comfortable making half-ass s..."_

Agile and Lean both contained good ideas, but they've been misinterpreted.
"Flexible processes" became "no processes", "rigorously test your assumptions"
became "try things at random".

Web and mobile are becoming mature platforms. There's now a long history of
web and mobile products to study - the design, engineering and business
principles for success in these products should be well-known. They're not
because of the rampant ADHD and short-termism in the industry.

~~~
morgante
> I'm a white male - a right-wing white male - and I agree with her.

Why do you need to include that?

She very deliberately said that this is _not_ an article about race, gender,
or politics.

~~~
dageshi
The article author spends numerous paragraphs establishing her identify to the
reader as a womain in tech before explaining that this isn't the issue she has
with tech. The comment author has merely done the same?

~~~
chris_wot
As someone with ADHD, I guess I should be insulted by IsaacL's post, but I'm
not. I thought it was fair comment.

------
tonyle
Reminds me of Ira Glass's Quote.

[http://www.goodreads.com/quotes/309485-nobody-tells-this-
to-...](http://www.goodreads.com/quotes/309485-nobody-tells-this-to-people-
who-are-beginners-i-wish)

And for a different perspective. This was posted 5 days ago.

[https://neilonsoftware.com/books/personality-patterns-of-
pro...](https://neilonsoftware.com/books/personality-patterns-of-problematic-
projects/developers/the-idealist/)

------
skybrian
Maybe the solution would be to switch to working on a different kind of
software, where everyone agrees that getting it right really is critical?

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

------
matt_wulfeck
> _But that’s where the anger ended, in not being white or a man or coding
> since I was two or some combination of the three. This wasn’t going to work.
> Coding wasn’t going to work. I didn’t belong._

What's interesting is that white men, with no gender or racial bogeyman to
hide behind, have created the term "imposter syndrome" to explain feelings
that are almost universal in this field, and also very evident in this woman's
essay. You don't belong. You don't think like them. Your mind is different. If
only you programmed since you were 5 on your family's Amiga.

It's sad for me to see gender and race become the focus of her disappointment
in her career. In a twisted way it puts even more distance between her and
other engineers who invariably feel the same way but are trying to cope with
it on their own.

Maybe she's worried they'll "say wrong things, and then I have to explain why
those things are wrong" ...

------
danso
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.

------
vdnkh
> Sometimes he says wrong things, and then I have to explain why those things
> are wrong

>please sit tight while I take a moment to roll my eyes

>You failed fast and broke my heart.

>Maybe I will change

It's hard to learn if you never accept that you're wrong. Admitting defeat is
not accepting you're wrong.

------
falcolas
If you have the opinion of "This wasn’t going to work. Coding wasn’t going to
work. I didn’t belong" _before you even start_ learning a new skill, of course
you're going to go through your career with that new skill believing you don't
belong.

It honestly sounds like the poster really needs to invest in some self
improvement before diving back into a career. If you want to succeed, go in
with the expectation that you will succeed. Do whatever it takes to succeed.
Don't start with an expectation of failure and expect everyone around you to
change your mind.

------
Clubber
Most of the things mentioned annoy me too and I've been doing this for going
on 20 years now. Perhaps move into a different industry that uses tech but is
not tech. Some companies appreciate 10+ year code. (Code you write that you
expect to last 10+ years).

Churn and burn code fits SV right now. VC's invest in hundreds of companies
expecting only a few to make good money. It makes sense to only build enough
product that proves the business model / concept. If the business model is
bad, it's better to have paid less to build it than spend more for solid code.
Solid code costs time and money.

Traditional companies that use tech want a product build well that has low
maintenance costs and will last them 10+ years. They are more willing to build
a tight application rather than a loose one because their business model is
already proven.

------
morgante
This piece really frustrates me because it _pretends_ to be neutral, but
actually has a very clear viewpoint of denigrating experimentation. It's very
clear that she actually thinks tech (not her) should change.

~~~
wycats
I hope nobody quits tech, and certainly not because they are frustrated that
the tech industry chronically celebrates solving problems we don't understand.

------
hippich
Not sure why it had to be prefaced with "white man" talk. Majority (all?)
people in software development, who are doing it because they like it, hate to
do half-ass job. Yes, even some silly-simple web widget most (all?) want to be
perfect. So this has nothing to do with "feelings", being a woman or being
non-white.

Trying to deliver perfect product is good in vacuum, but not so in real world.
For real world perfect product is not the same as perfect product in vacuum.
It takes time to truly understand, but OP, just like all other devs, will get
it eventually.

------
ascotan
Interesting. Here my 2 cents.

Most software that i've worked on is terrible. It's terrible because software
engineers by nature are 'technology muddlers'. They know how to program but
have little insight into the world around them. By this I mean that there is
very little in the way of 'deep understanding' by the guy fixing the problem.

Image I gave you a hammer and a box of nails and I told you to build a house.
"Sure thing", you say. What sort of house am I going to get? A shack? Sticks
nailed together? Cardboard box? It totally depends on the guy with the hammer.
What happens if I gave 6 people hammers and boxes of nails and asked for the
same task? Would the product be any better?

Most software developers get away with crap as a delivery because the cost of
failure is low. So there's no real incentive to 'do it right' or 'make it
perfect'. In fact the opposite is true. There is a real cost of failure
attached to understanding a problem and taking time to solve it correctly.

If I was given an hammer and nails and asked to build a house, I could put
down the hammer and go away and become an architect. However, I'd never get
the house built, or I'd realize that a hammer wasn't an appropriate tool for
this task. Now that you have a deep understanding of the problem now you
realize that the problem is not solvable without a large time and expense.

"But I've promised that delivery in 90 days", says your boss. You then explain
how that, given a toolbox full of hammers and 200K nails, this project is
going to end up as a large ball of mud.

In the end the 'business of software' is pragmatic. Do you as Cassandra,
having knowledge of the future but no power to change it, fight the inevitable
ball of mud? Or do you accept that yes, you will not be proud of this body of
work, and dutifully search Stackoverflow.com for another mud layer to pat onto
it?

Personally I'm also a perfectionist and like to understand the problem deeply.
I've found that this is a hindrance as well as an asset. I think that if you
find yourself in this situation, find someone that is the opposite to pair
program with. That way you can balance out your own strengths and weaknesses.

------
bayonetz
The authors espousing of deep problem understanding sound like it would be
more at home in a PhD program / academia. Also, sometimes it's possible people
just "pick wrong" in the sense that they don't or can't think far enough ahead
to realize where their best fit will be professionally. Wouldn't be surprised
if that's what's going here. For example, I'm pretty sure, in hindsight, my
best fit would be as a psychiatrist / psychologist but I'm too far down the
path as an engineer to really want to change course. Instead I've channeled my
strengths and leanings by working in ML and user-centered design as much as
possible. That helps but never fully makes my fish out of water feelings go
away. I have much more of the "feeling" predisposition than the overwhelming
"thinking" predisposition of eng teams I've always worked on. Earlier on I
felt like this oppressed (in terms of values) minority but once I learned
about innate personality type distributions I was able to stop taking it so
personally and in fact use it to my advantage by taking on roles where my
differences were in fact strengths (being the guy who made sure the UI didn't
feel like dogshit, thinking through how to personalize our shopping
predictions, etc.).

------
combatentropy
The writer complains about the tech industry and anticipates any replies. Her
tone is feisty. She cites general scenarios as proof, and by the end she is
inconsolable. After years of experience, I think she is the kind of person who
somehow attracts you to help her but who will stab you in the chest when you
try.

It sounds like she has had a few experiences that wounded her deeply, and she
has decided to protect herself by closing up. But I think her experience is
limited. There are places you can work that let you craft great code. They
typically are not in the tech industry as she defines it, "companies and
professionals who view code as a core part of their business and their self-
understanding, both internally and externally." And I'm not sure she will find
a company that actually encourages good code, only one that gives her space to
code how she wants --- not because they appreciate good code but because they
don't understand it. Their programming team is a black box, and whatever
estimate you give they have to just have to accept, like when your mechanic or
your doctor tells you it will take such-and-such.

I would advise her to look for a job where tech is an ancillary part of the
business, perhaps a programmer at a hospital, college, or niche-but-profitable
industry. Or, as others here have suggested, working more on back end than web
front end. No matter where, she still should ask lots and lots of questions of
the company, preferably of the employees themselves if she can get a hold of
them. There are pockets of good, but like anything in the world they are
diamonds in the rough, and you have to do some digging to discover them.

------
FT_intern
She was only a developer for 6 months. Sounds like an ad hominem, but it is
relevant to weigh her longevity in the field when she criticizes the field.

------
firefoxd
I had that feeling. It went away after a few more years.

I used to try to fix everything and stay up at night thinking about a strategy
to turn the spaghetti code into a well structured framework. What you don't
realize before you start is that it takes an awful amount of time and the end
user doesn't even notice it. You make it harder on yourself thinking about the
ideal code rather then fixing the problem.

It's all about making it work. And trust me, that in it self can be exciting.

Think about maintaining an old php project where the original developer is all
gone and you have to figure it out. You can complain all you want, try to
convert it to rails, or you can fix the bugs. That feeling of figuring out and
fixing it is where i get my thrill.

------
qwertyuiop924
That wasn't the article I was expecting. Which is good. Because I was
expecting the, "I am a woman in tech" article. You know the one. What I got
instead was a very well written article about something that I can actually
identify with.

And it's something that a lot of people in tech complain about. Maybe not your
coworkers, or your boss, or your friends on the internet. But the people doing
major work. People like Joe Armstrong and Alan Kay.

I don't know if you'll stay with tech. But if you stay, I'm confident you'll
find people who think like you do. Eventually.

------
kevan
Echoing the sentiments of others here, it looks like she's been in startup
world for the past few years, maybe she should try working with different
types of companies for a while.

------
odammit
I used to work in healthcare and banking. Failing fast isn't encouraged in
either.

The problem with fields where perfectionism is expected is that everyone knows
you arent going to do a perfect job.

So you end up having 50482772 code reviews with 30 people pouring over every
single semicolon, that is also very frustrating.

Maybe the author should get out of web/mobile development, but I'll take some
dipshitty code that I know I can fix over highly micromanaged perfectionism
any day.

------
davidf18
Software, standard engineering (e.g., EE, Civil, Mechanical), and clinical
medicine are fields in which in order to understand and learn requires an
iterative process of attempting to understand, trying something out (coding
and debugging, designing and trying out a hardware or a building or mechanical
apparatus or attending to patients) and learning.

When it comes to these sorts of applied fields it is important to do both.

------
rokhayakebe
Perfectionists rarely finish, but when they do, it's usually everything they
wanted and more than you expected.

I can't be a perfectionist in anything.

More than perfectionists, though, I like those who focus on building that one
product, writing that one book, solving that one math problem over years. That
is people who are dedicated to a problem and have removed Time from the
equation.

------
nickstefan12
This feels very INTP vs INTJ. Both are stereotypical engineers, but INTP
typically values understanding the problem. INTJ is stereotypically more
interested in leveraging just enough understanding. The world needs both. I'm
not surprised that the ESTJ managers and such don't value the INTP style...

------
agumonkey
I kinda get the feeling, the holistic understanding has always been a
requirement for me, and peaked when systems grew either too big or too fluid
(js fatigue).

It's hard to accept the sniper mentality where you try to find a target ASAP
and remove it quickly. Instead of migrating the world smoothly.

------
platz
OP posits that industry developers have different values than hers; but how
much is it that she's simply learning about the business side of things?

In other words, is her problem really with developer's values, or with
business/operations/management?

I feel a bit like she's simplified it a bit by placing everyone in into a
"Tech" category (vs her experiences with non-tech).

Are there not inter-company divisions, that are usually in opposition
regarding these values (with developers, usually having the least leverage in
the business, following business priorities)?

~~~
dwaltrip
It basically sounds like she doesn't want to be a pigeon-holed implementation
engineer in a fast paced silicon valley startup.

The traits she described can actually be quite valuable. She just need to find
the right role. Or perhaps one day start her own company.

------
ridgeguy
She might well be happier in a different development environment. The link [1]
is to a 1996 article that describes organizational aspects of Space Shuttle
flight software development. The priorities were understanding and perfection,
which may resonate with the OP. Shuttle is history, of course, but I'm sure
there are similar mission-critical coding environments today.

[1] [https://www.fastcompany.com/28121/they-write-right-
stuff](https://www.fastcompany.com/28121/they-write-right-stuff)

------
dominotw
overly flowery writing made it really hard to get at the core point the author
was trying to make.

from what i got she wants everthing to be perfectly done with unlimited time.
I would imagine one of the core qualities of software dev is figuring out what
level of perfection is acceptable. Not everything in the world need to be 100%
perfect, Walmart exists for a reason. That said its a welcome attitude in
world full of crappy software.

~~~
alangpierce
I'm pretty sure the style of writing was to convey emotion and help people
understand her perspective at a deeper level, it wasn't just long for no
reason. In this case, the article is specifically about what motivates us to
keep on programming and keep on building things, so the human side of things
is really important. It's not just that she wants everything to be perfect,
she believes that the relationship between a website developer and one of its
users should be one of trust, and it feels wrong to betray that even if it's
more efficient from an engineering standpoint. Accurately conveying "this
feels wrong" is complicated, hence the long article.

------
notalaser
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.

------
dublinben
The writer sounds like a crippling perfectionist. The world isn't perfect, and
neither is any real program. It's an important step in your personal
development to recognize and deal with that.

Perhaps they would be happier as a designer, where they can make everything
fit into perfectly neat boxes.

~~~
zachlatta
> Perhaps they would be happier as a designer, where they can make everything
> fit into perfectly neat boxes.

Typically I'd just downvote, but was that condescending comment really needed?
This is the sort of toxicity that turns people away from our community.

~~~
angersock
It is a fair comment. In design you at least have a chance at clean work safe
from messy reality.

~~~
dack
I'm not sure about that - designers have to build a UX that works in the real
world, and sometimes there are really complicated processes that need to be
exposed in a nice way. I imagine this has similar tradeoffs as programming
(i.e. difficulty in implementation, balancing power/intuitiveness)

~~~
user5994461
As a designer, one can live exclusively in "photoshop", ignoring the
complexity of the process and the reality of usage. It's not like you can
"test" a drawing with a real user.

As a programmer, you gotta get all the little details right or the application
is not possible to use. There is no way around it, whatever is forgotten will
just hit you right in your face.

And last but not least. Drawing is dead easy. A programmer could design a UI
in a drag&drop devtool maybe as fast as a designer. The challenge when
creating an application is not the drawing of the UI but the handling of the
user interactions and the data.

~~~
dcole2929
This is such a massive simplification of what a designer does it's actually
amazing. You're first and last paragraphs are simply wrong.

First of all a designer doesn't get to live exclusively in photoshop or some
other tool. They don't get to ignore the "reality of usage". In order to be a
competent designer they have to not only completely understand the problem
domain, but also the given software solution and how a user can use the
software to achieve the desired goal in the most concise manner. They have to
worry about how to signal to users how to perform any given interaction and
the overall complexity any activity has. Also they absolutely do test designs
with real users. There is like a whole field of study in design around exactly
this.

As to your last point, drawing != designing. Designing is actually really
hard. This is a problem I see with programmers all the time. The
oversimplification of others contributions. Yes you can put together a UI with
drag and drop tools. You can build a website with drag and drop tools too and
you'll probably get the same quality as the drag and drop UI. A drag and drop
design will probably have most of the various pieces. But will it be obvious
what actions a user can take from any given screen? Will it properly optimize
screen space, and be color correct? There are a 1001 questions that a designer
has to ask that most programmers wouldn't even think to ask. There are many
challenges when writing an app, and good design has proven over and over again
to matter just as much to the success of a business as solid code.

~~~
user5994461
We both agree that there is a difference between a "drawer" and a designer,
just like there is a difference between a "code monkey" and a developer.

First paragraph. I could say all the exact same thing about a developer.

Second paragraph. Yes to all your questions. I should clarify that the
drag&drop tools I had in mind were for desktop applications, not web, that's a
different world.

------
wglb
_I do not belong. My values are not valued._

Well, I can understand the feeling, but the industry needs more programmers
like the author.

------
_RPM
This was way too long for me to read. I wish she would just get to the damn
point instead of going into pointless details about her feelings, etc.

------
aibottle
Reading the first paragraph of that "article" I only can respond to the title
saying: True.

------
swiftisthebest
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.

------
jimmywanger
This post is horribly verbose. It constantly brings gender and race into it,
then disavows it a couple paragraphs later.

This is a textbook definition of a first world problem. Don't like tech? Don't
do it. Nobody has a gun to your head. The worst part is having a job, "hating"
it, and spewing your hatred of it across your social circles. That does nobody
any good. You're not a slave. Either you dislike not having money more than
imperfect tech, or I guess you're going to be doing your job for the
foreseeable future.

The worst thing is expecting the world to change according to your ideas of
what the "right" thing to do i.

~~~
Veen
> Don't like tech? Don't do it.

Alternatively: love tech but don't like how it's built and the incentives in
the industry? Try to change things for the better.

Your way, nothing ever improves. Her way, things might get a little better for
some people. At the very least, there's a benefit to highlighting the issue
and generating some conversation.

~~~
jimmywanger
> Try to change things for the better.

Change arises closest to home. Instead of setting up straw men to knock down
on the internet, why not quietly work to change your own work environment? I'm
working on a Node.js code base I'm not particularly enthused by, but I'm
trying to make it better by pointing things out and speaking up about
inefficiencies or unprofessional coding practices.

> At the very least, there's a benefit to highlighting the issue and
> generating conversation.

That is completely false. The issue she's highlighting is that she doesn't
like the way reality is, and that reality should change. That's not going to
happen, especially with that attitude. The only conversation this should
generate is "Ok, we all have things we have to deal with. Stop complaining and
make smaller, local changes rather than dumping your feelings all over the
internet in elaborate prose. That is worse than useless, it actively advocates
against your cause. Who would want to be on your side when all you do is
complain illogically?"

------
collyw
Sounds more like she values all the startup culture over proper engineering
values. "Lean methodology", “fail fast and break things,” Javascript would
point in that direction. Pretty sure other areas of tech would value good
engineering over those things.

------
hprotagonist
Tl;dr: researcher discovers they're a researcher not an engineer.

------
andrewvijay
Write the friggin tests is what she means to say.

------
saiko-chriskun
textbook imposter syndrome

~~~
stale2002
This is like the opposite of imposter syndrome.

She cares about quality and is upset that no one else seems to care.

