I don’t belong in tech
medium.com
medium.com
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.
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.
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.
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.
Most of them came from.a gateway called CyberSource.
Also, lots of customers have weird banks where they see both an authorization (I.e. hold) and the actual capture, and they mistake it for two captures. Usually it helps to educate them about what is an authorization.
Most banks don't even bother showing the customer authorizations of any kind.
That bit us in the A$$ with double payments a few times.
0- https://hc.apache.org/httpcomponents-client-ga/httpclient/ap...
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.
The race condition resulted in an error syncing between two datacenters, so when it happens it can be dealt with manually.
Also, to be clear, it did not affect customer waiting time as the delay was in a webhook which we used as a backup to the main payment process.
Taking a bug out to tea is fantastic, because it really is about understanding the problem. But she conflates maintenance coding and program writing. There is a lot of half-baked software out there, but to say that this isn't like any other industry - like journalism - is really patently absurd. Despite best intentions, journalism is absolutely like programming. A sub-editor is really just like your QA department in many ways. And just like she made a mistake in a script on NPR unintentionally, so too do programmers.
This piece is really a mass of contradictions. Take the following:
But here’s the thing. No one will ever remember that number. No one remembers it now, and I’m sure no one noticed it when it happened. But I knew it happened, that it was an easily preventable mistake, and, in journalism, being wrong in that way is absolutely unacceptable.
So... what is it? Was it unacceptable that the figure got into the story to the extent that she got fired? No, of course not - I'm assuming NPR ran a correction, and forgave her for her mistake.
I really doubt most programmers are going out of their way to slap together code that has deliberate bugs. Yeah, they exist but to say any software development house that writes email clients, job seeking sites or any other software are intentionally encouraging this sort of behaviour seems to be an insult to the vast majority of founders and software developers who work hard to hone their craft and take care to produce quality software.
This essay seems overly emotionally wrought and with a perspective that is out of kilter with reality. For me, despite her protestations that she is no better than all the others who work at software development, there's an implicit undertone of superiority masked by claims of victimisation and isolation. It's not particularly fair, and it seems rather manipulative to me.
This is totally not how things work in tech though. First of all there are a lot more mistakes/bugs, and because of that how bugs are handled is completely different. If you're not doing something where lives/money are at stake, it's ok to release with bugs so long as they aren't showstoppers. When I write something that has a bug in it, I don't even get talked to. We just write it up and toss it in the list with all the other bugs.
There are of course situations in both industries where things are different but I think in general there is definitely a major difference in how tech treats mistakes as compare to how pretty much every other industry.
Moreover, sure NPR might fire you for repeatedly using incorrect numbers for which they then have to publish retractions but that doesn't stop you from using essentially correct statistics in highly misleading ways, a sin all major media sources are guilty of.
And a million sysadmins across the world cried aloud in agreement and despair.
The point is that I think there are business side problems more than there are tech problems in this industry as a whole. I think the phrase "the perfect is the enemy of the good" is a dangerous one for so many managers to latch onto. More on point to the article though, we need more magnum opuses, more results of this kind of long term thinking, put into action. Not more band-aids on problems.
I do think though, that big picture thinkers of this ilk do find themselves trapped into a twist on the Bertrand Russell saying, "The trouble with the world is that the stupid are cocksure and the intelligent are full of doubt."
What we need then, are some of the intelligent to gain a bit of the cocksuredness, and the stupid to gain a bit of doubt.
Those other industries? They are already quite mature, and are operating on razor-thin margins, often in the 5% range.
I think it's reasonable for people to wish that more of user-facing software worked this way, even though it's out of sync with how Silicon Valley and Venture Capital tend to work.
If anything, I think this demonstrates how talented Apple's marketing team can be, as well as how meticulous their UI team can be. I myself am a huge fan of attention to detail, and we need more of it. I've used Skylight before, and if I'm working on another project that could benefit from it I'd recommend it again, so thanks for paying attention to all the little things.
“Well if no one out there understands, start your own revolution and cut out the middle man” - Billy Bragg, Waiting for the Great Leap Forwards
Bragg was writing about the tension between being a musician and being a political activist rather than the tension between problem understanding and problem solving, but the tension seems to be everywhere. I've got a friend who was frustrated about how little his PhD had to do with philosophy because there was no time for that, only time to publish. Alan Kay said something of the ilk in the epic Ask HN thread a few months ago, referring to how hard it's been to get funding to do good research for something like the last 35 years or so. Hopefully the author can find her 'birds of a feather', it's not like we lack problems that need understanding.
I don't understand. He studied philosophy but ended up writing a thesis that was only tangentially related to the field?
Or he assumed that "Doctor of Philosophy" was related to the field of philosophy, and was disappointed that he couldn't talk about Plato while writing about physics?
I also think the philosophy of computer science is very interesting, though. I just saw that Oxford offers a course that combines computer science and philosophy: https://www.ox.ac.uk/admissions/undergraduate/courses-listin...
The reason why academic titles have the word philosophy in them is because modern investigations have developed from the philosophical tradition.
For example, philosophers may have a question, "what is value?", or "what is the nature of the world?", born out of the philosophical tradition.
Then, after sufficient discussion and philosophical investigation, they figure out that certain methods, approaches to answering these questions, are very fertile and lead to informative answers, e.g. value as a real-valued mathematical measure, or the nature of the world as a generalization of empirical observation.
Such methods may prove to be so fertile that you may have academics spending decades or centuries investigating the implications of that method. Hence you have economics and philosophy.
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.
If I build a house with a bad frame, it's really hard to make it better over time. If I build a quick MVP, I can easily incrementally improve it.
But sure, it'll be different this time.
If you can code something quickly and well enough that it doesn't immediately collapse under its own weight, you have succeeded. The fact that a codebase has existed long enough to become "legacy" means it did a good enough job to stay alive.
I don't think that's fair to a large number of engineers. We know that code gets loaded with technical debt and we know that we can't spend time fixing it because of "business realities". That doesn't mean it isn't a problem for us though. Anyone whose had to maintain a codebase that's years old and riddled with undocumented and untested "features" suffers for it. Old code is a source of stress and anxiety. It might make money, but that isn't a reason to think it's not an issue.
Far from. The worry is not "this code is old." Plenty of old code (especially boring old code) is cranking along just fine.
The worry is that if an old, abstruse system stops working or has a critical security bug, there's a real risk that nobody will be able to put the fire out.
Well, yeah, for the first version. But when is the first version also the last one? Not in many good situations. Crap that doesn't immediately collapse under its own weight will probably immediately collapse as soon as you add more weight to it in version 2.
A lack of anxiety about the structure of the product is myopic and ignorant of engineering realities. There's got to be a balance. Too little anxiety, and you lose customers to competitors that spent more time to build a quality product, structured so that it's easier to grow. Too much anxiety, and you're in a "perfect is the enemy of good" situation, and you'll lose customers to competitors that were able to iterate faster and with a proper balance.
But you won't. Even if you want to, the client won't pay you to because all the client sees a working solution, so you never get the chance to.
That's the problem the author is highlighting.
Code "quality" (whatever bullshit metric you use for that) is not the only metric of improvement. In fact, it's probably the least important metric to optimize over time.
Usually that's new features and bug fixes. It's very rare to find a client who'll happily pay for refactoring. If you're in a job where you get time for that you should consider yourself very lucky indeed.
EDIT: For what it's worth, I agree with your point about code quality. What's 'beautiful' now is only 'perfect' in the frame of the current feature set. It might be horrible if the next feature that comes along changes things dramatically. I'm very much of the opinion that "good is better than perfect", just with the addendum that the code at least has to be good. Bad code is just bad.
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.
I find the beauty of code is not in adhering to someones concept of elegantly written code, that only the coders see, but in the fact that it's living, and that over time your solution can evolve to become better than its intended purpose. Something observed to be perfect usually has a past that is often overlooked.
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.
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.
This may be true for trivial web apps, but line-of-business software is often used for years, sometimes decades.
Software falls over all the time, often in very avoidable ways that give the impression of simple laziness and/or incompetence.
E.g. Why do I need to use Safari to log into my bank account? I bank with a household name bank in the UK, but they've failed to make their web portal work with Chrome.
Why does iTunes let me set up a new iPad, but at the end of the process I get a choice between two buttons labelled "Sync" and "Done" - and I still have no idea what either is supposed to do, because sometimes I get a message about syncing to an old backup, or something, and the whole process is utterly counterintuitive.
Why can't operating systems handle paths with spaces or unicode with a standard convention for quoting that ensures consistency? It's 2016, not 1966, and this shouldn't even be a problem. But it is, for a lot of languages and operating systems.
And so on. IMO the author is right. We have a "dog ate my homework" industry made of quick superficial hacks bodged together, when we should have an industry built on solidly professional standards, conventions, and expectations.
Yes, the hacks ship. But if they don't work, how is that a success?
The attitude is built into the culture, and it shouldn't be. It should be impossible for anyone to become a professional dev without some lectures or lessons in domain analysis that forces them to confront a fundamental lesson - the problem is always harder and more complicated than you think it is.
A talent for cute math and logic problems is not the same thing as being able to dive into a novel domain, extract the essential elements, design a workable architecture to represent the elements, and then iterate towards a robust solution that can survive contact with users.
I think the attitude of doing less things better is quite common among successful software developers. It's just hard these days to have a good experience while getting to a level where these values matter.
Building 90% of a software is easy, getting to 100% is insanely difficult.
Building 90% of a construction/hardware/car/... is hard, the final bits are easy.
Finishing always requires more attention to detail, and a tougher sense of good-enough than the first 90%.
They don't, but a good carpenter is not going to try to figure out how to make every single wall perfectly 90 degrees, etc. He's going to take a level, see if the thing is in a center for a given stud, make that work, and then move on.
They never perfect the end result. None of the walls in your house are likely perfectly square and plumb They also use imperfect building materials, and so they know that a year from now, even if it was square, it wouldn't be anymore.
Carpenters, more than anyone, are true believers in "good enough". I'd argue most of your other examples are the same.
That said, the problem she complains about is real. She is, in essence, a programmer from 30-40 years ago.
When you had to share time on computers, and your software broke, you didn't just poke it repeatedly until it worked, because you couldn't. Instead, you sat on a mountain and meditated upon your code, until you understood it well enough to fix the problem and try again.
In that sense, the thing that has really changed is not the cost, it's the speed at which you can throw shit at the wall.
Development is so fast nowadays that programmers don't stop to think about the real underlying problem, they just want to make the compiler shut up or the program keep going.
They just want to solve whatever their immediate problem is.
The cost incentive was always there. People always wanted good software as fast as it could be built. It was the speed of being able to build it that made people concerned with quality.
Now that they can essentially build it at light speed, nobody cares, because it's only how it seems to work that matters.
IE doing things the wrong way to achieve the result people want is fine, even if it causes longer term problems.
You can see this in pretty much any long-running (IE 15+ year) open source project.
:)
So yeah, it was entirely possible they didn't introduce more bugs.
Now people just expect to crash often and make it up in volume.
They can of course, which is precisely the problem the original author has: in a ton of contexts, fast and able to hack up things is more sellable than understanding problems.
(and FWIW, i actually haven't thought hard enough about it to have an opinion whether the current status is better or worse, i'm just explaining why it's not necessarily about cost to develop).
Although we may have formal engineering education, most of us end up making business logic where there are few rules on how to do it. You can't compare it with building a bridge, which has a strict mathematical workflow.
The use of the word "still" here implies that it will be, or that it should be, more "science" than "art". As an act of creation and navigating ever changing constraints, I think it is more art, and will have art be a major component of it for a long time, if not forever.
Of course, the definition of "perfect" is different for everyone. The point is that craftsmen can wait until they're fully satisfied with what they are working on before releasing it. Engineers don't have that luxury.
In places where failures are expensive, such as high volume websites, we use techniques such as A/B testing to limit the scope of expense of failures and detect them earlier.
In cases where failure is truly unacceptable we take more drastic measures such as formal verification, restricting programmer freedom through coding standards, etc.
Even he dramatic story about having a wrong number read out on NPR you'll notice she is the one punishing herself; no-one really admonishes her, there are no negative repercussions. As economic pressures have increased in journalism, this attitude that everything must be fact checked has fallen by the wayside since it is not economically viable any more. This economic pressure coincides with mass adoption of the internet though, and the real cause may not just be their declining ad revenue, but the increased competition between news outlets to be first, since that's what drives clicks.
The saying that the perfect is the enemy of the good exists for a reason.
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."
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.
(12) Perfection has been reached not when there is nothing left
to add, but when there is nothing left to take away.
Given objectives, constraints, and means, the most fit set of solutions are the "perfect" ones.
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.
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.
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.
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.
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!
you say that but the industries you mentioned have some of the worst code possible.
This isn't about writing great code, it's about the culture surrounding release.
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.
Sounds more like she just lectures him rather than having actual conversations.
That annoyed me in The Fountainhead, and it bothers me in this prose also.
I think there is a big difference between being bothered by someone's comments and litigating them :-)
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?
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).
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.
Why do you need to include that?
She very deliberately said that this is not an article about race, gender, or politics.
http://www.goodreads.com/quotes/309485-nobody-tells-this-to-...
And for a different perspective. This was posted 5 days ago.
https://neilonsoftware.com/books/personality-patterns-of-pro...
It sounds to me like the author wants to get it perfect, not just right. And even in those other kinds if software, you stop when it works well.
It might even be worse, as the developer needs to sometimes willingly make the product worse in some areas to make it acceptable in others, and that kind of compromise hurts to a perfectionist.
[Just a thought]
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" ...
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.
>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.
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.
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.
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.
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.
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.
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.
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.
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.
When it comes to these sorts of applied fields it is important to do both.
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.
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.
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)?
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.
[1] https://www.fastcompany.com/28121/they-write-right-stuff
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.
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.
Perhaps they would be happier as a designer, where they can make everything fit into perfectly neat boxes.
The interesting part is that programming is the one place where perfection escapes me, as in I haven't desired for it. I realize there are bugs and caveats to written code. My flip side here is that I strive for perfection of the user's experience. I do get disheartened when a user experiences something negative in the code based I work on.
The key for me has been focusing on the perfection to a user and not perfection of code. There may be a dark edge that they never see, and it's fine.
When there is a careless bug, I still struggle balancing empathy and drive to fix it. That's fine, however, as I'm aware and work to not do it. I could see where someone who strives for perfection would easily get disheartened and feel misalignment in values.
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.
A condescending comment would be something like: "Maybe you should stick to your pretty R graphs for 'journalism' and leave discussion of software engineering to the professionals who actually get paid to build systems and who haven't, as a profession, fucked up on every metric in the last decade even without including the most recent election."
That would be a condescending comment--the one you are remarking on can be interpreted as "hey, designers get to make pretty things unfettered by layers of shaky abstractions and stupid imposed by business and deadlines".
Please don't rush to aid the theoretically aggrieved; especially when there are folks in this same subthread going "yep, as a designer, that's the truth".
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.
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.
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.
Also, design in the context of a team especially ought be perfect, because your perfection will be degraded in a game of telephone.
By perfect, I don't mean that your design fits the user with maximum optimality. I mean that when you draw a box, you actually mean a perfect box. When a mathematician draws a square, they are describing a perfect square. It would be a little socially blind to pick up a magnifying glass and accuse the mathematician or the designer's square to be imperfect because you find the bumpy ugliness of a 1080p monitor or a sheet of paper.
Given that you do not possess the prerogative to control the costs of your potential mistakes, ought not calls of toxicity be restrained toward obvious cases? Also, how toxic are mistaken accusations of toxicity?
There are lots of branches of technology work that prize understanding over shipping.
The entire official story of "lean" is "build, measure, learn", which is fundamentally about developing a process for shipping while deepening an understanding.
The hermeneutic circle (https://en.m.wikipedia.org/wiki/Hermeneutic_circle) cited by Dave Herman of Mozilla Research and Brendan Eich (about JavaScript) is a process of iteration that prizes a deepening understanding interleaved with lessons learned from shipping.
I didn't interpret the OP to be saying that she wanted to gain a perfect understanding before shipping, but rather that she preferred a style that focused more than the tech community average on deepening understanding.
And I don't think she needs to go to a different branch of technology to get that. Maybe app development needs more of it.
Steve Jobs famously talked about the interplay between understanding and building: https://wycats.svbtle.com/theres-a-tremendous-amount-of-craf....
I think we could do worse than to think about this topic more.
Her mindset of wanting to fully understand the problem, why it's a problem, etc seems like it would fit be in an environment where you had lots of time and a lot of people that you could meet with to gather information, plan, etc.
6-7 years ago, I interviewed at EFJohnson. The position involved maintaining code for systems used by emergency services (might've been related to E911, but I'm not sure). I distinctly remember one of my interviewers telling me, "if we screw up, people die". I'm fairly sure my lack of self-confidence was why I didn't get the job; he could easily see the nervousness on my face when he said that. However, it sounds like that kind of job would be perfect for the author.
Well, I can understand the feeling, but the industry needs more programmers like the author.
People who cannot process their emotions should not try to build a startup.
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.
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.
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?"
She cares about quality and is upset that no one else seems to care.