That is exactly my current employer. Our main office is in a small town, so there aren’t that many candidates to begin with (a job stays open for 6–9 months and we get maybe 15 applicants during that time)

Our software is utter trash because the business is very clannish, fragmented, and the people in charge either never ever wrote code or did it 15 years ago.

And yet we fail 95% of the technical candidates we interview because they don’t meet our “high” standards. We won’t even consider hiring remotely (but within the country because we’re making government software) even though an overwhelming majority of the company and tech team has been working from home 80–100% since March... No, we’re insisting on rejecting the handful of candidates that apply in our small town. Insane.

>Doing a good job requires extensive, encyclopedic, knowledge of what's out there

I wouldn't say that. What I feel like I've accumulated in knowledge over time is I can look at a new problem and without having the solution/encyclopedic knowledge, I can know in my gut that (a) there is a solution, and (b) the solution I'm looking at is not the solution.

Merely being able to look up things on the internet without these two things means you will either give up too early or settle on the wrong solution.

This is the most succinct way I can describe what I think >a decade of experience is worth compared to being fresh out of college.

I describe this as known-unknown vs unknown-unknown (credit to Donald Rumsfeld)

Unknown unknowns: The things that you don't know are possible and thus don't even know how to start solving. You will accidentally reinvent the wheel, most likely very badly. Or give up right away.

Known unknowns: An experienced developer most likely unconsciously knows (has read on HN/Reddit/Book/Blog some time in the last 20 years) that a thing they encounter has been solved already, at least partially.

This allows them to start searching for the answer with a few key words, because they know it's possible but don't know how it can be done.

Same comes with having a network of people who know different things, I know the bare minimum about professional pentesting, but I know a few people who I are absolute pros in the field.

> Known unknowns: An experienced developer most likely unconsciously knows (has read on HN/Reddit/Book/Blog some time in the last 20 years) that a thing they encounter has been solved already, at least partially.

I feel like my brain is full of "I read a headline about this once" tidbits, in part because of HN. It's like I don't know the answer, but I know the question has been solved before so I know there is an answer.

Yup, a lot of developers grow into generalists that know a lot of things about a wide range of subjects; they suck in a technical / algorithm interview, but they can solve most problems. They may not know all of NPM's options (for example), but they know how to quickly find an answer if they are confronted with a problem.

>>This business of high stakes quiz questions serves just one purpose: feeding the ego of the interviewer. "We have high standards!"

It's scary how true this is. I know one manager who routinely rejects perfectly good candidates for making negligible mistakes in the interview. All on the grounds of "We have high standards!"

Haha. I worked at a place that did not start out as a software company but now had a software team (they built industrial machinery). The director of the electrical and software department was completely clueless of course. He insisted that since we are an engineering company, an engineering degree was required to work here. And that meant any candidate for a software engineering position was automatically rejected if they only had a computer science degree since it didn't have the word "engineering" in the title.

It sounds like the process works! … at preserving the candidate from your organization. :)

I honestly don't agree with this. The worst programs are written by people who know how to plug a million and one things together, but can't drill down and analyse the algorithmic implications of what they're doing. Electron runs like shit and inhales RAM is because it was programmed by people who don't have solid understanding of fundamentals. They understand a huge number of horizontal abstractions but they have no concept of how it looks vertically.

Knowing how to maximally exploit a CPU is way more important than knowing eight different Javascript frameworks if good software is your objective. And frankly, learning Node is way easier than figuring out how to structure basic, bare-bones Javascript so that it leverages your L1 cache.

And therein lies the problem. How many interviewers dock marks for iterating over columns, instead of rows? Because that matters, a huge amount. How many interviewers would give credit for "how can you speed this up?" if the interviewee said, "write it in C, and simplify the datastructures you want me to use so we maximise sequential lookups over basic arrays, to maximise cache usage." They'll look at you like you have three heads.

"Don't you know Big N complexity is the only thing that really matters if you're looking for speed?" - then you get Electron.

