Readit News2. Big projects do not look finished until the end.
3. If you want to dominate the dojo, only fight children.
4. The creative process is messy and mostly unsuccessful. Assembly lines are neat and predictable…
…the sprint model comes out of consulting where the goal is to do the same thing that’s been done before.
5. QA’s job is to find bugs. They are part of your team. They are not your opponents.
Good luck.
hahah, love it, thanks!
You have the "luxury" of a QA team, unlike many developers. Take advantage of that. Don't feel bad just because you see a bug once a year (which I don't believe is accurate reporting on your part).
An actual strategy: track all of the blockers. You say that your sprints "go wrong" but that isn't a helpful observation. If you track why it goes wrong - write down the start and end time any time you get stuck, blocked, confused, waiting on others, dealing with unforeseen issues, "tech debt", etc.
This is not a failure, it's a vital signal! The time spent on blockers are literally what's standing between you and consistency. Address them head on with empirical data. You should be able to estimate the risk for any new change based on how much time you wasted in the past working on that subsystem. It's a clear choice. Slog through the problems again and deliver inconsistent results - or fix it and deliver consistently.
You do have to be selective - don't just fiddle with the code until it's pretty - fix only the observed problems that stand in the way of delivery. "Make the change easy, then make the easy change" - Kent Beck.
This is why more experienced developers get paid more — because the deliver more consistent, higher quality, less issues work.
You work more, on more projects etc. and you eventually grow. Doesn't matter at all which tricks, approaches do you use.
The best investment in you quicker growth - is to find bigger, more complex and important project to tackle, and better team.
Lots of options, some of them require swallowing your pride and putting effort in.
- Try to get stuff tested earlier (see point 1)
- if things can get be tested, write tests while working on the code
- split a feature up in chunks and develop parts
- take your time. Pressure of failing sprints (whatever that might actually be caused by) does not help. Smaller changes help with getting others to respect your time too. Everyone is happy when stuff works :), even if its incomplete
Skills wise, I would recommend spending a few years learning C++ at the least, try developing an engine from scratch, build an ECS, build some basic multiplayer implementations. I wouldn't expect much of your web experience to transfer, and you would most likely be joining the industry as junior.
Stability wise, if you have any backend experience, applying for infrastructure SWE roles that handle online services for video games is an alright bet, but that job market is quite small.