Jedi mind tricks or cardboard cut out?

I was sat with a developer in my team the other day. He was trying to put some functionality into an existing site. Impressively he had drawn out the flow and logic for the problem so it was all laid out in front of us. He described several ways of handling the GET and POST requests needed to implement what he had in mind. The stumbling block was that he didn’t like the solution that seemed the clearest and most simple. It seemed too simple, to the point where it felt like there must be something wrong with it. Thanks to the diagram and his description of the solution I couldn’t see any better way of doing it. I spoke relatively little and asked why he thought his solution was flawed?

After a few minutes we both agreed he had the answer, at this point he was convinced I had told him the solution and how to implement it. The truth is I hadn’t, he had it all along. He just needed to be convinced that he wasn’t missing something and that simple can be right.

I told him he had solved it, it was all his work, I just listened and asked a couple of questions.

No, you just did some kind of Jedi mind trick on me to make me think it was my idea.

A developer I used to work with called it the “cardboard cutout”, the person you are helping talks to you, you either just listen or ask the odd question. This usually flushes out any issues and helps arrive at the best solution. No mind tricks, no persuasion, nothing but a few minutes of geeky goodness.

We are using this technique more and more to work together, improving the understanding and quality of what we are building.

Needing to know the basics – part 2

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.

VS Toolbox

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.

ORM

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!