> Electron runs like shit and inhales RAM is because it was programmed by people who don't have solid understanding of fundamentals.

I feel like this is a huge oversimplification. I’d argue that for sufficiently large projects (say, Chromium) every single programmer who works on it could have a strong understanding of performance fundamentals but the product itself could still have performance problems because there are necessary levels of abstraction involved and no one person has the entire codebase in their head. Performance problems could come from emergent behavior that could not have been predicted by the original engineers.

But, as for implementing an app on top of Electron. Say I need to write a cross-platform app with a consistent style and fluid animations. I know how to write a NEON implementation for ChaCha20 for fun, or write a zero-copy binary property list parser that’s faster than anything I’ve found. I have a decent understanding of performance. That doesn’t help me write this cross-platform app. I don’t have to time to write a novel native UI toolkit that allows me to share code while maintaining platform consistency and native performance. I don’t have time to fix the memory consumption of Chromium. I’m going to write my Electron app in JavaScript, carefully, and hope the performance will be acceptable (but not great). I don’t see how that can reflect on any individual programmer poorly.

I disagree. As evidence: games are way more complex, have enormous teams, and manage to simulate an entire game world rendering render hundreds of thousands of polygons 60 times every second. Twitter crashes my browser.

But I don't think that it has _anything_ to do with the individual programmers inherently understanding performance better.

There is likely a huge organizational focus on performance and more people expressly dedicated to the task because it is a higher priority for Epic. It is directly correlated to Epic's ability to deliver a successful product to game companies, whereas for browsers it is slightly more orthogonal to their success.

LLVM has a bunch of contributors who likely understand the intricacies of machine code better than either of us, and:

> Each LLVM release is a few percent slower than the last.

> The larger problem is that LLVM simply does not track compile-time regressions. While LNT tracks run-time performance over time, the same is not being done for compile-time or memory usage. The end result is that patches introduce unintentional compile-time regressions that go unnoticed, and can no longer be easily identified by the time the next release rolls out.

https://nikic.github.io/2020/05/10/Make-LLVM-fast-again.html

Electron is a running joke because of how horrible the performance is. Again, I don't buy it. I think it's much more a matter of "they can't" than "they don't want to."

I think if those LLVM contributors understood compilers better, they wouldn't be introducing those issues. Look at Jon Blow's achievements on Jai. LLVM is the bottleneck for his entire compiler at the moment, and he's planning to replace it with what... Three people or something? But I also think there are structural issues there. I don't think a top-down project from a large company gets to use that excuse.

That's because GPUs are insane and purpose built. For an honest benchmark, you'd only look at instructions executed on the CPU which won't be any rendering, but stuff like world ops, AI, game flow. Some of those are not really that taxing.

As an example, Stellaris had performance issues that were CPU bound for a while and it's gotten better. It's not a visually demanding game after all.

So run Electron like a game. Leverage the GPU, if that really is the issue. Or run it like Qt, which manages to avoid that problem.

I just think that's a weak excuse, especially given most games have tremendous complexity running through the CPU too.

(As a side note I don't think paradox games are a good example. They're famously poorly optimised.)

Think about the requirements for market success of the different pieces of software. Games most run fast and any performance you safe can go back into better graphics. Performance is crucial. Electron is hugely successful despite not being very performant.

Developers love thinking about performance. It's fun and asked us to use so many of our skills. However, for many products other quality aspects are more important, like maintainability, extendability and expediency of development.

That performance often falls by the wayside on terms of business priorities ends up being reflected in the typical developer skill set.

I don't know if I agree. Its plausible, but also these businesses are monopolies, so even if they churn out shit it doesn't undermine their market position.

But I think Electron in particular is a symptom of the fact that GUI frameworks are in general horrible. There was a market gap for usability because using everything else was obtuse, and now we're paying for it.

Which businesses are monopolies? Slack surely isn't. If there's a market for faster chat clients because that's what people want then looks like a business opportunity?

FWIW all of slack competitors are also electron (rocket.chat et all), so it seems like you possibly know something that other engineers don't and might have a competitive advantage!

