Type 2 can have a reduced insulin production, as well as the insulin resistance. In fact, insulin resistance can put increased demand on production and exhaust the producing islet cells.

Since type 2 is not an immune system disease, in that case there’s no need for immune suppressing drugs!

Don’t understand the kidney thing either:-)

Just care for your team.

Realise you need to spend most of your time working with your more junior developers, making sure that they understand the problems they’re solving, doing some whiteboard-design sessions, jumping in and pairing frequently to teach them as well as keep things going in the right direction. A lot of that is giving your team enough confidence that they’re going in the right direction that they can make the decisions they need to make.

But you should not see yourself as someone that picks up tasks and gets things done by themselves. You need to work through your team. That can be difficult. And if the team gets larger, that gets even more difficult! You’ll need to find some seniors you can trust, and use them to pick up some of that leadership/guiding work. You will run the risk of getting further removed from the practical technical work, and will have to find a balance. You’ll probably be doing more work around the team than in the team. Maybe get involved with planning more.

But the most important thing is the above: make things clear for your team(s), don’t leave them guessing about the direction, but don’t prescribe the solution too much, teach as much as you can, but give people room to make their own decisions too.

There’s a few different things, I think, that are wrapped up in this.

• Generated UI code is unmaintainable
• Finding (and using) a good cross-platform UI library is hard
• Setting up a new project and packaging for it is hard

To start with the first, yes, generated code can be useful to quickly get something started. After that, in general you’ll need to adapt it and grow it be coding from there on. Round-trip (going back to the design tool from code) tends to not work that well.

There’s good UI libraries, but cross platform tends to be difficult. Oddly enough, a lot more work has been done to create good cross-platform UI on mobile than for desktop. Interestingly enough, flutter seems to also be bridging that towards desktop. Another ecosystem, another language (dart), but much clearer about how you should build, and plenty of documentation on easily building, from code, user interfaces.

Taking a small step back, I’d like to say that one thing you might want to start with is to look at your current code and try to restructure it in such a way that you separate the core of the functionality from the user interface. This can be a tricky process, and reading up on refactoring techniques is going to be useful. It might also really help in this process of potentially moving to a different language, because it will be so much clearer what you are moving, and what is incidental and just related to the framework you are working in.

Don’t confuse a bad work environment with not liking or being suitable for your job.

If you liked programming, do your work in the way that made you originally liked programming. People will put pressure on you to just “do things”. Don’t. Ensure you start understanding, slowly get more insight into what’s going on. Ask the people around you any and all questions you need to get more understanding. Allow yourself to learn. That is the only way to start feeling in control, and the only way to become ‘more senior’.

That being said. If you want to move on, there’s no harm, and no shame. Just do it because you’ll be doing something you know you will like better.

I’ll just leave this here:

What about code reviews?