TLAs, we hates them, my precious.
Mar. 26th, 2010 02:28 pm![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png)
It seems that every time I look at a job description, it has TLAs in it. Some make sense: if they want me to know about "XML", fair enough, that's the precise technical name for it. Sometimes the abbreviation is a registered trademark for a specific product - again, fair enough.
But there's usually a string of extras, methodologies and so on, and every time, I Google them, only to say "oh, that! been doing it for ten years, since when did it need a fancy name?"
The latest is a job which requires "Hands-on experience of ETL development". Googling takes me to Wkipedia (as it often does), where I am told that "ETL" means "Extract, transform, load". To go into more detail:
* Extracting data from outside sources
* Transforming it to fit operational needs (which can include quality levels)
* Loading it into the end target (database or data warehouse)
Well, duh. Yes, done a lot of that. But again, since when did that need a mysterious abbreviation? And why that abbreviation: the concept is one I learnt while looking at Jackson Structured Programming: think in terms of data. What have we got, what do we want, how do we get from one to the other? "JSP": only now, if someone talks about JSP in a job spec, they mean "Java Server Processes" - probably. It might, in certain contexts, be a Joint Service Publication, if I went back to dealing with engineering software for the MoD.
And there's the problem. If everyone's inventing TLAs for the most basic processes, what happens if they mean something quite different by a TLA from the meaning I know for it? I am reminded of a comment to a friend's post about the abbreviation "Ind." as used to describe a meat pie: "individual", "industrial", or "indigestible"?
But there's usually a string of extras, methodologies and so on, and every time, I Google them, only to say "oh, that! been doing it for ten years, since when did it need a fancy name?"
The latest is a job which requires "Hands-on experience of ETL development". Googling takes me to Wkipedia (as it often does), where I am told that "ETL" means "Extract, transform, load". To go into more detail:
* Extracting data from outside sources
* Transforming it to fit operational needs (which can include quality levels)
* Loading it into the end target (database or data warehouse)
Well, duh. Yes, done a lot of that. But again, since when did that need a mysterious abbreviation? And why that abbreviation: the concept is one I learnt while looking at Jackson Structured Programming: think in terms of data. What have we got, what do we want, how do we get from one to the other? "JSP": only now, if someone talks about JSP in a job spec, they mean "Java Server Processes" - probably. It might, in certain contexts, be a Joint Service Publication, if I went back to dealing with engineering software for the MoD.
And there's the problem. If everyone's inventing TLAs for the most basic processes, what happens if they mean something quite different by a TLA from the meaning I know for it? I am reminded of a comment to a friend's post about the abbreviation "Ind." as used to describe a meat pie: "individual", "industrial", or "indigestible"?
no subject
Date: 2010-03-26 06:27 pm (UTC)no subject
Date: 2010-03-29 03:04 pm (UTC)