Google is a monopoly.

If someone released a GPU-accelerated version of Electron that had the performance of the GUI in basically every video game, it would destroy Electron. Now, would it be popular? I'm not sure, but let's say the answer is no. Ok, now imagine Google released that.

The likelihood that people who created Electron don't understand caches or cache locality is close to zero. That's an oversimplification. Electron is a large project that does many things… there are many reasons why it could have been slow. Today there are many Electron based apps that are quite decent.

> Knowing how to maximally exploit a CPU is way more important than knowing eight different Javascript frameworks if good software is your objective. And frankly, learning Node is way easier than figuring out how to structure basic, bare-bones Javascript so that it leverages your L1 cache.

Learning Node isn't easier than learning how to structure basic, bare-bones code that leverages L1 cache. In fact, it's quite the opposite. You can learn cache locality as a concept in much less time than you would learn Node (or any programming ecosystem for that matter).

I don't buy it. Unreal Engine is a larger project that does many more things, and the speed at which it does them compared to Electron is not even in the same universe.

How can you compare unreal engine with electron ?! That makes no sense at all.

The fact that people think they're somehow fundamentally incomparable is the problem.

Seriously. This whole part of the comment tree has been fabulously enlightening. Great insight into the psychology of how we end up with chat clients that do less with 20x the resources than entire operating system + office suites of yesteryear.

I feel you tried to be snarky and I didn't really follow even what you tried to imply! Regardless would like to have your opinion if you don't mind explaining it better.

I’d figured it was mostly cheap companies driving the broadly terrible performance of modern software for often fairly small benefits to speed and dev cost, but it turns out there’s a much stronger contingent of software developers with not just a tolerance for business-driven trade-offs, but a strongly enabling attitude toward the whole thing, apparently not seeing what they’re doing the same way I do at all. Adding this information, observed software quality makes a lot more sense to me now.

I'm not sure it's the cheap companies or developers driving this. Even companies that pay really well produce pretty slow software (Gmail, etc.). It's mostly the ecosystem in which software is developed.

As someone else said, businesses hire software engineers to solve business problems. Speed often isn't a priority. Fast software will make the experience perceivably better, but it's hard to get on a sales call and tell a potential customer that your application loads much faster when they are looking for feature X. And most companies buying software are looking at a checklist of features first and then maybe the experience.

You also need to put in the time to make software fast and then keep it fast. It's not something you can tack on at the end—if you want something to be fast, that has to be carefully considered from the very beginning. By the time people notice something is too slow, you're burdened by half baked architecture and a monstrosity of a codebase. At that point, it's near impossible to really make anything fast.

> most companies buying software are looking at a checklist of features first and then maybe the experience.

I think the hugely successful SalesForce proves this point. Just one standout among many such products.

I would argue they won because of marketing, not because they had unique functionality. Features are not that hard to build, most basic tooling can be cloned with a relatively small budget.

Most enterprise businesses win because of better sales and distribution, but your product ultimately has to support your sales. Salesforce had both (and other advantages). How does sales work in medium to large B2B? You'll get a RFP with a list of questions, you'll often get a list of features that company X wants. Naturally, as a company, you'd focus on building those features instead of optimising speed.

If the market values fast software, you'll see a lot more fast software. There _is_ a lot of unnecessarily slow software these days, so it _is_ starting to happen. Think Superhuman, Linear.app, etc. — an entire category of software based primarily on the idea of being fast, aimed at the power user. If these apps succeed, you'll see a lot more of them. If the market doesn't value fast software, most commercial software will be slow.

I don't really agree with the premise. Sales by definition exploits the fact that the consumer can't differentiate between products on their own. That leaves a lot of leeway for broken software and misleading marketing.

I don't think companies choose to make bad software as a tradeoff. Salesforce had enough budget to build out those features and not be terrible. I think in general, when software is bad it's because the company wasn't able to make it good. And I think the distinction between those categories is important.

