I had some nice comments on my last post about the database developer role. Most believed there is still a place for database developers, and not necessarily the graveyard. An organisation that is small enough (and hasn't out-sourced everything) can allow someone to spread out out either a DBA or developer role to combine the two. In my experience this is harder in large organisations where DBAs tend to be put under the 'infrastructure' umbrella while developers are grouped into projects or applications.
Some suggested the title of 'Architect'. I have mixed feelings on this term, but @ddelmoli summed up my thoughts with his tweet "I don't know what db architects do. All I know is they're rarely around when the SQL is tough or the db needs recovery".
I'm all in favour of a good achitecture and design. It won't work otherwise. But to my mind it is a first step and there's an important job in turning that design into a working system. Joel Spolsky talks of 'Astronaut Architects' who have believed the hype of the latest and greatest. And then leave you to implement some new architecture where the software is still in 0.X version. Or in some cases, 16.X because they are releasing new versions every month, each highly incompatible with the last.
And then there are the 'Cookie Cutter Architects' who use the same design for everything, changing the names to protect the innocent. You'll quickly find that in their haste to reuse and recycle, they've missed some essential facet of the business that makes the solution unworkable.
And that's the key. If it doesn't work, it doesn't count.
I recall a year or so ago seeing a student on the train with a folder bearing the prominent sticker "Engineers make it work". I know when I've delivered a screen or batch program, and watched it run in Production, there's a great feeling of accomplishment...at least when it doesn't fall over. I've never felt that when I've produced a design document. Then its more of a feeling of "Great, that is out of the way. Let's get things happening."
So I definitely prefer the term 'database engineer'. I think that's what I want to be when I grow up
2 comments:
Engineer is probably the wrong title: it is a totally different discipline.
Many years ago when HR didn't exist, there was an IT generic title that fit the job perfectly:
Analyst.
We had System Analysts, Database Analysts and Analyst Programmers, depending on the particular requirements.
Then HR started and having no clue what to do with IT, they decided to fill it with "feel good" and "group hug" positions. Just like they did for the rest of the enterprise.
The result is the cacophony of titles you see today, basically one for each job ad.
Meanwhile, lo and behold, the need for Analysts never abated. There was a very specific reason for their existence:
they were needed.
But "need" is something HR simply does not understand. If it doesn't fit some model they saw in a HR rag that weekend, it can't possibly exist. It's all about following "trends".
And the whole sad joke goes on and on...
I started out as an analyst programmer. My degree is even in Systems Analysis.
But I do find it quite a passive term. I want something that embodies Analyst/Designer/Programmer.
Engineer does balance against Architect. But it definitely implies a more rigorous discipline than that typically seen in software and especially in-house development.
Post a Comment