Everything I do for macOS/iOS is already without Xcode but it's a pain in the ass to keep up with changes, and there are things I haven't figured out yet (like AUv3).
I feel like this needs a big asterisk. Can you ship a a non-trivial iOS or Mac app that uses SwiftUI or other first-party APIs without Xcode? Is it practical? Those are real questions, some cursory searching did not turn up a concrete answer.
> They want "computer, plan my next vacation to XYZ for me" to lay out a full itinerary and offer to buy the tickets and make the reservations.
Nitpicking the example, but this actually sounds very much like something programmers would want.
Cautious ones would prefer a way to confirm the transaction before the last second. But IMO that goes for anyone, not just programmers.
Also I get the feeling the interest in "computers" is 50/50 for developers. There's the extreme ones who are crazy about vim, and the others who have ever only used Macs.
Not advocating that people should follow this but:
As someone that loves cleaning up code, I'm actually asking the vibe coders in the team (designer, PM and SEO guy) to just give me small PRs and then I clean up instead of reviewing. I know they will just put the text back in code anyway, so it's less work for me to refactor it.
With a caveat: if they give me >1000 lines or too many features in the same PR, I ask them to reduce the scope, sometimes to start from scratch.
And I also started doing this with another engineer: no review cycle, we just clean up each other's code and merge.
I'm honestly surprised at how much I prefer this to the traditional structure of code reviews.
Additionally, I don't have to follow Jira tickets with lengthy SEO specs or "please change this according to Figma". They just the changes themselves and we go on with our lives.
Favorited. I was talking to someone (non-dev) yesterday who prototypes with Claude and then goes back/forth with the lead engineer to clean it up and make it production worthy (or at least more robust). I like that model.
The JVM has been extremely fast for a long long time now. Even Javascript is really fast, and if you really need performance there’s also others in the same performance class like C#, Rust, Go.
Hot take, but: Performance hasn’t been a major factor in choosing C or C++ for almost two decades now.
I think it is the perception of performance instead of the actual performance, also that C/C++ encroaches on “close to the metal” assembly for many applications. (E.g. when I think how much C moves the stack pointer around meaninglessly in my AVR-8 programs it drives me nuts but AVR-8 has a hard limit and C programs are portable to the much faster ESP32 and ARM.
A while back when my son was playing Chess I wrote a chess engine in Python and then tried to make a better one in Java which could respect time control, it was not hard to make the main search routine work without allocating memory but I tried to do transposition tables with Java objects it made the engine slower, not faster. I could have implemented them with off-heap memory but around that time my son switched from Chess to guitar so I started thinks about audio processing instead.
The Rust vs Java comparison is also pointed. I was excited about Rust the same way I was excited about cyclone when it came out but seeing people struggle with async is painful for me to watch and makes it look like the whole idea doesn’t really work when you get away from what you can do with stack allocation. People think they can’t live with Java’s GC pauses.
Is having problematic features that causes problems also a requirement?
The answer to the above question will reveal if someone an engineer or a electrician/plumber/code monkey.
In virtually every other engineering discipline engineers have a very prominent seat at the table, and the opposite is only true in very corrupt situations.
Interesting. I have worked with a CEO that did exactly that.
The product quality was just insane.
I have also worked with people in power who believed they were doing the same, but actually just had weird taste in interfaces and ended up screwing up the product.
> One caveat: squash-merge workflows compress authorship. If the team squashes every PR into a single commit, this output reflects who merged, not who wrote. Worth asking about the merge strategy before drawing conclusions.
In my experience, when the team doesn't squash, this will reflect the messiest members of the team.
The top committer on the repository I maintain has 8x more commits than the second one. They were fired before I joined and nobody even remembers what they did. Git itself says: not much, just changing the same few files over and over.
Of course if nobody is making a mess in their own commits, this is not an issue. But if they are, squash can be quite more truthful.
It’s like a children or a puppy. People get impressed and go “how cute” at anything it does.
I see designers and PMs vibe coding shit that they would complain for days if it was delivered by a developer. I see C-Levels delivering reports that would make them eviscerate some intern.
Everything I do for macOS/iOS is already without Xcode but it's a pain in the ass to keep up with changes, and there are things I haven't figured out yet (like AUv3).
reply