In working in our graduate programme I’m noticing a general trend, the urge for graduate developers to write as much code as possible regardless of the situation.
Part of our prgramme involves them going into different teams - sometimes the teams the go into teams are at the ‘busy figuring out a new piece of work’ stage and are having a lot of meetings and discussions on what and why they are doing something. Generally the graduates will rate their week poorly because they haven’t gottent to code as much as they would like. I came across a post called 15 tips on How to Improve as a Junior Developer. Natasha made a great point, she said…
It’s easy to feel like nothing is more important than the next feature or problem to be solved. Meetings, research and time spent gathering broader context for your work can feel like painful interludes between getting your hands dirty in the code. However, you’ll soon come to realise that understanding the whys of what you’re doing are more important than the hows. If you’re missing context or an understanding of the business, industry or organization that you’re working within, you may end up building things that people don’t need, or won’t use. A significant chunk of Junior developer mistakes are due to us misunderstanding or making assumptions about the domain we’re working in. Take the time to understand how things work in the real world before trying to translate them into code.
Often the opportunities to understand if what you are going to build is really the best thing to do is more important than the construction part.
