A Tale of Two Devs - exploring the differences and crossovers of SQL and BI

How many times have you heard SQL Devs say that BI Devs’ work is easy? And how many times have you listened to a BI Dev argue back that SQL tuning is simplistic; better suited to lower-skilled DBAs?

As a technical recruitment agency, we wanted to share the differences (and crossovers) between these two roles. Drawing on their extensive experiences of the roles, Naresh Mepani (RPMI Railpen) has taken the side of BI Devs, while Kevin Urquhart (SQL Solved) has taken the side of SQL Devs…

BI Devs V SQL Devs

Naresh explained how the role of a BI Dev is crucial to the extraction of data and the speed of usability we can gain from it. Typical BI Devs focus on creating a unified sense of data for businesses’ day-to-day runnings, using BI tools to transform data. On the other hand, SQL Devs use SQL (surprise, surprise!) to build out and maintain infrastructures, which is an area often overlooked by BIs.

How an outsider views these roles

To an outsider, it seems as though these two roles would work alongside each other harmoniously, focusing on their aspect of a joint, data-related mission. However, it sounds as though there’s a pretty massive gap in terms of how each role interacts with the business as a whole – BI Devs know the industry inside out, SQL Devs don’t. Both Naresh and Kevin agree that this is a gap that needs to be bridged.

The rapidly expanding gap

The gap is rapidly expanding, mainly due to the widespread criticism of BI Devs – by SQL Devs. Due to the growing demand for BI Devs, SQL Devs have to streamline their skillsets. The industry no longer needs DBAs; it needs specialists. As such, SQL Devs are being pushed out – by SQL, strange as it sounds.

The performance myth

And what about the myth that BI Devs don’t care about performance? Well, it’s not strictly true, says Naresh, although he acknowledges that this role does purely focus on the data itself. The SQL Devs are the ones who pay attention to this aspect of data sets, refining data modelling in ways that BI Devs can’t, or don’t, do. There’s also a suggestion that BI Devs work from a short-term perspective, coding for now (and coding fast) without much regard for future functionality. Again, this highlights a vast difference between BI Devs and SQL Devs – the latter being far more focused on coding ‘properly’ or for the long-term good, as Kevin remarks.

However, although BI Devs are widely seen as intuitive, their exposure means they have their own way of doing things. Despite the suggestion that their jobs are easy, many argue that working with SQL has become overly simplistic and that their niche is disintegrating into DBAs and novice coders. BI Devs need less and less SQL experience – they no longer need an in-depth understanding of it, thanks to the race to automate everything. Again, this is increasing the gap between the two niches, causing more tension between the roles. Adding to this is the accidental misunderstanding and mislabelling of roles by many recruitment agencies – job adverts posted with incorrect skillsets or experience requisites can lead to further competition between BI Devs and SQL Devs, despite the difference in their roles.

Taking the side of a SQL Dev, Kevin remarks that BI Devs are creeping into this domain – the vast number of tools they have access to means that it’s becoming more of a ‘generalist’ area than an expert niche. More BI tools mean less focus; fewer skills. Sure, BI Devs can write SQL code, but will it work? Not according to a lot of SQL Devs, by the sounds of it.

What’s the solution?

For budding Devs the world over, both Naresh and Kevin suggest upskilling. ‘Get exposure to what you can, have your niche and train yourself up’, says Kevin, citing the numerous online courses available globally. Naresh suggests choosing a stable stack, at least to start with – Microsoft or Amazon are a great place to learn. Of course, Oracle is always an option for those who fancy investing half a decade in learning! The more experience and exposure you have, the easier it will be to work your way up the ladder. It’s all about being proactive – companies look for those who are willing to learn, so you’ll need to be ready to put the effort in yourself. Refine your interests, pursue your passion, and figure out which side of data-handling you want to be on.

It all comes down to speed vs intricacy, immediacy vs sustainability, BI Devs vs SQL Devs…