- Danish Swimming Water Quality App[1]: Native app for my iPhone that I use to check the water quality. The official one wasn't working for me, too slow and too buggy. Ultimately, it's just a JSON of public data spread on the map, very simple.
- Artwork Framer[2]: Script using Blender that converts .png into a framed 3D model. You can even adjust the frame if you want and then export it as a model to be used in VR (works even in Apple Vision)
I signed up for it, and I'm not expected to code anymore (I only do so in my free time nowadays - which actually made it even more fun!). But my company expects the engineering managers to be basically at the same level as senior/staff engineers when it comes to experience & knowledge. Part of my work is coaching people, which now I cannot really do in many ways.
But I'm on a good end anyways, since I have a team of people that I know I can trust with things. So I'm here mostly to find out what would be the best way for me to approach this. Thanks for all the advice!
Very blunt, I appreciate that. Though, engineering leadership is certainly different than other types of leadership. Managing through example was my current way of working. I'd be collaborating with engineers, and try to coach them when I could, or sponsor them when I couldn't (provide with either internal or external coaching).
I didn't mention that I'm coding in my initial post, and the reality is that I currently don't code at my job. So while I appreciate your answer, it doesn't really apply to my case, or my question.
On the opposite, I find that sharing code across full stack is becoming overrated. The reason I'm saying this is because that often leads to some very messy dependencies, and maintaining that codebase can become really difficult if you're not very careful.
Additionally, I found that in some teams, people would use some backend code on the frontend, resulting in some security vulnerabilities (server-side logic running on FE instead of BE). Instead, now that we have backend (Go) & frontend (TS) teams at my work, both teams consider the best practices for each environment with more focus. You could say that the same people do that with the same stack, but in my experience, if you allow people to put more focus on the one component they're building, they'll just build it better than when they have a plethora of other dependencies to consider.
The main problem could be talent, as if you have specialised people, you always have to hire for both of these positions (or train your people in either direction internally). But I honestly never experienced a shortage of people. It's more of a problem if you have a shortage of money, at which point, you should just use whatever you can build with the quickest to keep your business afloat.
With Swift UI & Jetpack Compose, I found it really easy to make a jump from React to either platform. The mental model is pretty similar to React in both. Sure, Android is still a lot of boilerplate (in my opinion), but Kotlin & Swift are also relatively easy to get into, especially if you happen to have some OOP experience.
There really should be a way to tell browsers up front about these things like changing box model for all elements, so that it's not forced to apply it for each element on the page one by one.
While I'm sure there are many optimisations already in place, at least we could avoid this anti-pattern that everybody's doing on web these days.
That's why you can use fixed library versions to make sure nothing changes. If you need to update something in the library, you can apply a patch and keep going.
> And this might mean asking to play video games with them.
I double this. It breaks so many barriers to just embrace the hobby and go along with it. Once the barriers are down, you'll get to know the person behind that face much much better.
