Trust Your Elders! Or Rather, Experienced Developers

One thing I’ve often done is take a method that somebody has developed with and changed it to suit me. Be this a full out framework or just a minor snippet. Code should always be well written and look good and be simple as possible.

That being said, there is something to think of before making any changes.

If you’re working with something by somebody who has lots more experience than you, maybe you shouldn’t. Often we see guides written as if they are making things more complicated than needs be. But be careful, they can often have a real reason to be complex.

Currently, I’m following a style guide for working with Angular 1.* ES2015 styleguide, but I feel it could be simpler. It can be. After much thought and reading into it, I’ve chosen not to. The fellow that wrote the guide, Todd Motto, is a hell lot more experienced with Angular than me. There’s a good chance he had the same thought as me but knows a reason not to do it that way. Why change something that somebody has clearly spent more time thinking about?

I think this is evident when working with code that will be developed across teams and scaled up. More so when time is money and you’re changing something that later may cause issues. These people have seen issues you won’t have come across yet, and if you follow their rules, maybe you won’t?

Think of it this way, is the real reason to change something because it doesn’t suit your thinking? Is it complex and you can remove tens to hundreds of lines doing it your way? Before doing that, read over any reasons given and if that doesn’t please you then ask. Developers should always challenge their thinking, even by those who without as much experience. That’s a key to learning and making quality code is questioning the reasoning behind it. So it works both ways. You get a new understanding of code but the developer also has to justify their reason as well.

Don’t just change things for the sake of suiting yourself. Look at the possible reasons why it’s like that. Ask why if you don’t understand providing your solution and reason behind it.