Better Training
-
Gary Varga (5/13/2014)
Do not fool yourselves into how only woefully unprepared graduate DBAs are. The same is true for developers. It's just that graduate developers generally have delusions of adequacy!!!Not me! When I graduated, I knew I couldn't program at all
Need an answer? No, you need a question
My blog at https://sqlkover.com.
MCSE Business Intelligence - Microsoft Data Platform MVP -
I remember our computer science degree was more like a software engineering lite. The Department head was not only a doctor of computer science, but also worked in the industry several years and did his undergraduate work in English (so your documentation had to be spot on as well). Combined with that, I was fortunate in that I was able to do some practical work for some engineers at the same manufacturing company during my college breaks and 1st few years of work life. And during the school year, I had a part time job in the colleges IT dept, doing data entry and other house keeping.
Had I not had the math and theory or even just had a business background, I do not think I would have been able to accomplish the things I did at that manufacturing company.
I wonder if it is not just the combination of school, and practice, but also a good mentor as well.
-- Optimist with experience and still learning
-
Steve Jones - SSC Editor (5/13/2014)
call.copse (5/13/2014)
I do think there should be a safe environment where students can learn the theory without being overly concerned about practicalities - this could be the first year of the degree. More practical exposure after that would ensure that students are not intimidated by real things and doing real work - while the theory continues.I guess here there is a problem with what the practical stuff might be - Java, .Net, T-SQL, Ruby on Rails, something less directly practical? My understanding is that Java is most common on undergrad courses, .Net is felt to be more sullied and 'vocational'. Still, as long as they stay away from PHP and Perl...
That's interesting. however, do we want the first or last year? When I started in CS, the first year was hard, really hard with theory and it weeded out people quickly. Seemed like a good way to raise quality.
However since then, I've thought that there are people that can learn to program and do well, but don't need the theory on how a quicksort works.
Having worked with a fair variety of programming types I can say weeding is a good plan - unfortunately there are not enough programmers with the right skills here right now. I'm trying to train up as many as I can but it's not quick work. Thing is even the best of programmers with the best of intentions can seem to leave behind code that is a little incoherent.
Of course there are a variety of roles to fill - I don't really even know how to categorise UI programmers who need to produce quite complicated code, but such types may well not really need sorting algorithms in their box of tricks. We are using a fair few more design oriented types who can do various types of fluid (responsive) layout. I think this is a relatively new role between design and back end programmer if you like, I'm sure there are numerous other types emerging. No mould will fit all cases I guess.
-
It depends on the exact profession but in my opinion nothing can replace a solid theoretical background. Especially with databases, because thinking in sets instead of records requires a mind shift that needs a whole new approach, and mister Edgar Codd gave us a perfect way to establish that solid background. Knowing when to use a LEFT OUTER JOIN or even a FULL OUTER JOIN instead of an INNER JOIN to get the correct results depends highly on your understanding of the model behind the data. In my years as DBA I had to correct so many subtle errors caused by lack of understanding the relational model, too often from people who learned how to spell SELECT from books that only address toy systems. If you do not learn the theory ahead of any practice, you probably never will, because you will have other priorities once you start to use it out there in the wild. Programmers have their own paradigms to deal with, like problem domains, inversion of control, unit of work and lots of patterns that you need to have in your backpack before you write the first letter of actual code.
Apart from teaching students theory and involving them in real world projects, there should also be some room for stuff that makes IT a little bit more attractive. Start a socker match between robots build by students, for example.
-
My early learning of programming (including database programming) used an iterative approach.
- First you would be taught the very basics i.e. theory of syntax (at such a simple level that just says everything you type matters).
- Next you would be shown a simple example of syntax; for programming something like output to console, for databases a SELECT statement.
- Then you would do an exercise on it in order to demonstrate ones understanding.
- Next you would be taught something further like the basics of relational theory and the associated syntax.
- Then you would do an exercise on simple joins using foreign keys i.e. INNER JOIN.
Obviously, the lecturers gauged what they could group together in order to ensure that appropriate use of classrooms and labs were used.
Unfortunately, most books are light on the theory as (to quote Koen) "it's boring". What the book purchasers like are the results on screen but they are unaware that they have been cheated from gaining true knowledge and understanding.
Gaz
-- Stop your grinnin' and drop your linen...they're everywhere!!!
call.copse (5/14/2014)
Having worked with a fair variety of programming types I can say weeding is a good plan - unfortunately there are not enough programmers with the right skills here right now. I'm trying to train up as many as I can but it's not quick work. Thing is even the best of programmers with the best of intentions can seem to leave behind code that is a little incoherent.
Of course there are a variety of roles to fill...
Yep, lots of roles.
The issue with weeding is that it tends to have a single funnel approach. You fit in, or get tossed to the side. That's not what we need in this business. If we're going to weed, based on some bar of qualification or skill, we need to be sure there are multiple ways or bars that can be met. We don't need Dr. Codd's or Bjorn Stroustrup's at every level. We need people at different levels.
vliet (5/14/2014)
It depends on the exact profession but in my opinion nothing can replace a solid theoretical background. Especially with databases, because thinking in sets instead of records requires a mind shift that needs a whole new approach, and mister Edgar Codd gave us a perfect way to establish that solid background. Knowing when to use a LEFT OUTER JOIN or even a FULL OUTER JOIN instead of an INNER JOIN to get the correct results depends highly on your understanding of the model behind the data.
I'm torn here. I think good solid basics in an area are important. However I'm not sure to what depth someone needs relational knowledge. There are lots of people that end up writing lots of CRUD, simple aggregates and basic report queries.
I think more we want to provide them with a way to understand when they're out of their depth. Maybe references on how much effort (resources) the computer should spend calculating problems per mm rows? Not sure.
Steve Jones - SSC Editor (5/14/2014)
I'm torn here. I think good solid basics in an area are important. However I'm not sure to what depth someone needs relational knowledge. There are lots of people that end up writing lots of CRUD, simple aggregates and basic report queries.
I think more we want to provide them with a way to understand when they're out of their depth. Maybe references on how much effort (resources) the computer should spend calculating problems per mm rows? Not sure.
I'd agree that people working in different fields will have differing requirements as to which areas they require deeper understanding but there are some basics which are fundemental and apply across pretty much all of IT.
One example of this is an understanding that computers store data in variables of finite length and use binary arithmetic and what the implications of that are. I wouldn't necessarily expect everyone to be able to multiply and divide in binary but it should be expected that they will know that floating point division may give an inexact result and how to address that.
Another applying particularly to SQL would be boolean algebra. How many times have there been questions posed where the poster is asking why they are missing results from a query because they do not understand how boolean operators - particularly AND and OR - combine.
Steve Jones - SSC Editor (5/14/2014)
call.copse (5/14/2014)
Having worked with a fair variety of programming types I can say weeding is a good plan - unfortunately there are not enough programmers with the right skills here right now. I'm trying to train up as many as I can but it's not quick work. Thing is even the best of programmers with the best of intentions can seem to leave behind code that is a little incoherent.
Of course there are a variety of roles to fill...
Yep, lots of roles.
The issue with weeding is that it tends to have a single funnel approach. You fit in, or get tossed to the side. That's not what we need in this business. If we're going to weed, based on some bar of qualification or skill, we need to be sure there are multiple ways or bars that can be met. We don't need Dr. Codd's or Bjorn Stroustrup's at every level. We need people at different levels.
I agree that a single funnel approach is wrong. Also, we do not want to put off the people who would do a reasonably decent job at the lower end (please remember that I do not rate the person as lower just their task(s) i.e. I have the upmost respect for bin men [non-gender specific garbage disposal engineers to you over the pond], toilet cleaners waiters/waitresses, support engineers, web developers etc. as individuals and for the job they do). We also do not want to bore the people who may become technology leaders. We need to give the individuals the chance to find out what they are good at and what they enjoy to allow them to select modules that are most appropriate.
Having said that, there are basic modules that ALL should do if only to understand that it is a difficult task so we can all have at least a little respect and understanding for those doing it and know to avoid that area personally.
Gaz
-- Stop your grinnin' and drop your linen...they're everywhere!!!
crmitchell (5/14/2014)
Steve Jones - SSC Editor (5/14/2014)
I'm torn here. I think good solid basics in an area are important. However I'm not sure to what depth someone needs relational knowledge. There are lots of people that end up writing lots of CRUD, simple aggregates and basic report queries.
I think more we want to provide them with a way to understand when they're out of their depth. Maybe references on how much effort (resources) the computer should spend calculating problems per mm rows? Not sure.
I'd agree that people working in different fields will have differing requirements as to which areas they require deeper understanding but there are some basics which are fundemental and apply across pretty much all of IT.
One example of this is an understanding that computers store data in variables of finite length and use binary arithmetic and what the implications of that are. I wouldn't necessarily expect everyone to be able to multiply and divide in binary but it should be expected that they will know that floating point division may give an inexact result and how to address that.
Another applying particularly to SQL would be boolean algebra. How many times have there been questions posed where the poster is asking why they are missing results from a query because they do not understand how boolean operators - particularly AND and OR - combine.
Not everyone needs to remember De Marco's theorem but everyone should understand that in most (if not all?) languages that precedents apply. That is why I use brackets even when I know that precedence will do the "right thing". At least the next developer can see not only the implementation but also the intention. Erm, and because sometimes I get things wrong 
Gaz
-- Stop your grinnin' and drop your linen...they're everywhere!!!
Jennifer Levy (5/13/2014)
Computer science degree from a liberal arts school here. Our major started with programming, the "weed-out" course (Assembly Language) was a 200-level one, as were the hard theory required courses. I do think that learning the theory behind what you're doing is a good thing as it explains why systems work better when you do things a certain way. And getting exposure to different languages helps you figure out how you learn best, which is always helpful given changes in technology and the job market.
CS rocks! I have found, IMHO, that the best developers/database pros understand the theory, and how the code works in the hardware. Basically, they get that they are just moving bits around. Then there are the developers who formerly were: copy repairman, photo salesperson, etc. And the best, the guy charging my car A/C was getting out of the business to be a developer!
Technologists are still caught between being a tradesperson or a professional. To be a professional, you need to really understand the underlying theory. The 'why', not just the 'how'. Now, the method for understanding the 'why' can vary. CS degree, or self-taught. does not matter. What does is that one understands the why.
The more you are prepared, the less you need it.
Viewing 11 posts - 46 through 55 (of 55 total)
You must be logged in to reply to this topic. Login to reply