 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 06/09/2012 10:56 PM, Francois Labreque wrote:
>>>> The thing is, I can't think of any career that makes use of an ability
>>>> to memorise and apply pointless algorithms...
>>>
>>> Off the top of my head:
>>
>>> research
>>
>> Seriously? That's a career? Talk about "vague"...
>>
>
> Every company that manufactures stuff has a R&D dept. Every university
> has professors doing a lot of R and a little D to pay for more R.
OK, well "research" is rather vague. It could mean almost /anything/.
"Motor design research" sounds like something that could be an actual
career.
> You already have some chemical knowledge acquired by osmosis, why not
> try to focus on bio-tech or pharmaceutical companies?
Because the bio-tech industry is going south in a big way currently.
(Actually, this arguably applies to /every/ industry right now...)
>>> finance
>>
>> Wouldn't I need extensive finance qualifications to do that?
>
> To become a floor trader at the stock exchange, sure. But to crunch the
> mountains of numbers that the financial industry needs to crunch, no.
It's interesting; one of the careers advisors I went to see advised me
to go into financial modelling. Trouble is, when I looked into it,
nobody is the slightest bit interested unless you have a PhD.
Also, the financial industry is kind of ground-zero of the current
global recession...
>>> crypto/security
>>
>> Seriously, almost *nobody* actually does that.
>>
>
> Right. And encryption/decryption algoritms sprout from trees?
From what I've seen, there are, like, three academics globally who
write the vast majority of this stuff. And there are already /way/ more
ciphers in existence than anybody actually wants or needs.
>>> logistics
>>
>> Really? I'm sure it's difficult keeping track of stuff, but I don't see
>> much technical detail involved. It's just about keeping track of a lot
>> of stuff all at once. It's hard, but it isn't very technical.
>
> Planning bus routes, garbabe disposal truck routes, snow removal routes,
> etc... are not exactly trivial.
I didn't say it's /easy/, I said it isn't very /technical/. It's
difficult for mundane, real-world reasons, not because the maths is hard.
> Operational reasearch is a field
> of mathematics that is quite active, and those mathematicians need
> programmers who also can understand them. You'd fit nicely.
Really? There's actually mathematics involved in remembering to do stuff?
>>> data mining
>>
>> Does anybody actually do that? I thought it was just a fashionable
>> middle management buzzword.
>
> See airline example above. They don't decide to put an Airbus 319 or 388
> on each flight just for the fun of it. There's very extensive data
> analysis that goes in to determine the best aircraft size for a
> particular flight, and that analysis comes from crunching as much of the
> previous passenger stats they can. Most industries also do so at all
> levels to see how many widgets to pre-order to keep the aseembly line
> running, without having to pay for a larger than necessary warehouse.
> When to time your yearly discounts, how to target your advertizing
> campaigns. Etc...
All of that sounds to me like an extremely specialised, extremely small
niche role that would be almost impossible to get hired for.
>>> robotics
>>
>> Is there any commercial application for that?
>>
>
> Apart from all the manufacturing that's done by automation, even today's
> dishwashers have programmable controllers that can sense the dirtiness
> of the dishes and adjust the cycles accordingly. If I was named Sarah
> Connor, I'd be worried at the moment.
Sure, there are autonomous machines all around us. I don't think that
designing or programming them requires a vast amount of technical
knowledge - just extensive testing and experimentation.
>>> communications
>>
>> From what I've seen, installing comms equipment doesn't require a great
>> deal of technical skill - you just need to be good at carrying stuff
>> around and running cables.
>
> Right. That's because the shmuck who has to go onsite to run the cables
> isn't the one who has to keep them running. It's like if you'd said
> "mechanical engineering doesn't look that hard... I mean the guy at the
> gas station barely does anything".
Again, "communications" could mean just about anything.
If you mean the 3 people on Earth who design the protocol stacks...
well, those have already been designed. And we already have the 3 people
who design them.
If you mean the people who design switches and routers and so forth...
then there's maybe, what, 6 companies globally who make the hardware for
that. And it's already been designed. And they already have the 20 or so
employees each who do that work, so they aren't hiring. And besides, I'm
no electrical engineer.
If you mean something else...
>>> disaster response
>>
>> What kind of disaster response requires technical skill?
>
> Planning to avoid them, and planning to deal with them when they can't
> be avoided. And dealing with them once you're knee deep in the water and
> the roof has flown 5 miles away. all of these steps require as much, if
> not more, technical-know how than heavy lifting.
When I wrote our disaster recovery plan, it was /way/ easier than a
trivial programming exercise.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>> Manufacturing uses robotics in a huge way.
>
> OK. But those robots already exist. Why would you ever need to design more?
Competition. If you don't design new robots that are faster, more
accurate, more versatile and cheaper than your previous generation, your
customers will buy their robots from someone who has designed new ones.
It's the same for pretty much every product.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>> Planning bus routes, garbabe disposal truck routes, snow removal routes,
>> etc... are not exactly trivial.
>
> I didn't say it's /easy/, I said it isn't very /technical/. It's
> difficult for mundane, real-world reasons, not because the maths is hard.
The skills needed are how to translate the real world situation to a
mathematical model, and then knowing which tools to use to
optimise/solve it. Most of the time that is not trivial from a
mathematical point of view.
A very simple example is staff rotas, you have a certain number of staff
that all have contracted hours, you have a requirement for a certain
number of staff each hour each day, how to minimise overtime costs and
maintain enough cover? It's not the sort of thing you can solve in 5
minutes on Excel, or even write a trivial brute force search for (unless
you have a supercomputer). If you are able to save a few % of overtime
pay for a large company that equals lots of $$$.
Another example is which products to make on a production line. You know
the order numbers, the stock levels, how long it takes to change over
each cell/machine etc, what is the optimum pattern of production to
maximise profit?
Those seem to me like the sort of things you would be good at and enjoy.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> The skills needed are how to translate the real world situation to a
> mathematical model, and then knowing which tools to use to
> optimise/solve it. Most of the time that is not trivial from a
> mathematical point of view.
>
> A very simple example is staff rotas, you have a certain number of staff
> that all have contracted hours, you have a requirement for a certain
> number of staff each hour each day, how to minimise overtime costs and
> maintain enough cover? It's not the sort of thing you can solve in 5
> minutes on Excel, or even write a trivial brute force search for (unless
> you have a supercomputer). If you are able to save a few % of overtime
> pay for a large company that equals lots of $$$.
>
> Another example is which products to make on a production line. You know
> the order numbers, the stock levels, how long it takes to change over
> each cell/machine etc, what is the optimum pattern of production to
> maximise profit?
>
> Those seem to me like the sort of things you would be good at and enjoy.
Those seem to me like the sort of things that get worked out, once and
for all, and then maybe changed perhaps twice per decade. Not the sort
of thing you hire a full time employee for.
And for that matter, if I can't get employment as a computer programmer
- something which is in great demand and which I am provably good at -
what are the chances of me getting hired for an obscure job that almost
nobody needs which I'm probably not even very good at?
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> Those seem to me like the sort of things that get worked out, once and
> for all, and then maybe changed perhaps twice per decade. Not the sort
> of thing you hire a full time employee for.
From my experience those sorts of things are always under continuous
development. Like there will be a list of additions and changes that is
never ending (because items are added faster than the people can
implement them). Again, part of the skill is trying to predict how
general to make the optimisation, as often the management won't be much
help (they'll come back and demand you implement some feature they
plainly said they would never ever want 3 months earlier).
> And for that matter, if I can't get employment as a computer programmer
> - something which is in great demand and which I am provably good at -
I think there's a difference between coding what someone else tells you
to, and coming up with the ideas yourself. I would have you'd be much
better (and find more enjoyable) the latter.
> what are the chances of me getting hired for an obscure job that almost
> nobody needs which I'm probably not even very good at?
You're probably better off trying to get in to a large company as
something vaguely IT related and then finding ways to show off your
skills. That's often how it works.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>> what are the chances of me getting hired for an obscure job that almost
>> nobody needs which I'm probably not even very good at?
>
> You're probably better off trying to get in to a large company as
> something vaguely IT related and then finding ways to show off your
> skills. That's often how it works.
Interestingly, the last two interviews I've been to have both been
companies that said "We're quite small, but we're growing. We think we
need more people, but we haven't really decided exactly what we want
yet." It /looks/ as if those are the sorts of places where you might be
able to dictate your own terms.
On the other hand, most small companies probably don't know who is or
isn't a rare find quite so well as a big company. And small companies
have no need to optimise tiny details of their operations; a small
improvement multiplied by a small number is a small profit. A small
improvement multiplied by a frickin' HUGE number represents a
substantial profit...
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> Interestingly, the last two interviews I've been to have both been
> companies that said "We're quite small, but we're growing. We think we
> need more people, but we haven't really decided exactly what we want
> yet." It /looks/ as if those are the sorts of places where you might be
> able to dictate your own terms.
True, the other way to look at it is that in large companies there is
more scope to move about and work on different (=more interesting) things.
> On the other hand, most small companies probably don't know who is or
> isn't a rare find quite so well as a big company. And small companies
> have no need to optimise tiny details of their operations; a small
> improvement multiplied by a small number is a small profit. A small
> improvement multiplied by a frickin' HUGE number represents a
> substantial profit...
And don't forget in the end the company interviewing you is looking at
you as an investment. Will you make more money for the company than the
amount they have to pay you.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> On 06/09/2012 10:56 PM, Francois Labreque wrote:
>> You already have some chemical knowledge acquired by osmosis, why not
>> try to focus on bio-tech or pharmaceutical companies?
>
> Because the bio-tech industry is going south in a big way currently.
> (Actually, this arguably applies to /every/ industry right now...)
>
They still have job openings. Are you looking to put food on your table
next week, of for a career that will last until you retire?
>> Right. And encryption/decryption algoritms sprout from trees?
>
> From what I've seen, there are, like, three academics globally who
> write the vast majority of this stuff. And there are already /way/ more
> ciphers in existence than anybody actually wants or needs.
>
Ok. And no one ever needs to implement those algorithms?
>>>> logistics
>>>
>>> Really? I'm sure it's difficult keeping track of stuff, but I don't see
>>> much technical detail involved. It's just about keeping track of a lot
>>> of stuff all at once. It's hard, but it isn't very technical.
>>
>> Planning bus routes, garbabe disposal truck routes, snow removal routes,
>> etc... are not exactly trivial.
>
> I didn't say it's /easy/, I said it isn't very /technical/. It's
> difficult for mundane, real-world reasons, not because the maths is hard.
>
>> Operational reasearch is a field
>> of mathematics that is quite active, and those mathematicians need
>> programmers who also can understand them. You'd fit nicely.
>
> Really? There's actually mathematics involved in remembering to do stuff?
>
http://lmgtfy.com/?q=operational+research
Remembering to do stuff is only part of it. Doing all of the stuff
efficiently is a lot harder. You have to optimize the routes so that
each truck picks as much garbage as possible without having to reuse the
same street (to save fuel, and because old ladies complain about the
racket), to minimize the number of trucks used (to save moeny on
maintenance and crew salaries) and to minimize the time it takes to the
job (again old ladies complaining about trash bins on the sidewalks).
>>>> data mining
>>>
>>> Does anybody actually do that? I thought it was just a fashionable
>>> middle management buzzword.
>>
>> See airline example above. They don't decide to put an Airbus 319 or 388
>> on each flight just for the fun of it. There's very extensive data
>> analysis that goes in to determine the best aircraft size for a
>> particular flight, and that analysis comes from crunching as much of the
>> previous passenger stats they can. Most industries also do so at all
>> levels to see how many widgets to pre-order to keep the aseembly line
>> running, without having to pay for a larger than necessary warehouse.
>> When to time your yearly discounts, how to target your advertizing
>> campaigns. Etc...
>
> All of that sounds to me like an extremely specialised, extremely small
> niche role that would be almost impossible to get hired for.
>
Who cares if it's almost impossible to get hired? You can still try.
The worst that can come out of it is that you get told "no".
I used one example. There are many more. You said in another reply
that you thought the biggest problem was asking the right question.
It's more than that. It's asking the right question in the right order.
'SELECT name, phonenumber, sex, age, status FROM TABLE
MiltonKeynesResidents WHERE sex = "f" AND (age > 18 AND age < 29) AND
status = "single"' will return results a lot faster if you first get
only the 18-29 age bracket, because it then makes a smaller subset of
the population for which to check their status or sex. Moreover, if you
add other criteria such as 'WHERE father.sport <> "karate"' optimizing
the queries properly can give you much faster results (Apologies if the
SQL is nessed up).
You did say you had Oracle experience. Even if you don't have a lot of
experience with it, you could look for DBA jobs, or even jobs where
they're looking for Crystal Reports knowledge. This means they want
someone to produce nice-looking reports from a DB backend. you could
use this as to get your foot in the door, and then move up from there.
>>>> robotics
>>>
>>> Is there any commercial application for that?
>>>
>>
>> Apart from all the manufacturing that's done by automation, even today's
>> dishwashers have programmable controllers that can sense the dirtiness
>> of the dishes and adjust the cycles accordingly. If I was named Sarah
>> Connor, I'd be worried at the moment.
>
> Sure, there are autonomous machines all around us. I don't think that
> designing or programming them requires a vast amount of technical
> knowledge - just extensive testing and experimentation.
>
Nope, no technical knowledge at all. Just farting around with legos.
http://s1.lemde.fr/image/2012/08/02/540x0/1741894_5_d417_le-nouveau-rover-martien-de-la-nasa-curiosity_9df653ffb46806f83c2f7d6e1516a8d1.jpg
Seriously. STOP WITH THE PRECONCIEVED NOTIONS. Unlearn everything, you
must.
>>>> communications
>>>
>>> From what I've seen, installing comms equipment doesn't require a great
>>> deal of technical skill - you just need to be good at carrying stuff
>>> around and running cables.
>>
>> Right. That's because the shmuck who has to go onsite to run the cables
>> isn't the one who has to keep them running. It's like if you'd said
>> "mechanical engineering doesn't look that hard... I mean the guy at the
>> gas station barely does anything".
>
> Again, "communications" could mean just about anything.
>
> If you mean the 3 people on Earth who design the protocol stacks...
> well, those have already been designed. And we already have the 3 people
> who design them.
>
> If you mean the people who design switches and routers and so forth...
> then there's maybe, what, 6 companies globally who make the hardware for
> that. And it's already been designed. And they already have the 20 or so
> employees each who do that work, so they aren't hiring. And besides, I'm
> no electrical engineer.
>
What about the millions of companies that USE those equipment? You've
already said in this forum that it was impossibly complicated to program
a Cisco switch, yet here you are saying the exact opposite! I get that
it may not be your favorite field of work, nor your best field of
expertise, but at least be constistent in your dismissal of it!
> If you mean something else...
>
>>>> disaster response
>>>
>>> What kind of disaster response requires technical skill?
>>
>> Planning to avoid them, and planning to deal with them when they can't
>> be avoided. And dealing with them once you're knee deep in the water and
>> the roof has flown 5 miles away. all of these steps require as much, if
>> not more, technical-know how than heavy lifting.
>
> When I wrote our disaster recovery plan, it was /way/ easier than a
> trivial programming exercise.
How many 9s of uptime did your company require? "we can live with being
offline for a few days" is not the same thing as "99.999% uptime or we
will be Fukushima'ed".
All kidding aside, as I've said in earlier replies, I've had to do lots
of hiring in the past - and dated a HR rep for a few years - so send me
your C.V. and a typical presentation letter, I'll see if there's
something you could easily improve with them.
--
/*Francois Labreque*/#local a=x+y;#local b=x+a;#local c=a+b;#macro P(F//
/* flabreque */L)polygon{5,F,F+z,L+z,L,F pigment{rgb 9}}#end union
/* @ */{P(0,a)P(a,b)P(b,c)P(2*a,2*b)P(2*b,b+c)P(b+c,<2,3>)
/* gmail.com */}camera{orthographic location<6,1.25,-6>look_at a }
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> Sure, there are autonomous machines all around us. I don't think that
> designing or programming them requires a vast amount of technical
> knowledge - just extensive testing and experimentation.
That's a very bad way to design products, it's expensive and time
consuming, and liable to create a product with lots of bugs you don't
find until they're out in the field. Far better to get people with vast
technical knowledge to properly design the product in the first place,
the actual product testing should just be a formality, not a tool to
find the best design.
But don't worry, you're not alone in underestimating the amount of
design work that goes into everyday products. Once you've been to a few
conferences on design and simulation software you realise that nothing
is just designed by trial and error. For example even the part of your
dishwasher that contains the salt to soften the water has been carefully
studied, designed and simulated to minimise salt use, pressure drop and
material costs. Certainly some person didn't just draw it out and say
"that'll work, let's test it" and then maybe make a couple of tweaks.
You wouldn't survive 5 minutes if your company worked like that.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Fri, 07 Sep 2012 11:24:02 +0100, Orchid Win7 v1 wrote:
>>>> crypto/security
>>>
>>> Seriously, almost *nobody* actually does that.
>>
>> Bullshit. I'm presently working with two teams that are knee-deep in
>> crypto and security work. Identity management, authentication, etc -
>> all use that extensively.
>
> You're telling me there are more than three people on Earth who actually
> design ciphers?
crypto/security isn't just about designing ciphers.
And I'm telling you that there are more than 3 people who work with crypto
and security.
>> Yes. See "Business Intelligence". Data-driven decision making is
>> something that a lot of businesses do, and they tend to be successful.
>
> I would have thought that querying the data to get the numbers you want
> is the /easy/ part. The hard part, surely, is figuring out what
> questions to ask in the first place. And that is out of my league.
Sometimes querying the data or figuring out what data you need is
actually fairly tricky, as is using the data that's available to try to
answer questions that are better answered with data that you don't have
and can't get.
>>>> robotics
>>>
>>> Is there any commercial application for that?
>>
>> Manufacturing uses robotics in a huge way.
>
> OK. But those robots already exist. Why would you ever need to design
> more?
Because not all the robots that are in use are optimum for the jobs they
do, additional manufacturing that currently is manual labour can be
automated - there are lots of applications still being developed.
Not all the robots that could ever be developed or could be useful have
been made yet. You /do/ realise this, don't you?
>>>> marketing
>>>
>>> There's technical expertise in that?
>>
>> Yes. Writing marketing copy that actually convinces technical people
>> requires technical expertise.
>
> You must be looking at very different "marketing copy" than the stuff
> I've seen.
Quite possibly. I've also been involved in creating some.
> Typically you get a picture of something expensive - a server, a disk
> enclosure, whatever - and a paragraph of fancy middle management
> power-word bullocks about how the company offer you "synergistic
> solutions" to "streamline" your operations and "leverage" legacy assets
> with their "revolutionary innovations" - hell no, I can't even type this
> stuff! >_<
That's "non-technical" marketing, designed to convince management types,
not marketing designed to convince technical types.
> In particular, such material is utterly devoid of even the slightest
> hint of technical detail. Lots of hand-waving about "total cost of
> ownership" and "return on investment" and so forth, but no technical
> specifications, and no prices.
You've never seen a technical specifications sheet - ever?
>>>> disaster response
>>>
>>> What kind of disaster response requires technical skill?
>>
>> Your data center has burned to the ground. Recover it.
>>
>> Yeah, that takes a lot of technical skill - and ability to use those
>> skills quickly to get the services running as soon as possible.
>
> Or rather, it requires technical skill to design the data center
> correctly in the first place. By the time a disaster actually occurs, it
> should be easy enough that a trained monkey could do the actual recovery
> part...
That's not actually how it works. I know from having worked on DR plans
for large and small companies.
Jim
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
