AboutJust a developer in career crisis. Trying to become indepentend building indie apps (now Dashlook).
SkillsGo, PHP, Swift/UI
Joined devRant on 11/2/2022
Do all the things like ++ or -- rants, post your own rants, comment on others' rants and build your customized dev avatarSign Up
From the creators of devRant, Pipeless lets you power real-time personalized recommendations and activity feeds using a simple APILearn More
Leave for another company. Company I work at, we have so much new “senior” developers who earn senior salary, but are no better than a junior, that it proofs to be the best option to get a promotion.
And from my personal experience: changing jobs is the quickest way to get a raise.4
Want to experience how a real dev nightmare feels like? Then try creating a native mac app. And make sure you use SwiftUI.
* No access to the SDK source code, thus you can only rely on documentation
* Everything you find on google is intended for iOS (including official documentation)
* Talking about official documentation it’s almost worthless
* Apple team doesn’t give a shit about macOS, so most obvious features are missing.
On a serious note, SwiftUI can be fun when it works, when it doesn’t you still can fallback to AppKit, but your codebase looks like some frankenstein monster.
I sometimes regret I was so stuborn to make a native app, instead of just cross-platform app with WebView.6
Damn I hate Apple… I have a macOS app written in SwiftUI which worked perfectly fine. And then Apple released MacOS Ventura, which broke the app to the point that it’s unusable. Release notes, obviously, doesn’t mention a thing that could give a slightest hint of what is causing the issues. And the worst part is that there’s no way to set up backwards compatibility, because stupid SwiftUI SceneBuilder doesn’t support damn conditional flows.16
May be just me, but I am quite frustrated with complexity of systems nowadays, even more how it’s became a norm for developers to import a library for every little sh*t…
Like, do you even need to import that OSS library, can’t you make it without it? Is it really worth it to import that monstrous library of 10k loc, just so you can save writing those 50loc for just once?
It almost feels like it’s driven by logic “if you don’t own the code, then you don’t need to maintain it”. But ironically you still need to mantain it, only now not the code (best case), but the library itself. You have to upgrade it (for security, bug fixes) and you better pray there’re no breaking changes. And if you encounter an edge case/bug that no one addressed yet, then well, I bet you wished you didn’t use that library in the first place.
It’s so much easier to support small piece of code within your codebase, than fix a bug in a library, that possibly has thousands of unnecessary dependencies, enormous abstraction trees, and infinity loc to support all possible use cases, which your project doesn’t even care about.
Just to make it clear, I am not talking, about cases where some library would really do some heavy lifting for you, it would be non-sensical not to use it in that case.
And talking about complexity, let’s not even mention microservices, kubernetes, and other hyped stuff…
Does anyone else shares the sentiment?16