Post #75,535
1/19/03 3:42:28 PM
8/21/07 6:27:45 AM
|
Not
Would you say the same thing about a high level database programmer (hmm, Smalltalk / Oracle maybe?) going for a realtime robotic TonyTib type of job?
I can do either. I'm equally good at low level C as high level Smalltalk. Sadly, I don't have enough low level C *work* on my resume and I'm sick of doing web apps - but thats all I'm getting offers on. I'd welcome a TonyTib type gig. I need a change of pace.
RE: Business Analyst - its just a system, right? Its the same job. I'd also point out that my usual role is architect - which means I already did the analysis to get you your database in the first place - so I'd guess I could figure out a new one with about the same effort (unless its completely wacked - which happens).
What was your point again?
I think that it's extraordinarily important that we in computer science keep fun in computing. When it started out, it was an awful lot of fun. Of course, the paying customer got shafted every now and then, and after a while we began to take their complaints seriously. We began to feel as if we really were responsible for the successful, error-free perfect use of these machines. I don't think we are. I think we're responsible for stretching them, setting them off in new directions, and keeping fun in the house. I hope the field of computer science never loses its sense of fun. Above all, I hope we don't become missionaries. Don't feel as if you're Bible salesmen. The world has too many of those already. What you know about computing other people will learn. Don't feel as if the key to successful computing is only in your hands. What's in your hands, I think and hope, is intelligence: the ability to see the machine as more than when you were first led up to it, that you can make it more.
--Alan Perlis
|
Post #75,561
1/19/03 6:01:06 PM
|
Well, it still depends on the person's abilities
My statement for custom machines / robotic programming:
I'd rather hire ME or EE who is interested in automation & teach them how to program than hire a CS guy who is interested in programming only. In fact, I've already seen one ME become a successful embedded programmer (in Perl and C/C++).
OTOH, if you are a good programming, such as Todd, and do have the interest in the end result, then you should do quite well.
For factory automation, another requirement is the ability to deal with the vendors' favorite programming languages, which vary from horrible (PLC code done wrong, Animatics, Galil, & most other motion control vendors) to OK (PLC done right -- and the Euro standard (IEC 61131) is a big improvement) to decent (e.g. Adept, C, VB). Fortunately, I get to spend a lot of time writing Python code.
Frankly, having experience with more dynamic languages (e.g. Smalltalk, Python) is a big plus; I know after using Python I'll program in C/C++ better.
My understanding is that in the overall embedded marked (e.g. stuff using RTOS or on small, memory limited systems) C & C++ are the dominant languages.
We hopefully will be hiring one programmer this quarter, but not yet (and to be honest, people with a strong connection to the current employees have an edge).
In any case, good luck.
Tony
|
Post #75,592
1/19/03 9:20:07 PM
|
Just a system?
Heart lung.
Steam engine.
Economic.
Nuclear pressure release.
Transaction processing database.
Heavily regulated, state by state,
county by county, city by city, mortgage
marketing that is dependent on interest
rates, economic outlook, debt load,
political situation, and the phase of
the moon.
I'm hiring for the last one. For some
reason it seems that as technical people
we deem it our area if certain software
expertise is required. If the expertise
crosses into some light programming, even
more so. A BO person is not a programmer.
Programming is a side effort, like a
spreadsheet jockey who grows to writing
macros.
Industry and regulatory knowledge is
probably more important than the software
aspect. But the BO knowledge will get them
in the door.
|
Post #75,611
1/20/03 4:28:59 AM
8/21/07 6:29:24 AM
|
Yep
Look, I see sort of what you are saying.
But if I follow your logic, then I'm not qualified to build your enterprise systems either. Nor is anyone else who designs software rather than pushes paper.
Thats just not true.
For stuff like this, you often have to pair people. I have built systems that take customer order entry for both residential, and business and government phone service orders (totally different domains), managed network inventory, automated provisioning of service, created a marketplace for language translation services with timing constraints, managed repair personnel and maintenance cycles, created web based questionaires, provided career lifecycle tracking in Europe, and automated a truck rental business (to name a few).
For most of these I designed the database schemas, the business objects, chunks of the UI, and the deployment structure of the system. What did I know about all of these domains going in?
Not a mother fucking thing. So I get me a SME (you need a SME - Subject Matter Expert) and I interrogate him/her until I do understand the constraints - regulatory, legal, business, financial, whatever. Its still not that hard - just time consuming.
This is different from building business software and doing data analysis for your company how?
I don't buy it. You said "We are currently looking for a Business Objects person."
If you really think you need a domain expert that happens to know Business Objects, you ought to put it that way. But thats not what you said. So far, I don't even know what domain your business is but you've mentioned the key skill is Busineess Objects. If what you say is true, then a Business Objects person isn't going to cut it either - they have to be a Business Objects person IN YOUR DOMAIN (which you still haven't mentioned).
See the disconnect? Its overly fussy. A good architect would do you if paired with a SME, or a good analyst in your domain could be paired with a decent developer. But to me its no surprise you're not finding what you want as you're not asking for what you need.
I think that it's extraordinarily important that we in computer science keep fun in computing. When it started out, it was an awful lot of fun. Of course, the paying customer got shafted every now and then, and after a while we began to take their complaints seriously. We began to feel as if we really were responsible for the successful, error-free perfect use of these machines. I don't think we are. I think we're responsible for stretching them, setting them off in new directions, and keeping fun in the house. I hope the field of computer science never loses its sense of fun. Above all, I hope we don't become missionaries. Don't feel as if you're Bible salesmen. The world has too many of those already. What you know about computing other people will learn. Don't feel as if the key to successful computing is only in your hands. What's in your hands, I think and hope, is intelligence: the ability to see the machine as more than when you were first led up to it, that you can make it more.
--Alan Perlis
|
Post #75,614
1/20/03 5:31:36 AM
|
Yep
The BO person I sort of knew never talked about business issues - he was always directly invovled with the DBA - this sounds more like a computer person.
He was very sharply dressed and fastidious.
-drl
|
Post #75,773
1/20/03 7:26:24 PM
|
OK, time to take my beating
You are right.
I am really looking for a person with domain experience if possible, who knows stats, and who has BO experience.
The combination of the stats and the BO would get you through the door, since the BO is really a tool to apply the stats knowledge, while the domain experience (mortgage) would be nice but is certainly not a requirement.
Is this clear enough?
|
Post #75,801
1/20/03 8:56:47 PM
8/21/07 6:33:52 AM
|
Cool
Now if we could just get the headhunters to behave accordingly we might all get a chance at food on the table.
I think that it's extraordinarily important that we in computer science keep fun in computing. When it started out, it was an awful lot of fun. Of course, the paying customer got shafted every now and then, and after a while we began to take their complaints seriously. We began to feel as if we really were responsible for the successful, error-free perfect use of these machines. I don't think we are. I think we're responsible for stretching them, setting them off in new directions, and keeping fun in the house. I hope the field of computer science never loses its sense of fun. Above all, I hope we don't become missionaries. Don't feel as if you're Bible salesmen. The world has too many of those already. What you know about computing other people will learn. Don't feel as if the key to successful computing is only in your hands. What's in your hands, I think and hope, is intelligence: the ability to see the machine as more than when you were first led up to it, that you can make it more.
--Alan Perlis
|
Post #76,446
1/23/03 4:39:31 PM
|
Re: OK, time to take my beating
I'm Confused.
You talk about BO and transaction processing in the same sentence as if you want to run those on the same box.
It's possible to do BO ( Data Warehouse ) and TP on the same box, but both kind of get compromised.
If you're serious TP (like me), then some things don't work well from the data warehouse world, like ROLLUPS and CUBES. At least you can't run them with your TP load. You have to run data warehouse stuff outside your prime TP processing window (eg. at night ). My take is that BO, Cognos, and MicroStrategy allow a business analyst to make data warehouse-like queries ( ROLLUPS and CUBES ) on a system.
So, if you're not careful, you're TP workload goes to hell in a handbasket as your business analyst is doing table scans to look at all the records for the summaries the VP wants, in the middle of the afternoon.
Maybe, if you have a big enough box, you don't care. But for our applications, the TP stuff has to add less than 1/2 second to our response time, and running data-warehouse queries puts us into 10-15 second response times very quickly.
Glen Austin
|