SalesForce ticks enough checkboxes. Competing products may tick the boxes too, but without great marketing that won’t matter, the company that can sell their product will win.

My point was that SalesForce has fairly poor user experience and performance, but does offer the features. It has the additional advantage (for SalesForce) or quick lock-in once the customer commits to it. SalesForce has improved the user experience over time because they have the customer base and revenue to allow that.

Software developers are hired by business to solve business problems.

Optimization of speed is sometimes it, sometimes it isn't.

I have worked accelerating algorithms in VHDL with a PCI-e interface, embedded linux without a MMU because a MMU uses too many logical gates, digital signal processing systems (FFT, goertzel, sigma delta filters) that had to process a lot of data under uS and etc.

Now a days I work more in the devops space, full stack dev and whatnot. I have worked with a lot of technologies, different constraints, different teams, different companies (12 in total) in different industries.

Trying to paint all business and developers as bad or as cheap because business requirements do not align with your view isn't really fair.

Twitter failing to load on a stable connection and crashing the browser if you scroll too far is not the result of business tradeoffs. It's a failure to achieve their own goals.

Are you sure there's not something wrong with your environment? Twitter has lots of users (me included) and is not a problem I have seen in any platform I access twitter from.

I also hit errors following links to twitter more often than not, reliably, on all sorts of environments. It feels like they’re doing some kind of cache-related routing based on headers. Often “refresh” doesn’t fix it, but hitting enter in the address bar does. Seen on iOS, macOS, Windows, and Linux, mostly in very normal browsers (I’d expect mobile Safari in particular is at least on their top-5 most-seen browsers). I’d assumed they were trying to annoy me enough that I install their app. I’ve seen many others report the same kind of reliable, very frequent errors.

Notably, I’m also not logged in, which might be another thing they’re trying to get me to do and another difference between those who hit this more often than not, and those who rarely or never see it. It’s been like this for years.

That sucks! I heard reddit also does things differently when you're logged in/ logged off. I haven't had a bad experience with these platforms myself but it sucks that it is so bad for other people.

The page loading thing used to happen to me regardless of login status, but it's less frequent now. The crashing was mostly just on mobile - that's still a problem.

If I remember right the app would also crash but it could take bigger loads. Not sure, I uninstalled it.

> Trying to paint all business and developers as bad or as cheap because business requirements do not align with your view isn't really fair.

Yes, that would be unfair.

Software is all about trade offs. I would actually recommend you the book Software Engineer at Google since you mentioned them so many times: https://www.amazon.ca/Software-Engineering-Google-Lessons-Pr...

The first chapter is all about that and how software engineer isn't programming. You seem to think as programming and I believe you're missing the bigger picture.

I understand what you're getting at but I think you're seriously underestimating the implications of what I said.

> Electron runs like shit

Does it? I've seen some electron apps that run like dogs, and others that seem perfectly performant. So, I'm curious... in what way does the framework run like shit? In what way could it be improved?

> How many interviewers dock marks for iterating over columns, instead of rows? Because that matters, a huge amount.

I think you mean the difference between SoA and AoS. I'm not sure that one is inherently better than the other, except the former scales well for large homogenous datasets.

I doubt optimising for DSPs/SIMD/big-data to maximize throughput and reduce cache-misses, is something the typical FAANG employee needs to know about. Could be wrong.

> "Don't you know Big N complexity is the only thing that really matters if you're looking for speed?"

It does, even if you cache-align and pool your data. And you can optimise your in-memory data-structures (and database IO) later, if profiling finds them to be a bottleneck.

>I've seen some electron apps that run like dogs

And almost no Qt apps run like that. "As long as I don't notice it most of the time, it's not slow." No, sorry, I don't agree. Frameworks should be fast. Slack is unforgivably slow.

>I think you mean the difference between SoA and AoS.

I mean literally in the interview when they do a nested for loop over primitives. Do they lose marks for going row-first? Why isn't that considered a basic rule? It's not complicated. Most interviewers don't even realise there's a difference (!!).

