Experience knows a Name
Reading Your Language Features Are My Libraries, a thought occurred to me. Not about language features, but about people.
I see new developers latch onto the new languages and the features that they support (Java has garbage collection; Ruby lets you extend classes and makes DSLs easy; C# has list comprehensions; and so on). I see new developers lead themselves down the road of re-implementing solutions when pre-existing libraries may have been available (sometimes core libraries). I see senior developers lament that the junior devs aren’t paying attention to what already exists.
Senior Developers have an Index
Seasoned or experienced developers have a large mental index of existing example code, libraries, design patterns, frameworks and full application stacks. Experienced developers can often qualify and evaluate suitable pre-existing approaches (existing language support, core libraries, available libraries, pre-existing applications) – much more frequently and with more success (where success is re-use rather than re-implementation) than junior developers.
I’m not so sure that the only reason for this is just that new developers don’t have the mental index of language features and libraries that more experienced developers do.
Both types of developers can use Google right (it’s a big “index” after all)? Well…not in the same way. Experienced developers have a higher chance of already understanding core aspects of the problem they are facing. Experienced developers are more likely to know the commonly used names for many of the aspects of the problem they are facing. So when they search, they’re searching for something very specific, something that is more likely to be found.
Junior developers will not be searching by name, rather by definition. They search by using the phrases that describe what they’re after. This isn’t as successful. Look at the difference between searching for carbonated sugar water versus coca-cola.
This has a huge impact on the likelihood that a suitable pre-existing solution will even be identified. I have improved in this respect over the years – partly just by accumulating knowledge of the names of things (this is the idea that naming something or knowing its name gives you some amount of power over it).
Then we come to the issue of understanding the problem. Developers will more often have to work to build a working model of the problem before any search or selection could take place. Developers by their very nature will write code to help them develop understanding of a problem. Writing a prototype is a very powerful tool for helping you understand a problem – if you can instruct a computer to perform a task, you must have a pretty good understanding of it.
Here’s the rub though, once you have a prototype, you have something with value. It becomes less attractive to qualify and acquire an alternative when you already have a working, or close to working “bird in hand”. Junior developers often over value their prototypes, partly due to the actual effort it took them to create it. Senior developers create more minimal prototypes, only explore the core parts of the problem domain they don’t already understand – and often with different tools, not caring about input, output or fixed data models or well defined types. The point is to learn just enough and senior developers are more prescient of what ‘just enough’ is.
Junior Developers Implement to Learn
The transfer of the names of things of these patterns of problems, is a core value that developers get out of mentoring each other.
Junior developers implement to learn. I encourage the junior developers I work with to write prototypes of existing algorithms and design patterns – it is vital practice and helps them develop a deeper understanding of problems. I try to discuss with them what they did, why they did it and try to transfer terminology and discuss with them existing solutions that I may know of for contrast.
As they gain experience, they will know its name.