I mean, if we’re doing this, let’s be honest and go as far as mid-level engineers whose work needs constant correction, as well as the many, many senior engineers out there who are senior only because they lucked out in getting the title during the artificial dev scarcity of the ZIRP eras.
I never really bought in to the anti-Leetcode crowd’s sentiment that it’s irrelevant. It has always mattered as a competitive edge, against other job candidates if you’re an employee or the competition of you’re a company. It only looked irrelevant because opportunities were everywhere during ZIRP, but good times never last.
Most developers work at banks, insurance companies and other “enterprise” jobs. Even most developers at BigTech and who are working “at scale” are building on top of scalable infrastructure and aren’t worrying about reversing a btree on a whiteboard.
Agree that the whiteboard thing is often not applicable but it's so nice when a developer has efficient code if only because it indicates that they know what's going on and also that there are fewer bugs and other bottlenecks in the system.
Those bugs don’t come from using the wrong algorithm, they come from not understanding the business case of what you’re writing. Most performance issues in the real world for most cases don’t have anything to do with the code. It’s networking, databases, etc.
Your login isn’t slow because the developer couldn’t do leetcode
No, it's because 50k reads of settings are happening with a SQL Table in memory that's queried via SQL statement instead of a key/value hashtable. (real world experience, I think it was close to 28k reads, but the point stands)
The ones I've thought of, and the one's you've thought of, and the ones Ancalagon has in their mind are three partially disjoint sets, but there's probably some intersection, which we can then use as a point of discussion. Given that "serious code" isn't a rigorously defined industry term, maybe you could be less rude?
I mean, are you gonna die on a hill defending every low-quality content in HN? Because I think it’s perfectly OK to call it out so that moderators can notice and improve. You seem to think that readers have an inherent responsibility to salvage someone else’s bad article.
This article is talking about the AI race as if it’s over when it’s only started. And really, an opinion of the entire market based on a few reddit posts?
Author spoke of compounding moats, yet Apple’s market share, highly performant custom silicon, and capital reserves just flew over his head. HN can have better articles to discuss AI with than this myopic hot take.
> This means you've learned to work around its shortcomings.
All software of comparable size and complexity have shortcomings that everyone learns to work around. And a great many of those shortcomings are actually just highly subjective personal preferences. More than half of the complaints in this thread are, to me, a terrible idea.
> All software of comparable size and complexity have shortcomings that everyone learns to work around.
This is part of the issue IMO. Is this size and complexity warranted?
Rust for example; its a complex language, can target pretty much all platforms under the sun, and yet it's configured with just text files, builds with just terminal commands, and works great with any text editor.
I've seen people in big tech work on codebases millions of files big with everything from VSCode to a russian text editor from the 90s. Linus Trovalds is building Linux with MicroEMACS. Why do I need a behemoth like Xcode to build a To Do app? Why does it have to be this "big and complex"?
Xcode isn't necessarily the problem. Some people like it. That's fine. But apple forces it's use for iOS development. There are workarounds like Tuist, but you are still locked into Xcode for debugging, instruments, and even console output from an iOS device!
Nobody is saying not to use Xcode if you like it, but there should be a choice like there is for almost every other modern platform.
The big part of Xcode is the integrated Interface Builder. With SwiftUI it might slowly become irrelevant, but as of now, there's still no replacement for Xcode's Interface Builder. JetBrains' AppCode is/was a decent replacement for the code editor, but you still had to switch to Xcode for the UI parts.
Practical answer? I don’t know, man. I’m just building a todo list after all. Heck, I build more complex apps than that but front-end work is at such a high level of abstraction that, realistically, I just never bother. I don’t mind a smaller download size, but it’s just a nice-to-have.
The point about Xcode being complex, I disagree with. Honestly I could think of so many additional features to make my workflow easier.
I agree, but I think that it's difficult to spot memory leaks in SwiftUI because it's such a high-level abstraction framework. When working with the Cocoa and Cocoa Touch libraries, it's so much easier to find.
And of course, Apple's UI frameworks != Swift the language itself.
Have you been nothing more than a junior contributor all this time? Because as you mature professionally your knowledge of the system should also be growing
It seems to me that now days software engineers move a lot more. Either within a company or to other companies. Furthermore, companies do not seem to care and they are always stuck on a learning loop where engineers are competent enough to make modifications and able to add new code but without deep insights where they can improve the fundamental abstractions of the system. Meanwhile even seniors with 25+ years of experience are noobs when they approaching a new system.
"Current business conditions or issues" -- I think that's because OP wants you to fill that in yourself, so that you might explain your assumptions or the market potential that you see, which might be wildly different from his (i.e. software having little to no moat)
reply