|
|
|
|
|
|
by Izkata
978 days ago
|
|
|
It's not going to be anywhere near as big as other responses, but I kind of did at 31: switched from development to maintenance. I was tired of having to keep redoing the same thing whenever the product owner or designer changed their mind on something, and the tipping point came after they were looking for suggestions for this one visualization clients had a hard time understanding. No one liked my suggestion so we did one of the other ones, then a few months later it came up again as still too confusing and the designer came up with something new - that just so happened to be the same thing I had originally suggested. It's been that version ever since. Switching to maintenance here meant that we're directly solving problems. Not just "thing is broken, fix it" but also creating simple for-purpose tools, refactoring and upgrading, and largely being able to plan our own work. It's been a great place to use the depth of knowledge built up over the years, though not so great for new devs to build that knowledge in the first place, like we typically would try and use the role for. |
|
|
- in job1, I redid the same thing three times (!!) using different tech stacks and/or different designs; got tired and found new job
- in job2 I was working on performance and tooling, so this was quite new; but after 2-3 years it became clear the app will go the same endless cycles of UI rewriting & refactoring, with things changing faster and performance degrading faster than I could improve it
- in job3 I'm in a senior role & platform team, building & ops-ing stuff; but most importantly the company is here to stay, and it builds new stuff; there's a very stable design system, and we keep innovating & keeping lights green, rather than doing endless brand refreshing.
Also a critical diff IMO: job3 is a b2b product -> focus is on making stuff work;
job1 & job2 were b2c products -> focus was on chasing new b2c customers (hence endless UI changes, lack of focus and vision)