November 11, 2015 at 7:54 am
ccd3000 (9/29/2015)
Well, I.T. hijacked and cheapened the 'Engineer' moniker a long time ago so why not 'Scientist'? Most of the I.T. "Engineers" I've worked in the past are no more engineers than I'm an astronaut. I've actually worked alongside real engineers in the nuclear energy field and they have this affection for methodology that is far too rarely seen anymore in I.T. and I doubt the newly minted "scientists" will raise the bar much. I have to admit I'm a little jealous. "Scientist" is so much more sexier than "Administrator". It's like "Sage" is to "Librarian". CERN probably has some real Data Scientists.
...and architect!!!
Which in England and Wales is technically illegal as it is a protected term but I will brave it out 😉
Gaz
-- Stop your grinnin' and drop your linen...they're everywhere!!!
November 11, 2015 at 7:57 am
Steve Jones - SSC Editor (10/1/2015)
I do usually tell people in Scouts or kids sports that I'm a computer guy. If they know something and want to ask more, I will talk about databases.
If I am a party I have been known to claim to be an astronaut as it is obvious that I am not and I avoid the "Oh great, I have this little problem you will know how to help me with...I want to connect my train set to my 48k Spectrum" moments.
Gaz
-- Stop your grinnin' and drop your linen...they're everywhere!!!
November 11, 2015 at 2:58 pm
Sorry, I think being a real 'data scientist' has very little to do with holding a post-graduate degree. It has to do with innate, intuitive, instinctive, empathetic understanding of data and relationships and how they interact. And also the same understanding of people and how they will and should interact with such data. I don't think this necessarily is taught or is inherent in obtaining a degree.
I'll give an example I've witnessed lately: Our city had a very efficient 4-lane street with maybe eight stoplights between downtown and the airport maybe 4 or 5 miles apart. This street had worked very well for decades as it was. It served a considerable amount of traffic including busses and trucks.
This summer they began a project to 'improve' this thoroughfare. First, they took space for on-street parking on both sides of the street. Then they added bicycle lanes on alternating sides of the street although I've never seen anyone risk their lives on a bicycle. Then they added a center turn lane all the way through the route.
Now the street is single lanes each way and very congested due to the heavy usage of four lanes combined into the two. It gets really bad when school busses stop all traffic for pick up and drop off, city busses have to cross the bicycle lanes to do the same. You almost never see anyone actually parking in the new parking lanes, because the neighborhood is nearly 100% residential with driveways and small businesses with parking lots of their own.
I'm fairly sure the city has traffic engineers with advanced degrees analyzing data and designing these projects and spending this money with disastrous results because they have all the training and theory down pat but lack the understanding and empathy for the way things will really work.
Over my career I saw many computer systems designed exactly this way too. Absolutely no understanding of how the user understood and worked with their data. I even worked for one company whose owner and president dictated that there should be absolutely NO constraints on technical and engineering folks being allowed to enter any data they desired, valid or invalid, from which the computer was expected to produce designs for blueprints. You should have seen the results of drawings that wandered all over town.
Data Scientist? My take is that it's maybe 10% degrees and 90% innate understanding and ability and empathy.
Rick
Disaster Recovery = Backup ( Backup ( Your Backup ) )
November 12, 2015 at 3:42 am
skeleton567 (11/11/2015)
I'm fairly sure the city has traffic engineers with advanced degrees analyzing data and designing these projects and spending this money with disastrous results because they have all the training and theory down pat but lack the understanding and empathy for the way things will really work.
My experience with traffic engineers is that they ought to be forbidden to call themselves "traffic engineer" (or indeed any sort of engineer). As far as I am aware none of them could legally use the title "Incorporated Engineer" or "Chartered Engineer" or "European Engineer" (unfortunately the title "traffic engineer" has no legal protection in the UK, anyone can use it, qualified or not). Given their amazing inclination to be happy with demonstrably incorrect mathematics I suspect they have no serious education in any technical subject at all.
Over my career I saw many computer systems designed exactly this way too. Absolutely no understanding of how the user understood and worked with their data.
Well, people calling themselves "software engineers" or "computer engineers" are mostly (a least in the UK - those are not protected titles in the UK) completely unqualified - maybe they have a degree from a 3rd rate University that taught them bad programming techniques in a really appallingly designed language like C++ (and in the USA some universities are still using BASIC, I'm not sure whether that's better or worse) which is more a disqualification that a qualification. Unfortunately those of us with real engineering qualifications are sometimes assumed to be as incompetent as these charlatans.
Tom
November 12, 2015 at 4:28 am
skeleton567 (11/11/2015)
Over my career I saw many computer systems designed exactly this way too. Absolutely no understanding of how the user understood and worked with their data.
One of the biggest complaints I received over my 30 year career has been due to poorly designed (or rather, not designed) user interfaces. In includes not just GUI screens but overall how people are expected to interact with a data system. I learned to observe people at their jobs, what they needed, and how to design systems appropriate to the users to maximize the value and experience. In more recent years, this seems to have given way to cumbersome interfaces that were easy for the developer (probably through generic screen generators) and a nightmare for the user. This has resulted in ineffective use of the system, user apathy for data quality, and subsequently overall lower value. This seems especially true in healthcare where data quality and accuracy is critical!
LinkedIn: https://www.linkedin.com/in/sqlrv
Website: https://www.sqlrv.com
November 12, 2015 at 6:15 am
[/quote]
Well, people calling themselves "software engineers" or "computer engineers" are mostly (a least in the UK - those are not protected titles in the UK) completely unqualified - maybe they have a degree from a 3rd rate University that taught them bad programming techniques in a really appallingly designed language like C++ (and in the USA some universities are still using BASIC, I'm not sure whether that's better or worse) which is more a disqualification that a qualification. Unfortunately those of us with real engineering qualifications are sometimes assumed to be as incompetent as these charlatans.[/quote]
Interesting take on C++ and VB languages. I'm interested in what language you use. Should I assume Fortran for engineering? Or has the engineering discipline moved to something else?
I used C extensively, but can't really say I was proficient in C++ or VB, just never experienced a 'forced need to know' on the job. My Fortran experience began when I interviewed for a position with the company I mentioned earlier where they needed Fortran, so I told them that by the time I had an offer and started work I would know Fortran. I got a PC version of Fortran, got books, spent the next three weeks in a crash course on my own, and ended up creating and supporting Fortran code for their design staff. Fortunately their existing all-custom software had been written by a very skilled engineering consultant so I had really good examples to learn further. We interfaced to Ingres database software which at that time was the absolute worst DB system I ever had to use.
Rick
Disaster Recovery = Backup ( Backup ( Your Backup ) )
November 13, 2015 at 10:04 am
skeleton567 (11/12/2015)
Well, people calling themselves "software engineers" or "computer engineers" are mostly (a least in the UK - those are not protected titles in the UK) completely unqualified - maybe they have a degree from a 3rd rate University that taught them bad programming techniques in a really appallingly designed language like C++ (and in the USA some universities are still using BASIC, I'm not sure whether that's better or worse) which is more a disqualification that a qualification. Unfortunately those of us with real engineering qualifications are sometimes assumed to be as incompetent as these charlatans.[/quote]
Interesting take on C++ and VB languages. I'm interested in what language you use. Should I assume Fortran for engineering? Or has the engineering discipline moved to something else?
[/quote]
Actually I didn't mean VB (or either of its successors). I don't really know enough about VB to say whether it's a reasonable language or not, but I do know enough about it (having used it a little) to recognise that it is very different from the sort of Basic I was thinking of. Back in the 1990s and in the early 2000s I was running into young Americans who had been taught a dialect of Basic not enormously different from the original Dartmouth Basic (a language dating from the early 60s), and that's what I was referring to. The reason that that might be better than C++ is that it's a language with far fewer features that C++ so it is impossible for it to have got as many things wrong. Visual Basic is very different, it's a language that has moved on a great deal from it's primitive ancestor and although the IDE for VB has been defunct for 7 years, replaced by VB.NET and VBA, it's still a very popular language - indeed MS says VB 6.0 apps should still work on the latest operating systems despite the withdrawal of official support for the IDE back in 2008 - so I suspect it's actually better than C++. I've written some fairly heavyweight stuff in C++ so I know that doing that in such an ill-constructed language is a real pain, but I've never written anything longer than about 10 lines in VB (if I did it probably wouldn't run) so I don't know how good or bad it is.
I use whatever language is appropriate for what I'm doing. For handling Active-X objects or similar stuff that used to be be JavaScript for me, rather than VB, simply because JavaScript was less different from what I had used before (incidentally, JavaScript is in no way related to Java, a language that I dislike intensely because I've seen too many projects fail because they tried to use it). For handling a database I rather like SQL. For general purpose programming I'd go for an ML dialect or Haskell or Miranda or even Hope+, for logic programming or constraint solving something like Prolog or Parlog. Decades ago (1970s) I sometimes advocated throwing together special-purpose programming languages designed for specific tasks, and my team had some great successes using that approach where it was appropriate. I also used an Algol 68 dialect rather a lot for data communications, for operating system components (both ICL and Burroughs wrote mainframe operating systems in dialects of Algol 68), and for simulations. Earlier than that I had used mostly various assembly languages and some Fortran.
I used C extensively, but can't really say I was proficient in C++ or VB, just never experienced a 'forced need to know' on the job. My Fortran experience began when I interviewed for a position with the company I mentioned earlier where they needed Fortran, so I told them that by the time I had an offer and started work I would know Fortran. I got a PC version of Fortran, got books, spent the next three weeks in a crash course on my own, and ended up creating and supporting Fortran code for their design staff. Fortunately their existing all-custom software had been written by a very skilled engineering consultant so I had really good examples to learn further. We interfaced to Ingres database software which at that time was the absolute worst DB system I ever had to use.
Fortran is another language that has changed greatly over the years. It took some damage from ill-judged compromises in the standardisation process early on (Fortran IV and ANS X3.4.3 FORTRAN caused a big step back in facilities and features compare to many earlier versions, reportedly because the big manufacturer - IBM - was not prepared to countenance a standard that included any features they hadn't already implemented so the standard had to leave a lot of things out that others had had for years) but eventually it recovered and moved a long way forwards.
Tom
Viewing 7 posts - 31 through 36 (of 36 total)
You must be logged in to reply to this topic. Login to reply