Yes and no, I'm looking for something that's deeply people-oriented now. I mentioned it in a different comment, being a teacher. Also thinking about being a nurse. My wife was a nurse, maybe we could work together.
not yet, I'm just starting. In the past (like 3 years ago) I've sent a couple of CVs around for specifics companies. Mostly the ones I was playng a game (like Rare for Sea of Thieves).
Yah, making it clear, I def get more than a couple of bugs yearly hehe. You sound right for me, and I heard stuff like that from companies here and there. Stuff like "delivery it first, make it better later", like focusing on putting it together on front of our users besides of over engineering the right thing. This is cool, till dozens of bugs appears
It's the right mindset. Because code isn't the end, it's a means to an end. The end is "value". To your users. The quicker you give that to them, the better. Bugs here and there are absolutely part of the process. You are making an assumption that the least amount of bugs is "best" for your company.
It's important to consider the bigger picture here. Consider a scenario where you spend twice the amount of time delivering features, getting things perfect. Let's assume for the sake of it, that our users will "like" half the features we ship, and we'll throw out the rest. In this scenario, it's better to reduce quality to ship faster, because half of your features are going to be "thrown out" anyway.
This happens in the real world, albeit to a less extreme extent. But the point remains. That's why we have product teams that attempt to reduce the likelihood of a feature being tossed out and time being wasted. That's why we have QA teams to ensure development bugs are caught and we deliver both value and have robust systems in place.
As long as these aren't catastrophic, affects-all-users, brings-down-the-servers type of bugs, you're probably writing the optimal amount of bugs to balance the trade-off in value delivery.
Good advice, really. love it. Maybe I can try harder to control these issues. One challenge with this is finding a way to talk about it without it sounding like I'm just complaining all the time
I've definitely been that guy complaining about all the unnecessary friction. What I've learned is that you have to be selective; take note of the flaws when you find them, but put them aside and focus on the things that directly impact current work on your plate. "I'm going to refactor this class in order to add X with less risk" is an easier sell compared to "I'm going to put development on hold while I refactor all the things for some reason."
Interesting point, but unfortunately not possible in all code bases. You know the drill, old code base, tight deadlines. But I can see the point, and I'll advocate to that for sure!
About asking feedback, what would be good points to ask exactly? I didnt have good experiences with feedbacks in my career, usually they were too vague.
