@RichardUie
"Live and learn" should have been "LEARN or DIE."
Lots o' languages, protocols, paradigms, libraries, platforms, databases. Trying to be agnostic.
Dunno. 'Bout July 1st, I'm prob'ly gonna be WAY busy, building a full-stack, Open Source, library system. Ask...no promises.
No blogs yet.
The teacher/employer analogy is a poor one. The teacher is not offering to pay you to provide services that support his company's reputation. Also, any teacher that you believe wants you to suck up by pretending to learn is not a teacher you want. Mark 's remark about not fooling some who knows the answer is dead-on. Really, reconsider the idea that BSing during an interview is good strategy. It ain't.
"...if you don't know, just freaking give it a go." Best remote phone interview I ever had - and that got me the job - included my confession of ignorance about a particular technology. "Best Interview" status was reported by both the consulting shop trying to place me, who were eavesdropping on the call, and the hiring shop. Be willing to be honestly ignorant when you ARE honestly ignorant.
I find better than mild hilarity in the extremity of difference in our approaches. I'm a very INTJ sort according to Myers-Briggs personality type measures. Misread you by more than a bit (except the last part...I too could 'a' been the guy promoting the change).
I have a queue of picks on my TODO list for reading, but goodness knows when I'll get to them. My list includes sci-fi, fantasy, natural history, scientific, technical...some of it re-reads. However, I'm currently comparing/contrasting/learning about FOSS library (you know, those buildings chock full o' printed books) software to identify a solution set for a small, relatively financially strapped library whose web pages are living in the 20th century. I can't even begin to deploy code before July due to organizational changes (new director takes charge in July), but I have zero experience in programming for public libraries, and there is much to learn about the business issues as well as potential FOSS solutions. In general, I like to read (I no longer own paper books - I donated all of them after building an e-library of thousands of "books"). Sometimes my reading requirement is as simple as words on a page - depends on where I am and what level of distraction I want. I read a lot of online news related to tech, science, and politics. Quick turnover, low time-commitment frequently matters most. Placing one, single BOOK title at the top of my TOREAD list... Mastering the Art of French Cooking by Julia Child.
Most of my initial tactics are among the following list. Some are more appropriate to one or the other type new tech, frameworks vs. languages. Some are more easily accomplished, depending on the nature of the existing population of adopters. I visit the project home site and read the docs. I read books. I check out online forums for the new framework/language, looking for friendliness toward and acceptance of newbies, general support, and Q&A responsiveness. For frameworks, I look for project bug lists and commit bandwidth. I search for articles that compare and contrast the new thing with something I already know. I locate pro/con presentations. I check locally to identify any existing in-house expertise - just 'cuz the tech is new to the shop in general doesn't mean it's new to everyone in the shop.
"In a SQL database, there is a schema that sets the rules for how tables are related to each other." You may be confusing the notion of schema as it relates to XML documents. Here's a good resource for how IBM DB2 deals with the idea of Schemas . "Rigid, predefined schema that needs to be updated for new columns" Simple ALTER TABLE operations can ADD (or DROP) columns and would rarely affect or be affected by a schema. ~ ~ ~ Days Later Without Reply... Well all-righty then, since Milecia seems uninclined to correct herself, I will re-emphasize what I said. Milecia's representations about schemas for RBDMSs are flatly wrong. Schemas serve very little purpose in RDBMSs other than providing namespace organization for collections of database objects - mainly, they prevent naming collisions and reserve certain organizational ideas, e.g., the SYSIBM schema for DB2. Columns are not database objects and would only influence or be influenced by schemas, if part or whole of an index (primary or foreign key or performance index...those, not simple columns ARE database objects) came into play, either deleting a column that was part of an index or adding a column that would become part of an index. Sorry, Milecia, be more careful when you attempt to teach. Especially, don't teach wrong stuff.