A junior engineer has been given a feature to develop. A senior engineer has built the basic mockup of the page, hooked it into the framework, but as the engineer attempts he runs into issues. He asks, through email, how do I save to the database. Its a project from a different development group, but the senior engineer has been through their code so he suggest looking into one part of the site and view specific controller and view files. The junior engineer acknowledged and life moves on. A week later the junior engineer comes to the senior engineer and says he is still having issues, so they open his code. The junior engineer has created a new file (instead of following editing the files already apart of the application structure) and is attempting to drive logic that belongs in the controller in a file in the view. He has ignored the structure of the site and is basically fighting against the natural flow of the program. At first glance I'd say this is a lack of understanding of MVC. However, this is not the first MVC project for this junior engineer.
Its a story playing itself over and over again in different ways. At first glance, I'd assume the engineer never looked at the example files and project flow, instead they just looked up "PHP connect to database". His code suggest that perhaps he looked at it, but didn't understand how the application uses the files. Perhaps the senior engineer should have called the junior engineer over and shown them the files and explained the various methods in play to save and how they work with the view.
A friend of mine once mentioned a similar issue with contractors in the corporate landscape. When he worked with them, over time he found himself practically programming the feature in the documentation to get the functionality he needed. Inevitably they fought the existing application and built extraneous files. At one point thier source had 4 different time classes that returned the time.
So how do we fix this without resorting to writing the program on a piece of paper and turning our junior engineers into a programming steno pool? Is this a hiring issue, should we let junior engineers like this go? A communication issue, did we not explain the solution completely should we have diagrammed it out? A language barrier? A training problem? An experience issue?
At this time ... I'm lost, perhaps time will bring insight.
