I noticed with linkedin premium - when you view a job listing it tells you how many other people have applied akready, and what number of them have masters, bachelors, phd, director level, etc.

in this day, it should be a law that all the boards must post this info clearly - just to save us all a lot of time.

The amount of time I have spent putting info together for some job listings and wondered how in the heck they found someone else with the same experience and knowledge.. and to think, there may have been 1500 that applied before hand and literally none of that matters.

They have the data, they should have to post it.

How do you vet mid level and entry developers? I know that sounds like a dumb question. But I only expect a mid level developer especially enterprise developers to turn well defined requirements into code. The bar is especially low in the age of AI. One is basically interchangeable for another. I have only interviewed senior level developers - ie people who I expect to operate on a higher level of scope, impact and ambiguity.

Those are easy to filter out via a few behavioral questions.

Surely you will not manage to hire one of the top 20 developers matching any given criterion unless you are paying too 1% compensation. (I made this number up.)

One of the criteria somehow is “will show up for work and not ghost us”.

No affiliation but they talked with me long time ago. They take upon themselves to perform the first screening… looks like something smaller startups could take advantage of. I am not sure how good they are.

I also came to a similar endpoint when building out a fairy large GUI application using egui. While egui solves the "draw widgets" part of building out the application, inevitably I had to restructure my app entirely with a new architecture to make it maintainable. In many places the "immediate" nature of the GUI mutable editing the state was no longer an advantage. Not to mention that UI code I wrote 6 months ago became difficult to read, especially if there was advanced layout happening.

Ultimately I've boiled my choices down to:

- egui for practicality but you pay the price in architecture + styling

- iced for a nice architecture but you have to roll all your own widgets

- slint maybe one day once they make text rendering a higher priority but even then the architecture side is not solved for you either

- tauri/dioxus/electron if you're not a purist like me

- Rewind 20 years and use Qt/WPF/etc.

Anyways, not going to die on that hill and I'll keep using it because it's simple and works well for my needs. One thing I do like is that I am not having to constantly keep a skeleton CMake project around to copy paste and setup.

It supports this syntax.

https://xmake.io/guide/project-configuration/syntax-descript...

  target("foo", function ()
      set_kind("binary")
      add_files("src/*.cpp")
      add_defines("FOO")
  end)

    target("foo", {
      kind = "binary",
      files = { "src/*.cpp" },
      includedirs = { "src" },
      defines = { "FOO", "BAR=BAZ" },
    })

    target {
      name = "foo",
      kind = "binary",
      files = { "src/*.cpp" },
      includedirs = { "src" },
      defines = { "FOO", "BAR=BAZ" },
    }

    target("foo", {
      kind = "binary",
      files = { "src/*.cpp" },
      includedirs = { "src" },
      defines = { "FOO", "BAR=BAZ" },
    })

(I think there are technical and marketing reasons to be weary of as well, but the degree to which that matters is application specific. The above is universal and will probably continue to be the case through at least a few more major revisions if I had to guess).

The problem with LLMs is that it is not only the "irrelevant details" that are hallucinated. It is also "very relevant details" which either make the whole system inconsistent or full of security vulnerabilities.

But if it's security critical? You'd better be touching every single line of code and you'd better fully understand what each one does, what could go wrong in the wild, how the approach taken compares to best practices, and how an attacker might go about trying to exploit what you've authored. Anything less is negligence on your part.

Which seems like an apt analogy for software. I see people all the time who build systems and they don't care about the details. The results are always mediocre.

I think this is a major point people do not mention enough during these debates on "AI vs Developers": The business/stakeholder side is completely fine with average and mediocre solutions as long as those solutions are delivered quickly and priced competitively. They will gladly use a vibecoded solution if the solution kinda sorta mostly works. They don't care about security, performance or completeness... such things are to be handled when/if they reach the user/customer in significant numbers. So while we (the devs) are thinking back to all the instances we used gpt/grok/claude/.. and not seeing how the business could possibly arrive to our solutions just with AI and wihout us in the loop... the business doesn't know any of the details nor does it care. When it comes to anything IT related, your typical business doesn't know what it doesn't know, which makes it easy to fire employees/contractors for redundancy first (because we have AI now) and ask questions later (uhh... because we have AI now).

egui has served me well and is eagerly recommended in "what gui should I use" threads since it solves the widget problem well in an easy-to-use package. However, any sufficiently advanced application ends up needing a nice architecture to maintain development speed and enjoyment. I've found whether using egui/slint/fltk/etc. you end up having to roll your own system. When you start needing things like undo/redo you suspiciously start architecting something that smells like the elm architecture.

Iced is the only Rust toolkit that I track that solves the architecture part upfront. The message pattern is hugely powerful but it is hard to appreciate until you've really gotten in the weeds on larger applications. Once iced reaches a point where there is an advanced set of widgets available I suspect its popularity will rise accordingly.

As a comparison, one of the most successful desktop gui toolkit of all times (Qt Widgets) solved the architecture/widget duality long ago with the signal/slot system and advanced widgets like treeviews, datagrid, etc. Since then we must have had hundreds of "desktop" toolkits across all languages that can draw buttons and dropdowns but nobody has toppled the king yet for building advanced desktop GUIs (although there were a few close competitors in C# with WPF and Java with Swing they only solved the widget part in my opinion). I like to think iced can take this mantle one day, best of luck to them and congrats on the 0.14 release.

They contribute back but it’s a notable distinction.

That said, for actually building most apps, what's more important is likely ease of learning and using the framework, platform/OS support, publishing support, etc, none of which Iced itself directly address.

Well Iced itself claims to be inspired by the Elm Arch, so that checks out (see the first line under the Overview section of the Readme https://github.com/iced-rs/iced )