The Big Picture

2 mins

I think it’s important for junior developers to learn to see the bigger picture in projects. However, this can be hard for new developers, particularly those with no computer science background. I have been told by experienced developers that the ability to see the bigger picture comes with time and working on multiple large projects. As a junior developer who is looking to transition to mid-level, I feel more and more aware that I still occasionally miss the bigger picture. I also think this is something that can be improved over time. To do this, I have to be aware of it and its importance.

It’s important to see the big picture because it will inform how developers write their code. If they understand that code needs to be maintained in the long run, and needs to be flexible and scalable, they will feel more motivated to write their code in a particular way. Naming and commenting are good examples of this. The way components, variables and files are named and commented is quite crucial to the maintainability and understandability of a codebase in the long run - and not only for the team but also for the developer who writes the code in the first place.

Seeing the big picture is very useful when it comes to naming code. Here are a couple of examples: 1. An API used as a proxy should be, in effect, ‘dumb’. It should not be named in such a way that suggests it is connected to another part of the codebase. It should be named for the purpose it serves and nothing else. When the API is used in a codebase, then it can be customised to fit the codebase’s purpose. 2. An icon should be named according to a decided pattern. One suggestion could be to name icons for what they are - e.g. a box with a shadow could be ShadowBox. In this case, any new icons added to the codebase should not be named for what page they are on or what function they serve. Both of these examples will help keep the codebase clear and understandable for developers who use it.

If a piece of code is complex, it pays to comment why it is there and why the code was not written in an alternative (and to the uninformed eye, a different but equally good way). People will thank you tremendously and you will thank yourself even more strongly for taking the time to comment code.

To conclude, I think it can be hard for new developers, particularly those coming from a non-computer background, to see the big picture. Most beginner projects that new developers can do by themselves also do not give the aspiring developer a very good idea of what it means to scale a project. Due to this, I think new devs should not stress too much about missing the big picture, but that they should always be aware that it’s an important thing to learn. If you’re a new developer, take your time and work on as many large projects as you can. Be involved, ask questions, and ask for feedback. Seeing the big picture and writing readable, maintainable code is a skill that comes over time and it totally learnable.