One of the replies by a Googler explains the rejection succintly:
"I suspect that you are awesome as a developer in a certain place, but that Google—at least as a software engineer—wouldn’t be the right fit for you. They really do want computer scientists. The ability to figure out what to build isn’t valued all that highly, because that’s not fundamentally the responsibility of the software engineer."
What irks me is that a lot of companies have imitated Google's hiring process without ever stopping to consider whether it's right for them. Do they want engineers who are computer scientists rather than engineers who can figure out what to build?
In Google's case they explicitly don't want the latter and hire accordingly. The company is structured to make this work -- there are product decision makers who understand software and can feed work to the CS-focused engineering teams.
My feeling is that most other companies would be much better off hiring engineers with a more user-oriented mindset, yet they end up explicitly filtering that out because they want to hire like Google.
Another interesting example is Shazam, which listens to 10 seconds of music and identifies the song. When I encountered it, I knew immediately that its implementation must be based on a fourier analysis of the sound to generate a fingerprint. That's because FA was a required part of my engineering curriculum.
No matter how good a programmer I was otherwise, without knowledge of FA I'd probably hack around for years with one inadequate ad-hoc solution after another. If I was really clever, I may even actually reinvent FA, badly.
This is where having proper engineering/mathematical training pays off. Just being a great programmer is just not enough.
For another minor example, I was given the minor job once of printing what was on the graphics screen on the printer. I knew that constructing a coordinate transform matrix was the answer, and had it running in a couple hours. A coworker, an excellent programmer, who had never heard of matrix math, was completely astonished at this and thought it was just black magic.
Not sure about your examples. I mean, when working as a programmer, we encounter tons of things we've never heard before but we do the research, we study what's needed to complete the task and we complete the task... e.g. it is quite easy to search about audio recognition - you encounter fingerprint, then you do the research...
Your examples make sense when you're isolated on some island without a connectivity, but that's not the case usually.
Also, I think companies like Shazam have separate people/teams in "science/research department" and "engineering department".
It‘s easy to google how Shazam works now, since they exist.
I‘m pretty sure that googling for „audio fingerprint“ or „algorithm for recognizing a song“ wouldn‘t have gotten you the answer in 2002.
You need to know the maths if you want to invent something new. If you just want to reimplement existing stuff, maybe you can get away without it.
(Inventing new stuff is actually pretty rare for programmers. I don‘t think I‘ve actually invented much, despite having worked as a software developer for more than 15 years...)
People tend to underestimate the age of working knowledge a lot.
Shazam wasn't an original invention, similar things were implemented in hardware in the 80s, and original research in this area done even much earlier.
Sure, though, as you go back in time, the probability that the environment you could get exposed to that knowledge in overlaps with academic circles probably increases.
Seriously, consider that the PARC people were working on perceptrons decades before they became truly feasible. There is almost always prior art to build on.
The most valuable engineering skill I find is the ability to say "I've run into a problem, I am not the first person to run into this, let me research how other people solved similar problems so I can understand my problem and it's edges better".
I'm pretty sure you'll get more than enough 90s, 80s or even earlier papers by searching "audio recognition", classification, etc...
Also, having studied math in the university and knowing where to lookup things when needed is one thing but demonstrating the knowledge on the blackboard during the interviews is another, especially if you're a mid-career professional and don't have a time nor willingness to allocate month(s) for preparation.
Yet if you look at the engineering team at a company like Shazam, I'd bet a small minority of them actually work on song fingerprinting.
Shazam is an app company. Most of the people there will be working on UIs, serving requests fast enough, integrating with partner APIs, and other standard software development where they never once need to feed audio packets into libfftw or whatever.
Your other comment seemed to suggest that you feel the Boeing model should apply here, and the people who don't work on the math-heavy product core should be considered technicians. Is that the right interpretation?
They also need a decent database to find the song from a five second sample occurring anywhere in the whole up to say 8 minute song, for their whole song library
In my experience this is where the ability to learn from literature would really help. In this specific case you’d encounter Fourier analysis pretty damn quickly if you started to read around the subject. Likewise whilst I think my formal teaching gave me a grounding I actually value the self-learning aspect from my degree more. The hard problems are the ones you’ve not heard the solution too before. The main thing a formal education provides is a leg up and hopefully a solid set of skills to help find answers to hard problems.
I can confirm that without specific education, reading around things like audio analysis and audio fingerprinting, Fourier comes up pretty quickly, and did before Shazam was a thing.
Honestly, I think tenacity and an ability to learn and move quickly are the most valuable engineering skills one can have.
The only place where I think this doesn't apply is within an extremely specialized space. I think that very few engineers of that type are generally necessary, though. At the same time, I'd imagine that if you do have the academic background for extreme specialization, you're probably going to be able to demand a pretty high paycheck.
How many people on the Shazam team needed to come up with the fourier analysis? How big was the Shazam team? What did the rest of them do?
This is my problem with only hiring comp-sci to build software and get stuff done. They all want to hire the John Carmacks of the world, but Doom would have never happened without John Romero. It's a waste of a PhD to spend it porting low level driver software from one architecture to another, but that type of work needs to be done, even by companies like Google.
And honestly, there's a difference between the high-level big-idea fancy stuff that Computer Science focuses on, and the low-level, details of implementing things correctly and performantly. They are not the same skills, but that's all been lumped together under this software engineering profession.
On the flip side here, though, once you have that ability it generalizes very well. My original educational background might be in biology, but I know how to read a technical computer science paper and where to find them. It means that I may not have knowledge intuitively, but I know where to find and learn it.
For all the responders who suggest this kind of thing can be picked up on the job by competent professionals, in my years at Boeing, I never saw a single tech pick up stress analysis, calculus, kinematics, heat transfer, dynamic analysis, etc., on their own. Not one. Frankly, I felt that was a crying shame.
Nearly everyone needs a structured environment and program to learn that stuff.
It is. Given the right environment (which might include coaches or teachers) it should be possible to pick up knowledge about stress analysis, kinematics, heat transfer, dynamic analysis on your own.
Calculus is a slightly different matter because it's indeed more foundational than the other areas you mentioned. Still, I think calculus can be learned without a formal education programme, too. After all, most of it has pretty obvious areas of application.
> job once of printing what was on the graphics screen on the printer.
I've had several variants of this, and the problem was not one of coordinate transform but either futzing with the API to actually get at the printer, or re-layout the items on the screen because transforming a 16:9 screen to a 1:1.6 piece of paper will look weird.
FA is the first thing that anyone who remotely googles for "identifying music technical implementation" pops up. The idea that someone couldn't figure this out on their own just because they didn't have rich parents who could afford to send them to some school is quite mistaken.
Put yourself in their shoes. You're you. You weren't sent to a school. What would you do to figure out the problem? Would you really hack around for years without success, or would you look up related material, read, study the problem, and check for existing solutions and scholarly articles on the topic? You know, all the things that a Real Engineer does.
And you'd get results quickly. Because you are a real engineer regardless of whether you went to a school.
I’d just like to add to all the people responding with “google didn’t exist back then” in the comments here, that libraries did exist. I found a great wealth of usable and applicable information in mathematical encyclopaedias, handbooks and software engineering books and journals (even 5 year old ones) in the public library where I live.
Let's say you did some research that suggested FA was the right solution. Now what? FA is not a freshman topic, it's a senior topic. You've got 3 years of math background you'd need to learn first to get to the point of being able to properly understand it (rather than blindly using it as a canned formula).
I'm speaking from experience. It's a generational gap, I think, which is why it's hard to understand. But it's true.
FA is using cosines up and down the spectrum to convert a set of samples (audio, image, etc) into a frequency spectrum (the magnitude associated with each cosine).
I didn't have to look that up. I just know it. And I'm no genius. This isn't nearly as difficult as it seems.
Especially because universities usually spoonfeed you information at an absurdly slow rate. There's value in that – I'd wager you could whip me if we have to bust out some paper and solve some integrals. But then again, I can just get a computer to do that hard work for me. I know what integrals mean and why they're useful, which is far more important than the rote memorization of techniques to solve them.
Now, if you want to argue that there are specializations that you can only learn in university, you'll get no disagreement from me. Distributed systems is a perfect example. On the other hand, I know those fundamentals too because I completed 6.824 on my own time. It's freely available.
And yeah, matrix math is a piece of cake too.
The world has simply changed. Information used to be valuable and guarded. Now all that matters is raw talent and motivation.
And credentials, sadly. But the world is slowly learning those aren't a great proxy for talent.
It's probably hard to empathize because you were well off enough to go to university. But you have to remember that intelligence is mostly genetic (probably), so talent can come from all walks of life. What would you have done if your parents had a massive divorce and someone squandered what little your family had? Are you sure you would have gotten a scholarship? When your parents never instilled the value of university into you from a young age?
> universities usually spoonfeed you information at an absurdly slow rate
I have to chuckle at that. I went to Caltech. A year of high school physics went by in about 4 lectures. I had to study about 40-50 hours a week just to keep from drowning. I would not have survived without help from the professors, TAs, and fellow students.
I don't disagree that a motivated, talented person can learn all that on their own. I've seen it happen, exactly once. The rest just employ ad-hoc hacky workarounds.
BTW, at the time Caltech had a specific policy that financial means would be no barrier to admission or attendance. They'd do what it took to make it work. I attended a very ordinary public high school in a working class neighborhood.
> matrix math is a piece of cake too.
But you have to know what it is to even recognize that it is the path to a solution.
Slow relative to learning the interesting bits. It took three years to get to FA? Seriously? That's a glacial pace relative to solving real world problems.
I agree you came out of it far better prepared, but drowning you in math for math's sake was merely hazing. Mostly.
Regarding your financial point: it's remarkable how hard it is for the upper echelon to empathize. It's not about the money. The money doesn't matter. It's the whole way of life leading up to college that kills you. The mindset. The motivations. The infighting. Being sent to some small religious school in the middle of nowhere because your dad thought religion was going to take over the world and it was super important for you to know a thing or two about god, then being tormented there because you're the only one in a school of 300 with an intellectual curiosity.
You think you would've stood a chance in an unfair fight? :)
Your mom and dad are owed a debt of gratitude. Family structure is the basis of power in life.
> glacial pace relative to solving real world problems / hazing
Sorry, I can't agree. My experience in post college real world problems was I was very well equipped to do so, compared with other newly minted engineers. And the techs who didn't have degrees weren't even on the radar.
> the only one
I was regularly assaulted in public school for being a nerd. Does that count?
> mom and dad
Mine were very special to me. But they were mine, and I'm heavily biased. Stepping back a bit, I don't believe they were exceptional, or better than the parents of my friends, etc.
> empathize
Get up and go comes from within, it is not installed by parents.
I wanted real bad to be a ham radio operator as a teen. I could not remotely afford to buy the equipment. I tried to build my own, but utterly lacked the skills, and could not get either the tools or the parts. Nobody helped me. I didn't know any hams, or anyone who knew anything about electronics. It was extremely frustrating.
For me, being at Caltech was very much like someone turning the lights on. I was around people with similar interests, classes were fun (despite being terrifyingly hard), lab equipment was all available, it was heaven. Nothing like public high school.
BTW, I was on partial financial aid from Caltech. They fronted me a loan, which I paid back after graduation. I'm sure they would have provided a full ride if my father couldn't pay anything.
It sounds like a self congratulatory post rationalization of the Google hiring process. People good at algorithms are not necessary to build what a huge chunk of Google engineers work on (basic CRUD apps). Additionally, being good at CS alone without software engineering knowledge results in crappy, untestable software with a poor user experience so CS knowledge isn't enough.
The best L6+ SWEs I worked with there were amazing due to their ability to distill requirements for complex products into sustainable software architectures. Other than the few groups working at the cutting edge of a CS field (<10% of SWEs), algorithms knowledge outside of complexity analysis (to avoid bad code) was essentially useless and software engineering was all that mattered.
Many employees at Google just defend the hiring process because they don't want to question the system that makes them feel superior to the hundreds of thousands that have applied over the years.
"Google doesn't build software, it advances computer science."
This hits on something that really bothered me in some of the Quora responses, particularly from those who had worked at Google: they smugness and superiority. In some ways, for some people, it could be well earned: someone took an idea from abstract concept to implemented algorithm and maybe even to a library or product and changed the world, to some degree.
Other software engineers, performing more mundane tasks, might also change the world. Howell's product certainly made a very positive difference for me and I leveraged this to get my own work done faster. I think we can all come up with many examples of software that's impacted our lives that doesn't revolve around a unique computer science discovery but instead, like Homebrew, solves a problem in a practical and accessible way.
This isn't in the text, but I am left with the feeling that software engineers who ended up (because life, etc.) working in less math-heavy roles are somehow inferior, and I just don't believe that. Working through BS level comp-sci coursework at a decent college is a significant achievement for those students, at that age, and should not be diminished. But to imply that those working in the field who have not had the good luck to have found interesting computer science problems to solve, who have instead worked at simply improving existing products or focusing on products that meet another need (i.e. accounting, communication, etc.) are not "really" software engineers is, in my opinion, going too far.
Back when I worked at Boeing, development teams were evenly split between technicians (draftsmen) and engineers. The latter had engineering degrees, the former didn't.
They often did exactly the same work. A lot of the techs were very, very good and had an excellent intuition about design and how things worked. But they got paid less for the same experience level, and sometimes grumbled about that.
The trouble was, sometimes intuition, experience, and high intelligence just wasn't enough - mathematics was needed, an ability to apply engineering principles to go beyond book solutions was required. And the techs were dead in the water on that, and that's where the engineers were needed.
I think Boeing's brilliance was realizing that both techs and engineers were needed to make a well-rounded team. Even the seating was engineer-tech-engineer-tech-engineer-tech to ensure that we worked together side by side.
I get that, if he applied to a particular compsci-heavy function... he's just not a good fit. That's fine.
But any HR department worth its salt has a good idea of the company's needs in general (i.e., the other 1000 functions that Google has), and could ascertain and recognise talents and strengths in Max, and find a fit.
The notion that, as Max puts it, 90% of Google employees and a significant fraction of developers worldwide use a technology you built, but that there's no fitting function for you at a large technology company with a highly diverse set of tech initiatives, is frankly ridiculous. There's obvious talent, drive, ability-to-deliver etc there.
> But any HR department worth its salt has a good idea of the company's needs in general (i.e., the other 1000 functions that Google has), and could ascertain and recognise talents and strengths in Max, and find a fit.
The more I read stories about hiring, the more I get the feel that all too often hiring people are preoccupied with trying to come up with reason -- any reason at all -- to reject a candidate. Instead of looking for talent to cultivate, they look out for "losers" to show the way out. They must be the bad applicants, and thus anyone who makes it through must be good, right? So clever, aren't we!
> They really do want computer scientists. The ability to figure out what to build isn’t valued all that highly, because that’s not fundamentally the responsibility of the software engineer
As a former Googler myself, I 100% endorse this analysis. Engineers at Google are well respected and have a fair amount of freedom along some axes, but UX/product decisions are not one of them. There are many engineers who enjoy working within those constraints. Ultimately, I decided that I wasn't one of them (which is why I'm no longer at Google).
Also, this at the end of Max's answer:
> I am often a dick, I am often difficult
...really wouldn't work well on most teams at Google. Google's culture has an allergic reaction to jerks, even brilliant jerks. On the whole I think this is a good thing, even if it selects against some highly capable people.
Google is a big company, and there is a lot of variance between teams. I don't think this is a great generalization.
I have only worked in one small area, but my intuition is that if you end up doing something that's very much a part of the public face of the company (say, a flagship mobile app), your experience will probably be similar to other product-driven app companies, where there are people who specialize in making product decisions and people who specialize in implementation. Whereas if you're down in the bowels of the infrastructure for transforming protobufs into cat videos, you may never meet a product manager for your whole career.
yeah, like gmail marking emails from people on the same business account as spam (for years) and account switching for google drive not working (for years) to name a few of my pet peeves.
Google does some great work, but their products are far from perfect, and many have been canned because they failed in the marketplace.
> a lot of companies have imitated Google's hiring process without ever stopping to consider whether it's right for them.
Truth be told, this is common across virtually all businesses, regardless of size and scope. Hiring is tough, since even the most well-meaning family oriented business doesn't want to put time+money into someone who isn't going to be a fit; at the same time, many employers aren't sure how to properly scope out what they want from an employee, and the end result is searching for "good ______ interview questions" and using those as the interview.
Taking the time to find out what you actually want instead of just "...the best!" is usually a better idea, but it also means taking a lot of time to really break down your needs first. I've seen interviews get past the last interview and to the final deliberation on the results only to have people arguing over the purpose of the position, which is pretty egregious in my mind.
I also imagine that it's certainly possible that at another time he may have been hired at a large behemoth like Google for another role, but by writing such a public letter, hiring him would be kind of silly now; the atmosphere is kind of poisoned.
1. The cautious engineer who joined a big corporation immediately after finishing university and who might change companies maybe once or twice in their whole careers. They never take risks, never get fired, achieve steady career progress, steady bonus every year, steady pay raises, steady promotions every couple of years, can spend hours learning algorithms, never having to spend any time to strategize their next negotiation or career move...
2. The risk-taking engineer who joined a startup straight after/before/during university and who went through companies like toilet paper for the first 10 years. Always directly exposed to market forces, ready to jump ship at any time; always keeping one eye on the lifeboat. Always looking for a big opportunity, willing to network hard, change countries, get exposure; do everything they can to stay independent of anyone else and completely self-reliant.
After finishing university, I started with path #2 but was exhausted after the first startup I joined failed so decided to try #1; unfortunately my past experience had made the corporate environment way too depressing for me. I just couldn't relate to the other employees there so I had to go back to path #2. It was difficult and painful but I got to build up my character and my confidence.
>> there are product decision makers who understand software and can feed work to the CS-focused engineering teams.
Their product "decision makers" aka marketing dept, have been terrible of late.
Google is really having a problem with new products, the only successful ones are one they bought that were created by software engineers not a marketing dept
Maybe Google needs to start hiring engineers that have the ability to figure out what to build and allow them to build it...
I’ve never worked at Google but my read on them is that they’re an algorithm company, not a product company. They tend to hire algorithm nerds and pass on folks who, like Max Howell, can design and build useful products. As a result, their core, algorithm based, functionality is successful, but they fail at new product design over and over, creating and retiring flawed products ad infinitum.
I did work at Google and, IMO, your analysis isn't that far from the truth. Plus every project is massively overstaffed on engineers and massively under-staffed on project and team managers, which is by design because, you know, SWEs at Google "don't like to be told what to do" and they will "organize themselves"...
And yet, Max Howell wouldn't see himself as a PM. Even if that would be where he could be the most help to Google! He'd want to be an engineer who makes up for his slight deficiencies in academic Computer Science with an excellent understanding of what Google's customers want.
Apologies to Max and Google if I misrepresented what you wanted out of this.
Example: Google Play Music doesn't even have basic "search inside my library" functionality. I work at a product obsessed startup now, and that lack of functionality is the type of thing we'd address very quickly. It feels like Google is content to stand up products that "work" whilst having very little regard for the end user experience. Maybe I'm wrong, but I've seen tons of people asking for basic functionality in their music platform, and the user base seems to be flatly ignored.
> Google Play Music doesn't even have basic "search inside my library" functionality.
Is this within some custom app that you've got? I'm a heavy user of Google Play Music to listen to my library across various locations, and I'm always searching inside my library!
I think this is a very important point that is not getting enough attention. Sure Google is enormously successful, but it's not clear that all the places they fail are a necessary part of building their success, and thus could still benefit from improvements.
they’re an algorithm company, not a product company. As a result, their core, algorithm based, functionality is successful, but they fail at new product design over and over, creating and retiring flawed products ad infinitum.
Interesting that this refusal to adapt still persists. After reading this article, I dug up my old (2006) rejection email from Google; and just as I remembered, it wasn't quite so nice. This is basically what it said:
"After careful review of your qualifications, we've determined that you have nothing. None of your skills are a match for anything at Google, and we don't foresee that changing any time in the near future. Good luck in your endeavors."
I'd applied as a technical writer.
Today I'm writing documentation at Intel for data scientists, engineers, and machine learning experts. Because guess what? Algorithms will get you only so far. Sometimes you don't need to add more engineers to solve a difficult problem, you just need better documentation.
Paraphrasing, but it doesn't matter. I'd applied because I admired it as a company that could help you find answers for pretty much anything. I wanted to be a part of that.
Yet clearly was it the intent of the email to inform me in a very specific way that they had scrutinized and deemed my skill set useless for "all" jobs at Google. They went out of their way to tell me that no jobs at Google would be a fit for my "experience and qualifications".
This was 2006 and it had IPO'd not long before. I'd been out of grad school for about two years at that point, and I knew that "growing" companies are supposed to need all kinds of people. It was baffling.
Long story short: this (and other) rejections rendered my self esteem pretty wrecked. This one though I look back to as the cruelest one and what more or less launched me into a pretty severe downward spiral that lasted about four years.
That Google is still (condescendingly) rejecting creative and intelligent people like Mr Howell for not fitting into their mold ... that is still baffling.
He seems like the kind of guy that would be set up to fail at such a giant corporation anyways. Especially if his peers would sneer at his lack of grasp abou comp sci. Getting shit done is not exactly what multi billion dollar enterprises are about. And making users happy is practically antithesis to googles MO. So I think they made the right call.
I’d rather Apple hire him and give him the resources to make a native MacOS package manager. If Apple are serious about Pro users, and their recent round table on the MacPro suggests they might be, then allowing researchers to easily install the tools they need is essential.
Let’s be real, nobody wants to use Homebrew. It just fills a niche for a tool that’s missing on MacOS. People use homebrew because they search “apt-get yum for Mac” and it’s the first thing that pops up.
In other words, the day that Apple bundles a native CLI package manager with macOS, nobody is going to stick with Homebrew for its amazing UI/UX.
I don’t think we should be praising this guy for being a usability mastermind. I think homebrew is successful because he was someone willing to do the grunt work of building an apt-get clone on Mac. Paradoxically this actually reflects poorly on him because a talented developer prefers to spend time on more intellectually stimulating projects, not grunt work.
Homebrew was not the first. There was Fink and MacPorts before it. I would guess it became prominent because of the UX? Sold my mac before Homebrew was around.
Homebrew, at the time, was the first to try and build against the libraries that came with MacOS. For a lot of packages this was a huge time saver as it would be compiling a third the amount of code that MacPorts was churning through.
Are you kidding? Homebrew is basically the first thing I install on OS X as a developer; nothing beats the simplicity of this tool, especially if you prefer to do actual work rather than messing around with compiling etc.
Yeah after enough projects and jobs, I think the morale and productivity cost of having people with whom are difficult to work is too high. Jerks breed resentment and destroy the motivation of others. Companies are about large organized groups of people accomplishing a goal larger than any given individual could accomplish by themself. Individuals who can’t cooperate with others are literally destroying a core aspect of any company.
Whilst I don't doubt that having the knowledge of an actual compsci education is valuable, because you're supposed to be able to build more than one product (and build it correctly), I don't think we should quote "really good things". Homebrew is quite popular and for the short time I used MacOS, I did like it, perhaps not as much as Linux package managers but better than anything Windows had to offer at that time.
Being smart and writing beautifully architectured software is also not something that sells. What sells is software people actually want to use. I often find myself focussing too much on the first part of getting a nice architecture, and in general writing nice code. But the UI/UX is the first thing people interact with and if that part is bad, the rest doesn't even matter anymore.
I realize this is not the case in every industry, but it's not something we can just consider 'worthless'. Homebrew does a fine job (as far as I could tell) of providing a decent user experience. Even if the internals would be pure spaghetti.
That said, I do think that at google you'd look for a balance of both, and they thought he didn't have enough knowledge about the underlying theory, which is a fine reason not to hire someone.
> Being smart and writing beautifully architectured software is also not something that sells.
Seeing how many people that use google products on a daily basis, I think you are mistaken.
> What sells is software people actually want to use.
Looking at app stores such as Steam, they sell a lot of software which is actually never used. So what sells is software that people want to buy. The using part is optional. Source: "Right now, I can tell you that about 37 percent of the roughly 781 million games registered to various Steam accounts haven’t even been loaded a single time." https://arstechnica.com/gaming/2014/04/introducing-steam-gau...
> Seeing how many people that use google products on a daily basis, I think you are mistaken.
I did add that I think google looks for a balance and was right not to hire him. I understand that their requirements are different from a lot of other companies. You probably overlooked that part and it might have seemed as if I thought it was unimportant at google, which I assure you is not the case. :-)
The second part is indeed a good point, there's a subtle difference and you are correct indeed!
> What sells is software people actually want to use.
That's one part of it and mostly b2c. The other part is well marketed software people have to use. Majority of people aren't exited about using office. Nobody wants to use windows. There may be a single lunatic who's excited about using an accounting package. Yet, more copies will be sold every day. And once they're established, their UI/UX can break in any possible way. The app sales won't slow down - training sales will go up.
> Being smart and writing beautifully architectured software is also not something that sells. What sells is software people actually want to use. I often find myself focussing too much on the first part of getting a nice architecture, and in general writing nice code. But the UI/UX is the first thing people interact with and if that part is bad, the rest doesn't even matter anymore.
It always baffles me that software engineers fail to understand that. The same people that doesn't do the same thing in other fields/products which is not related to software.
Maybe he's just being realistic? It's exhausting how people having their own opinions are labelled dicks lately, and conformist sheeple are called "good team players". Good teams need people who dare to disagree and question the status quo, because that validates internal ideas, making the results stronger, better implemented, more creative.
