If you can separate those practically at the job you are likely
working in a canned document production gig where all the programming
has been done for you and not calling you a programmer is a means to
keep your salary in the 40k to 60k range USD. IOW, cheap hands to
tag, not design.
Data design without an eye to implementation in code is clothing
design without an eye to the human body. No size fits all.
I've spent the last ten months "designing" a FOSI to render S1000D to
PDF via a broken version of Arbor Text. I've spent sixty hours a
week for the last ten weeks writing an application to get around the
problems of compose on demand from the CSDB for a data design that
while smart in its data-ness presents peculiar challenges to
composition if one doesn't actually understand the data design both in
its XML features and the problems of mapping it to an output spec
that is significantly different from the implied spec. None of these
are insurmountable and it's been fun to solve the problems but without
programming skills, they are impossible to solve. Of course others
have and that is why there are expensive but working solutions to
these problems available commercially. That's the business. Diverse
competencies are the best approach to just-in-time chaos: smarter
monkeys over process.
Sexier? No. Excel spreadsheets are sexier if you measure who's
actually getting laid by virtue of their work title. XML-Dev slowed
down once it was realized that as a Development Process it was
complete. Rehash isn't sexy.
XSLT implementation is harder by orders of magnitude than data design.
That makes for a lively and constantly refreshed monkey tree.
len