>I doubt optimising for DSPs/SIMD/big-data to maximize throughput and reduce cache-misses, is something the typical FAANG employee needs to know about.

Twitter is so bad it crashes my browser. It's 90% text! The only ram-hogs are auto-playing videos that dissapear after you scroll past them. These engineers are paid half a million per year. Half the time the website doesn't even load (!!!). That's insane.

>And you can optimise your in-memory data-structures (and database IO) later

Ehh, skeptical. Unless your data & algorithms are structured as contiguous arrays of primitives to begin with you're going to have trouble refactoring the abstraction.

> Do they lose marks for going row-first?

It's not objectively wrong to do this. Suggesting that "SoA is always right", tells me that maybe you don't understand the trade-offs between expediency, readability and performance... or understand the trap of early optimisation. Always measure first before optimising, otherwise write code that's easier to read, and simpler to write.

> Twitter is so bad it crashes my browser. It's 90% text!

Not sure how knowing how to micro-optimise cache-effects fixes these issues. Profiling and spending time on perf does, but they've decided it's just not worth their time.

> Ehh, skeptical. Unless your data & algorithms are structured as contiguous arrays of primitives to begin with you're going to have trouble refactoring the abstraction.

The keyword is refactor. Developers and organizations do it all the time - or at least they ought to.

Disclaimer: Used to work in the video games industry. Literally worked for years doing perf, and cache-level optimisation.

You're responding to things I didn't say.

No, I don't mean SoA, I just said that.

I don't think twitter is crappy because of cache misses, I think it's crappy because they don't have a solid understanding of what their code is doing. Ignorance of caching is another symptom.

If you build your game on an entity-component system, you can't "just refractor" that to make it contiguous. Your structure is pretty baked.

> I don't think twitter is crappy because of cache misses, I think it's crappy because they don't have a solid understanding of what their code is doing.

It's my hunch that you have little idea of what the code-bases for twitter are like, nor what factors are at play that affect usability issues.

> If you build your game on an entity-component system, you can't "just refractor" that to make it contiguous.

Moving to object pooling of components is very do-able. There might be some extra work, like extracting a generic matrix hierarchy and physics primitives out, but you'd only do such a thing if you found that d-cache misses on v-table lookups, or if i-cache misses due to update code churning were of real concern... and these could realistically be mitigated with homogenised object pools for the particular use case... though usually yes.

Edit: I'd expect anyone on an engine team, or technical programmers at a game dev shop, or maybe even someone working on a browser renderer to have such knowledge from day 0, rather than the average FAANG employee.

FWIW I work in a place which uses a lot of C++ and cares a lot about performance.

I have seen a lot of really bad Qt UIs as far as responsiviness. The Signal/SLot framework can get really hard to follow in huge code bases with lots of state. The whole thread interaction in Qt is not ideal.

It is interesting because most of people are now actually using PyQT or pyside. Even with these being slower than pure Qt. Because it is easier to adjust to business requirements with Python.

Oh, and I have personally rewritten some of these UIs in React and replaced them with a web browser which made them much more responsive.

> Half the time the website doesn't even load (!!!). That's insane.

I’d assumed Twitter showing me “an error occurred” on about 50-75% of inbound link-follows to their site, across multiple browsers on multiple operating systems, was an intentional “feature” to drive me to their app.

It's a deliberate business tradeoff.

Performance matters when it matters. Part of the job is knowing when it matters and adjusting the approach accordingly.

Efficiency automatically matters for something like Electron because if it's not well-engineered, it will produce monstrosities like Slack.

If Slack was written in Qt with the same budget it would just be fast. Even with effort we don't have Qt apps that behave like Slack.

If slack were built in Qt it wouldn’t ever have hit the market or adapt to changes. It would be an order of magnitude more expensive too.

Do you feel that you somehow know something that nobody else knows ? It’s all about trade offs . Being able to move quicker seems more important to businesses than writing more performant software .

