In part 1 I looked at my early career and the lessons learned by having to know what was happening in my code and others in order to understand bugs and build upon existing features. In part 2 I intend to look at more specific examples of using tools and how not knowing what is happening can affect a developer’s ability to do their job.
I have been called over by a more junior member of the development team in several of my past jobs to help them with a problem. Usually it is with a piece of legacy code written in ASP or PHP, they have made a change and it has broken something. “I have made this change and now it has stopped working…i need to debug it” Now at this point if it is ASP we could attach the debugger (http://msdn.microsoft.com/en-us/library/3s68z0b3.aspx) and step through the code after some tinkering. Or we drop in a Response.Write or two and hit refresh in the browser. Mostly you can get to the bottom of it fairly quickly without any extra tooling, just remember to take those write statements out before you deploy!
Another instance of knowing what is going on can arise from occasions where developers have used one of two things. Either the (horrible) Visual Studio toolbox to drag and drop a whole set of controls onto a page or when someone is using an ORM to do their database modelling.
This approach can help the “bedroom” or newbie developer to get things up and running with no hassle (if you want no hassle development and efficiency of getting things up and running, check out NancyFx) or need to write their own code. Great you might think, I have a login form or set of pages to do CRUD operations on my data and I didn’t have to write anything! What happens if you need to extend it or debug it, maybe someone else needs to style it or write some client side code against it, is it secure, does it perform well? With some digging into the auto generated code and what is being called lower down the stack and in the database you can find out the answers. However then you have just defeated the object of using some “tools” to get you to a place quickly without having to write code.
In my career so far i have done pretty much every approach to persist and read data into and from a database, SQL commands/parameters, stored procedures, views, datasets, data tables and database first, code first and dynamic style modelling using an ORM. I have had several Twitter conversations with @JohnnoNolan and @FranHoey around the potential for a dying breed of developers who can write and understand SQL. I have also spoken to people I have worked with about cracking open the Profiler and seeing what their LINQ or similar is actually doing.
Mapping database fields and values to POCOs is great and can allow middle-ware and UI development to be done without having a dependency on a particular data source. However if this source is from a database, are these queries performing as well as they could? Are you going to incur the wrath of a DBA somewhere?
At the end of the days tools are brilliant, but it is useful to know the basics, then you can extend what the tools are giving you. You can also help solve that tricky bug and gain the plaudits of your ever so grateful colleagues!