Here's the deal. I just got my first "senior developer" job in a company that's moving from the "Ahhh! Write all the code and deliver all the things so we can get some marketshare!" phase to the "Ok, now we need a professional codebase" phase. It's AngularJS and the things that need to change are seemingly obvious (add tests, reduce duplication, clean things up, etc), but I keep finding myself asking the same questions.
- How can I prove that one version of the application is better than another?
- How can I set up an environment that allows my devs to prove that a change they want to make is worthwhile?
I feel that all of these things come down to metrics, but as of now, there are no metrics being gathered that I can use to drive my decisions. I don't believe there's a need to change something on a hunch or because the community says I should be at one version of a framework over another. I'd like to add that I believe better can me measured from the user's POV or from a developer's POV. A version of an application that's easier to maintain is better that one that isn't, although not directly to the user. Below are a few things that I already know:
- Page load time is the most important metric to the user.
- Tests allow change to happen safely. They are absolutely necessary, but the "what to test" conversation is for a different post.
Top comments (1)
I can definitely relate. I feel like we're in this kind of phase with dev.to a bit. Of course, a/b testing can solve a subset of the issues you are describing. But it's definitely not something you can rely on to solve all your problems.
I have more questions than answers, like you, but trying to establish some principles can help. Like, having a principled idea that the users will never use all the features so we should question adding more vs putting more work into existing ones. That might be a bit contrived, but finding things you can lean on to make consistently good decisions can go far IMO.