[cdelgado5]

I am currently enrolled in a dual degree in database management and computer programming. I would just like to know what a day to day might be like. How would you describe the culture? What problems might new hires have with communication on the job. Are new people usually mentored or are thrown out to the wolves to fend for themselves. Just doing a little research to make sure this is what I want to do.

[modi123_1]

Quote

How would you describe the culture?

Depends on the company. Some are all sorts of touchie-feelie.. some are "we expect you to hit the ground running"... and some forget you in a long abandoned computer lab hidden in a labyrinth the on the first day. Go a head - ask me how I know. lol

Quote

What problems might new hires have with communication on the job.

Power lines, struggles, terminology, where everything is, historical cruft built up over the years, names, projects, etc. You know - pretty much how any new day goes for any job.

Quote

Are new people usually mentored or are thrown out to the wolves to fend for themselves

Again, depends on the company. (See line about being forgotten the first day and then extrapolate and extend that to another four months of viciously carving out respect and forging new paths as a tester when no one told you otherwise).

[e_i_pi]

In the places I've worked, there can be an expectation that the DB schemas don't need to be explained because they are set up right. Often they are not set up right, especially when you get multiple developers working on a project at once. A programmer is not necessarily a DBA and vice-versa, so sometimes you can look at a schema and think 'WTF'. Common issues I have found with looking at new schemas are:

• Does not meet normal form, sometimes not meeting even 1NF
  
• Incorrect/inconsistent datatypes used
  
• Lack of FK constraints where there should be constraints
  
• Legacy fields in tables that are no longer in use
  
• Bad practices in query design, exacerbated by copy-pasting when creating new views / SPs
  
• Misspelt fields
  
• Mixed standards (e.g. - 'my_table', 'myOtherTable', 'this.ID', 'this.thisID')
  
• Lack of documentation of the schema, especially in regards to "quick-fix" solutions, such as ad-lib indexes
  
• Lack of database diagrams
  
• No-one knows why a certain practice has been implemented / cannot remember when it was implemented
  
• Problems with version control around differnet versions of a DB
  
• Issues arise from your Dev environment having different specs to the client's Prod environment
  
• Client upgrades Prod environment without notifying developers beforehand, resulting in application crashing due to not being future-ready
  
• Client's IT department decides they know what's best, and start meddling with the data / indexes. Client's CEO calls you and starts screaming about the app no longer working.
  
• Dirty data is the rule, not the exception
  
• Problems with external systems getting pushed onto the DB guys (e.g. - external system runs in data that hasn't been cleaned properly - instead of fixing the app, the DB team now have to clean the data as well)

This is in my short and limited experience, and what I can think of off-hand. It's a job, there's challenges, it's how you're treated by your co-workers and boss, and how you manage the workload / stress that's important. Keep yourself sane, and you'll do fine.