+972 52-548-6969
The basics requirements of a developer
Something really bothered me in JAOO. A couple of the presenters had a slide that showed something like this:
The Relational / OO Divide
- DBA not familiar with OO design
- Developer not familiar with SQL
I asked around, and apparently there is this assumption on the Java world that developers are usually only vaguely familiar with SQL. I am not sure if this is the case in practice or not, but that just sounds insane to me.
I live in the .NET world, and here I expect all developers to have a fairly good grasp of SQL and how it works. Not to the DBA level, I wouldn't really expect a developer to be able to fully analyze a query or optimize it based on index scan patterns for Oracle 11.g with patch XYZ.B, but I would expect that they would know SQL as well as they know their programming language of choice.
In fact, thinking about it, in most of my recent projects, a developer is expected to know at least the following languages:
|
|
This isn't really from choice, this is simply because those are the stuff that we use fairly often. It seems odd to assume that you would limit that. That would severely limit your ability to actually do useful work.
Comments
I'd be curious to see how many people can state they know all those languages to a point where they can do a presentation during 15 minutes on each and every one of them, explaining the limits, do's and dont's.
I tend to think you're expecting a lot!
If I was to expect that much from a developer in Montreal, I wouldn't find anybody! If so, I have open positions ;)
Ahh but in the Java world you just pickup another level of abstractions such as Hibernate, Struts, or Spring.
Screw that, just another thing to learn and muck through when debugging. Why not just code SQL and be done with it?
I'm not advocating assembler mind you, just that enough with all that abstraction stuff. And now LINQ from Microsoft. %^$#@!(&^
Ayende, I think we are thinking alike about this, but I would like to say it in an other way.. (well, maybe not about VB.NET.. that's for poets ;-) )
If a developer had, for some reason, never before been working on a project dealing with this languages, (s)he should be able to pick them up in just no time. These languages are not rocket science.
I do believe that if someone with about 2 years of professional experience is not able to learn xslt, hql, javascript or whatever in a week or two, that person will never achieve the level of a decent developer. And I don't say you have to know all these stuff by heart, there is a thing out there called Google.(don't get me wrong, there are some basics you really have to know!) But you should be able to know what to look for when you're stuck and what the problem is you're dealing with.
So my point is, the languages are not the issue here, neither the .Net or Java world, but the ability of thinking abstractly/analyticly and to be able resolving problems in some language suited for the domain/problem in a maintainable and structured way. Off course, the les one has to look things up, the higher the efficiency ;-)
The fact that these tool vendors are assuming developers are nitwits who aren't sufficiently competent to learn these technologies is indeed rather disheartening.
However, it should also be your clue that the primary target audience of these vendors is rather different from what you might like to imagine. These tools are designed to appear to a particularly pessimistic conception of the Mort archetype -- not you and I (or really most anyone who reads tech blogs).
The truth is, we just don't need these tools. We're all rock stars. If we don't have the tools, we'll build them ourselves or we'll do without them, learn what we need and succeed regardless!
We're a real finicky lot and at best a niche market insofar as tools vendors are concerned. Most of them won't make enough money by courting us to be worth the bother. We simply won't pay for anything unless it's perfect and we can't already get it for free from open source projects.
Is it any wonder that the vendors are looking elsewhere?
A good DBA can run rings around the best application developers I have ever met ... SQL is an art like C# - in fact I would say you can pretty much be an expert in only one domain.
Most Java developers can write PL/SQL - but they know there are good database developers that do it 1000x better ... in the MS world the seperation of database from application is far more blurred ... and not neccessarily for the better.
VB.NET and C# together? It doesn't seem to be right at all :)
Francois,
That is literally the bare minimum that you need to understand just in terms of languages, I can go on and list the technologies that you need, and that would probably be longer.
You don't need to be an expert, and I am perfectly willing to accept someone who knows XSLT-via-google, for instance. That is my level of expertise there, after all. But you do need to be able to work with them.
Steven,
Absolutely, those are usually things you can just pick up very easily.
The point is that you would usually have picked them up after a year of two programming. If you have the experience but not the knowledge, that is... troubling.
There are reasons for that, obviously, but at least most of them should have been stuff most developer would have used and are familiar with.
And if I get a response like "I need a three weeks course to learn that", this is probably someone I wouldn't like.
Casey,
Again, no argument here, I certainly hope that a good DBA knows more SQL than I do.
Nevertheless, I certainly expect to be able to read most of what they are doing, and to be able to follow that, and to be able to write stuff that would put the DBA into convulsions.
Most of my stuff puts DBAs into convulsions too :)
I actually applaud the Java world where developers stay out of the database ... most applciation developers write bad enough C#, they really shouldn't be let near a database!!!!!
I absolutely agree with Ayende. The developer must have a knowledge in these fields - not to be an expert, but to be able to develop and solve low level problems.
"The half of knowledge is knowing where to find knowledge".
--inscribed over the main entrance to Dodd Hall, Florida State University.
"I would expect that they would know SQL as well as they know their programming language of choice"
That sounds over the top to me. It's like being expected to know my mother-in-law as well as I know my wife.
I'd expect a good developer to be competent in SQL, but if I'm hiring them to work primarily in C#, I'd hope that's the language they know best! I've pored over the C# spec for hours and hours - I consider that I know most of its "ins and outs".
By contrast, I know SQL well enough to do most of what I need without looking anything up, and I can almost always do what I need to after a bit of searching. However, I'm sure I'm unaware of some of the pitfalls - partly because they'll be different for different databases.
I guess what I'm saying is that "I wouldn't really expect a developer to be able to fully analyze a query or optimize it based on index scan patterns for Oracle 11.g with patch XYZ.B, but I would expect that they would know SQL as well as they know their programming language of choice." is a contradiction in terms - because when it comes to my programming language of choice (C#) I can do the equivalent of the query analysis/optimisation.
Would you ever dare to tell a DBA that they should know C# as well as they know SQL? If not, why is it reasonable to reverse the position for developers?
(I suspect we're actually on the same page here, and that you've just exaggerated how much you actually expect of developers. I'll be interested to see whether that's correct or not though :)
Jon
PS Why does the blog claim that a url of http://pobox.com/~skeet/csharp is invalid? My guess is that the tilde is throwing it off...
I can assure you that the only times that I have actually read the C# spec was to find the scoping rules for anonymous delegate inside a loop and when the C# 3.0 came out in PDC 05.
By knowing SQL as well as their programming language of choice, I meant just that, they should be able to program in them. I think that you consider knowledge of the language to include stuff that I would consider as framework knowledge.
I wouldn't try to tell a DBA that they should know C# because they aren't building applications. Developers talk to DBs all the time.
About the tilda, complain to Haacked :-)
Each of the languages you mention besides SQL and HQL, I would say every decent ASP.NET developer should know, or at least be familiar with enough to produce production level code. Just by working with ASP.NET, I have had to learn all of them in order to be successful (successful enough to keep my job, build products in a timely manner, ect.).
Our local university, which touts a strong computer science department, does not make relational databases a mandatory class. Instead it is an elective. I would say 80% of the engineers I interview from this university have difficulty explaining joins, stored procedures, and why indices are necessary.
T-SQL is a language I feel every developer should know. They do not need to be an expert, nor earn a DBA level status, but they should be able to retrieve data from a table, join tables, write stored procs, and know when to lock tables. I may be missing a few, but beyond that, a DBA should step in and help.
HQL is implementation specific, and I would see knowledge of this as a bonus.
To reiterate your initial post, I too am disappointed that developers and DBAs draw distinct boundaries between the two crafts. As far as I am concerned, there should be a fair amount of overlapping and collaboration.
There's a differece between "knowing how to program in SQL" and "knowing SQL as well as you know your programming language in choice".
I know how to program in SQL, to a reasonable level, but I know how to program in C# to a much greater degree. (And I really do mean C# rather than .NET.) In other words, I don't know SQL as well as I know C#. I don't see why that should be either unexpected or unsatisfactory from an employer's point of view.
In the context of the original sentence, it seemed clear to me that the "as well as" meant "to the same extent as" rather than just "in addition to".
If you really just meant developers should be reasonably competent in SQL even if they're much more skilled in their programming language of choice, that's fine - but expecting to be as good in SQL as they are in their preferred other language - i.e. making it a "joint first" language - seems like overkill to me.
Jon
"developers should be reasonably competent in SQL even if they're much more skilled in their programming language of choice"
I can most definitely agree about this statement.
Cool - sounds like I was making far too much fuss over a simple misunderstanding then. It's not the first time :)
i think i'll benefit on this, resharpening my skills. its the best
Comment preview