Let's define malleability as how quickly a codebase can be modified to meet new requirements without breaking anything. The more malleable the codebase is, the more productive and happier the team will be.
Unfortunately, malleability is perceived differently by different engineers. This can lead to difficulty improving it - in the worst case, different areas of the code diverge in style leading to siloing and decreased malleability overall. Ideally, teams are aligned on what malleability looks like and how to improve it.
On a individual level, you can help by being humble and self-aware about what's influencing your own perspective. This can help calibrate your views in a direction that leads to better alignment with your team and nicer code for everyone.
I'm going to talk about a few factors that can influence an engineer's perspective:
- Experience with the codebase
- Skill at reading code
- Personal sense of aesthetics
Experience with the codebase
Learning a new codebase is hard. At the beginning, it seems impossible to wrap your head around how everything hangs together, grasp all the new idioms, and untangle all the foibles. It can seem that the only productive way forward is to refactor or rewrite everything into a more malleable form.
The good news is that even on a complex codebase, as time goes on, you will eventually internalise the things that matter in order to be productive. Even the quirkiest bits of code and the funkiest anti-patterns will become second nature and the cognitive overhead of making a change will drop to the point that you can make error-free changes quickly. The trick is to start small (say, with bugs), then move onto features and big refactors later. Being tasked with making achievable changes causes the testing effect to kick in and your brain to learn by doing.
I recommend judging a new codebase with caution until you've been working with it for a little while, particularly if you can see that the engineers that have been there for a while seem to be getting things done. Even if things do need refactoring, your perspective and decision making will be much better after you've immersed yourself in the code and internalised the key parts of it.
That said, a codebase that takes a long time to internalise and be productive with is an excessive malleability tax on new joiners. The team should worry about this if they expect to ever have new joiners on the project. If the business is successful, this will likely happen eventually!
Skill at reading code
Different programmers have different levels of ability to read other people's code.
Reading code is a skill that is mostly gained through the experience of making changes to other people's code. Engineers that have mainly worked on their own projects will need time to build up this muscle. If you don't have a lot of experience, getting involved in open source is a great way to supercharge your skills in this area. Bear in mind that it's essential that you set out to actually make some real changes to something (i.e. accepted by the maintainer) rather than passively reading it in order to learn the skill efficiently.
It's also worth mentioning that in an unfamiliar codebase, being proficient with an editor that can fluidly jump to definitions and call sites of functions (and back out again) to surf the structure of the code is essential. Learn all the keyboard shortcuts and get them into your muscle memory. If in doubt, just use Visual Studio Code or something by JetBrains.
If you've mostly worked on your own projects, its quite likely you will have a bias towards wanting to refactor code into your own style or just rewrite all of it into something you can deal with, as the cognitive overhead of dealing with other people's code will be high to begin with. Resist this urge! Take this as an opportunity to build up your code reading muscle - after a little while, you'll likely find the existing code is somewhat malleable after all and you'll have saved yourself a heap of time. If it is indeed garbage you do decide to rewrite or refactor after all, you probably won't have much success doing it unless you have internalised the existing functionality - and the best way to do that is by actively making changes to it.
Personal aesthetics
Engineers are largely unique. Each engineer gets jobs satisfaction from a different blend of things.
Some engineers are strongly motivated by the feeling of building things and shipping products to users. Other engineers are more motivated by the inner beauty of code and take delight in technical elegance. For most of us, its a bit of both.
As you've probably experienced at some point, this broad church can occasionally experience a disagreement or two! When thinking about how malleable an area of code is (or how it might be if you refactored it), regardless of how experienced you are, it never hurts to check your ego at the door and reflect upon the following with humility:
- To what extent do I hold this opinion because of an aesthetic instinct, rather than visualising the likely outcomes?
- Can I back up my opinion with some concrete examples? Do they represent likely future work?
- What's the counter argument? How well do I understand it?
- Is it possible that I would change my mind if I had more knowledge?
The most effective engineers I've worked with have a humility that allows them to be productive in many different styles, and to seamlessly adapt to the methods of any team they join. They often hold strong views about aesthetics, but they value team alignment more highly than their individual preference.
Summary
When discussing malleability, strive to reach alignment with your team. Be humble and self-aware about your own familiarity with the codebase, how skilled you are at reading code, and what your own personal aesthetics are.