I have been feeling more and more tired recently. For a while, I didn't really understand why, given that with AI tools i code, so I thought of it as unusual.
Then I realized that is the actual cause. I don't vibe code, I care how the code looks like, so i read and understand most of it, fix it, review it, etc.
but the amount of code I go through in a day is astonishing, that creates the problem for me.
I haven’t gained much productivity by using any of the LLMs, particularly not the recent ones as their thinking ability is nothing else than overthinking and overcomplicating everything.
What I really use LLMs for is to uncover what I should not do, and this is quite a strong win.
Overall, they are generally very bad at giving me anything useful for the things I build.
One of the problems I encountered in my career was to understand the actual need. You have that entirely.
AI coming in and giving you the ability to do what you and others need and most devs couldn't do without you explainin the need and requirement in detail, is pretty amazing.
Maybe you teach this to some non-dev peers of yours?
I tend to use same structure (in html) and use css for making it brand specific. I built something that makes this easier for me, basically it takes a couple minutes to set something up with a lor of things prestyled.
What I am suggesting, I guess, is use some similar approach for you sue cases. Craft one, or pick one, see if ou can reuse the structure then reconfigure the branding part with some css lib (maybe pico? https://picocss.com)
I quite like the simplicity but I am especially a big fan of the standards-based development model. Will definitely try it out soonish and come back to you with some feedback.
It has a richest std lib with quite good performance which makes it suitable for a lot of use cases where one wants to reduce dependency. I also find it quite easy to learn. Personally use for all web products I build as I have gotten the hang of it and have a small sort of framework to build products quickly with. And I get to ship a single binary to production.
A headless OS came to mind immediately when I was reading your post. Let me expand: an OS which does provide a collection of components that can be used to build a UI but not the concept of windows and to make it connect to the hardware it provide the connecting functionality in a headless manner. App store transform into component store. Would be interesting to work on something like this.
Can you elaborate on the "The reason is to remove a dependency between your dev team and the target platform."? I think I might not understand your point here.
I think the order in my case will definitely be customer experience first. And for the the rest of the points, we are looking at something similar already, limited user access initially, only one platform perhaps.
On your last point, reusing code among platforms, I was looking into Rust, it seems there isn't yet a good way to share Rust code. I have found https://kotlinlang.org/lp/mobile/ which looks interesting.
Making a choice based on popularity of the tool might be the wrong approach. If making a choice is even needed.
If I would start something now I would most definitely go for Swift/SwiftUI and Kotlin/Jetpack Compose. I find that productivity, developer experience are best with those as soon as one gets the hand of them.
Also, these are the only ones to be guaranteed to be around long-term. While any of the cross platform options sound interesting, there is no guarantee they will be around.
I have done many interviews before with engineers, I always moved someone forward in the process based on the potential, on problem solving skills. I'm not really interested if they know a certain stack or not, that can be easily picked up in a good team with some great mentorship.
You are presenting interesting points. I also live in Scandinavia though not too active in interviews yet. Will be though, on the interviewing side. In case you are in Stockholm, wanna grab a coffee? I'd be happy to know more about what you are looking for.