It's a chat client, it's really not complicated. Even if we take for granted that they genuinely had to ride on top of Electron to get to market (I think the back-end is probably much more complex), they have more than enough money at this point to rewrite from scratch.

Note that one person is literally doing that, with ripcord. Looks like shit but it illustrates the point.

It is really that complicated. They have a lot of features, integrations and platforms. I don't believe you understand how a chat client code base could be much more complex than Unreal.

Every multiplayer game on the market does 90% of what Slack does as a side note.

Can you give me one that integrates to all my business ?

Monitoring , metrics , deployment , etc.

I am also looking to play said game on all platforms ! iPad , Android , iPhone , Mac , Linux , Windows and etc.

Would be great if the chat client supported markdown as well

I understand the point you're trying to make but arguing that World of Warcraft is less complex than the Slack client is not the hill to die on.

From your posts your view of complexity seems very limited to the art of programming and making complex, fast and correct programs.

Complexity for me is the software engineering part which the Software Engineering at Google displays really well and I agree wholehearted. I would argue a game is simpler because it doesn't need frequent updates and doesn't live forever.

I work in systems at my company used in a very big scale that were written 30 years ago and are still maintained / changed. That system I would argue is much more complex than any game.

Even tho from your point of view it probably only updates files on disk :)

just here to say that vscode works plenty fine on electron and has handily beat out other IDE's you might consider better software. it's always possible to use a tool badly but it's not always the fault of the tool.

As someone who uses Emacs (which is a terrible piece of software in its own right), looking at the top feature requests for VS Code is like looking into the twilight zone. It lacks absurdly basic functionality.

Granted, they made Electron run fast enough to be usable but I wouldn't call it good software.

It might lack functionality that you use on a daily basis, but I don't think it lacks any objectively basic functionality. In my opinion this is proven by the fact that thousands (millions?) of programmers, including me, work with VS Code on a daily basis.

What's the alternative? All editors are kind of crap. Compare them to raw level of engineering you find in, say, a video game. It's a different world.

Imagine VS Code was exactly how it is now, but had the extensibility of Emacs. It would blow everything else out of the water. Why isn't it like that?

The extensibility of emacs is insane is why, it really is more like an OS that happens to have editor functionality. I think the only thing that even gets close is Eclipse which has a ton of performance issues which I'm convinced are due to the (enterprise-y) way they try to achieve that extensibility. After that would be the IntelliJ platform, it's usually much faster and nicer to use but also has performance issues and is known for using a ton of RAM.

VS Code is doing well here compared to its competition. It is quite extensible, you can add extensions to it written in JavaScript that can add new UI and make changes to the editor view. It's also much more performant than either of the other two IDEs I mentioned, even after you load it up with extensions to replicate some of the most used features from those IDEs.

> Why isn't it like that?

Because most of us don't care. I need my code editor to just work out of the box. I want to be able to write code and install a few plugins to enhance the tools I'm using. Hacking my editor is a waste of my time and even if I wanted to, I'm certainly not going to learn lisp to do it.

Sublime Text is nice if you care about good engineering and performance.

your definition of good software here reminds me of the critic in Ratatouille who loves food so much he doesn't eat any of it. must be terrible living in a world where everything sucks as badly as you perceive it.

Hacker News, which is literally just text, can't display every comment in this post. There's a disclaimer at the top. Scroll up and read it.

How much money does the Y Combinator Web team receive? Do you think its enough that they should be able to render... Text?

This might be off topic, but what basic functionality does Emacs have that VS code doesn't? I know there's SLIME and Org, but I don't think you meant that.

Difficult to answer directly, but scanning through the most popular feature requests, most of the non-VSCode-specific feature requests have been solved (somewhere) by Emacs:

https://github.com/Microsoft/vscode/issues?q=is%3Aopen+is%3A...

I will say that this was way worse a couple of years ago. They seem to have added a lot since then.

> Knowing how to maximally exploit a CPU is way more important than knowing eight different Javascript frameworks if good software is your objective

Which is why 90% of all software is very profitable crap.