There are plenty of developers who will happily build the functionality described in a set of requirements.
That is fine as far as it goes. We need requirements and we need to deliver working software to satisfy requirements. But it takes a LOT more than just this to build decent software products. Not only are there a myriad different ways to satisfy a set of requirements, but even more exciting, in today’s agile (small a) world developers have a great opportunity to co-create products with their product owners. And in the process to become great developers, not just good developers.
So I want to share some personal views on what you should be thinking of to become a great developer. I’m taking for granted that you know your framework, you know how to use Stack Overflow and that you write good unit tests. I’m going to be talking about the other stuff. The stuff that, in my view, distinguishes great developers from, well, just developers. The stuff that, when I see it in my team, helps me sleep more soundly, knowing that the codebase is in good hands.
Here’s the first one.
Learn your database
Your framework is great. It has a lot of really cool abstractions so you can program away without having to (amongst others) handle all the tedious details of writing SQL [1].
Time for a story.
A product owner was launching a new product and wanted to give the impression that it had been around for a long while. A reasonable request, I mean, who wants to know they are being billed with Invoice #1. The solution was to use a higher number. So the first invoice would be #225678 rather than 1, for example.
This is trivial to do with any RDBMS I’ve seen: you just set the auto-increment to the appropriate number, rather than start counting from 1.
Not in this case. The developer didn’t want to get involved in proprietary database commands. He decided to use a parameter, let’s call it INVOICE_OFFSET, to adjust what someone would see on the UI. Sounds simple enough – set INVOICE_OFFSET to 225677 and every time you show an invoice number on the UI or in an email add INVOICE_OFFSET to the database id. Likewise, subtract before you do any CRUD operations on the database.
Can you see where this is going?
It was fine while there was only one developer involved in the product. It soon turned into a bit of a mess when new developers came on board and weren’t expecting this INVOICE_OFFSET idea. For example in a REST situation, would you use the database ID in the URL? Or use the ID that the user would recognise? And then when you were interpreting the ID in the URL, is it a database ID or an adjusted ID?
True story [2].
I fully accept that writing SQL by hand is horrible and so I am very grateful for ORMs for abstracting that away. But too many developers have gone too far the other way and treat the database as a black box. Or go as far as learning about indexes.
Databases are pretty awesome pieces of software, see what else they can do to help you build better applications.
[1] Hell, you could even write an application that you can then easily port from one database to another should you want to. Though if there ever was a case of YAGNI, having an app that you can port between databases should be a top contender.
[2] To be fair, I don’t think there was ever a production issue where one person could inadvertently see someone else’s invoices, but it was certainly a PITA during QA time.