In message , at 10:47:29 on Sat, 14 Jan
2017, tim... remarked:

just because you know that there is a shortage of workers in one group
cannot help you determine if there is a shortage in the other.

In case you hadn't noticed, the majority of programming requirement is
now for the online space. And the online paradigms are often new and
evolving, thus it helps to get new blood in.
--
Roland Perry

"Roland Perry" wrote in message
...
In message , at 10:55:38 on Sat, 14 Jan 2017,
tim... remarked:

Ah, a slight light dawns - you think Uber is just an App, and the tooth
fairly provided the backoffice/online platform?

There is no connection with this discussion on the way that "software
engineer" has been Hijacked

and Uber's requirement.

You are still insisting that it doesn't require software engineers to
build Uber's platform?

Jesus, no I am not

You really are not understanding the point that I made

I have written Windows Applications in a past world (starting at 2.0)

Bully for you. Uber's backoffice/online platform is not an "application".

the back office part isn't, and even when I did work on Win stuff I had no
experience of that.

As to the online part, surely it is, as in "there an app for that!"

I'm talking about software which is engineered to provide an integrated
solution, thus Google's search engine and cloud processing counts, even
though you need a browser and operating system on your device to access
it. Ditto eBay's trading platform.

But the point is that you were using this example as some sort of proof
that there is some similarity in the way that software developers work
proficiently on software for an engineering product.

All the deliverables above (Uber, Google, eBay) are engineering products.

I don't agree

they use programs that run on general purpose computers (except for edge
cases like Google glass)

None of the companies substantive products requires "traditional"
engineering skills, except whilst writing software.

I know nothing about Blockchain,

QED, which is why it's necessary to recruit new blood which does.

Of course it's necessary to recruit more staff if you need them

But you will recall that the discussion was about getting skilled people and
the learning curve if you couldn't

You don't recruit and train people to use random development environments
that don't bring anything to your type of product.

it is (/would appear to be) not a useful tool when writing software for an
engineering product.

Blockchain isn't a tool, it's a process (or protocol if you prefer).

Though it seems to be something to do with accessing stored records (let's
call that a database, shall we?)

tim

"Roland Perry" wrote in message
...
In message , at 10:47:29 on Sat, 14 Jan 2017,
tim... remarked:

just because you know that there is a shortage of workers in one group
cannot help you determine if there is a shortage in the other.

In case you hadn't noticed, the majority of programming requirement is now
for the online space.

agreed

but that's irrelevant to a discussion which stared with me saying

there isn't a shortage of IT staff in engineering

and you saving

yes there is

And the online paradigms are often new and evolving, thus it helps to get
new blood in.

I think that's insulting to experienced staff to say "we don't think that
you can learn this new skill"

I had this discussion very very early on in my career when real time
development was done on specialist development systems and moved to being
done on IBM PC's

Recruiters would say nonsense like you don't have PC experience, my client
can't use you - to which I could respond "but I do have development on PC
experience" (though I was pretty unique in that at the time), but if I
hadn't they would have been saying to a 28 year old graduate "you can't be
retrained to use a simple computer interface" (that all our, left school at
16, admin staff are being retrained to use) - Utter Bull ****!

tim

In message , at 20:30:07 on Sat, 14 Jan
2017, tim... remarked:

Ah, a slight light dawns - you think Uber is just an App, and the
tooth fairly provided the backoffice/online platform?

There is no connection with this discussion on the way that "software
engineer" has been Hijacked

and Uber's requirement.

You are still insisting that it doesn't require software engineers to
build Uber's platform?

Jesus, no I am not

You really are not understanding the point that I made

Just to be clear, you *do* accept that the term "software engineering"
applies to the task of implementing Uber's platform?

I have written Windows Applications in a past world (starting at 2.0)

Bully for you. Uber's backoffice/online platform is not an "application".

the back office part isn't, and even when I did work on Win stuff I had
no experience of that.

As to the online part, surely it is, as in "there an app for that!"

In the days of Windows 2.0 there was a Windows app which purported to
produce customised Windows apps. The problem was that both the app
itself, and its offspring were excrutiatingly slow, and the offspring
had a very limited UI feature set.

Fast forward to today, and the way you make a new Android App is to use
an SDK on a PC (not an Android app on a phone).

I'm talking about software which is engineered to provide an
integrated solution, thus Google's search engine and cloud
processing counts, even though you need a browser and operating
system on your device to access it. Ditto eBay's trading platform.

But the point is that you were using this example as some sort of
proof that there is some similarity in the way that software
developers work proficiently on software for an engineering product.

All the deliverables above (Uber, Google, eBay) are engineering products.

I don't agree

they use programs that run on general purpose computers (except for
edge cases like Google glass)

None of the companies substantive products requires "traditional"
engineering skills, except whilst writing software.

Is there an invisible "electronic" in front of "engineering" there? If
so that's just one of dozens of types of engineering. If you have some
pressing need to include metal[1]-bashing into anything you are prepared
to call an engineering product then perhaps you aren't aware that Google
designs and builds its own data centres, full of generators, air
conditioning and all sorts of other non-softwary things.

[1] Semiconductors are metal for the purpose of this discussion

I know nothing about Blockchain,

QED, which is why it's necessary to recruit new blood which does.

Of course it's necessary to recruit more staff if you need them

But you will recall that the discussion was about getting skilled
people and the learning curve if you couldn't

Which is the situation today. A huge skills shortage in the areas under
discussion.

You don't recruit and train people to use random development
environments that don't bring anything to your type of product.

FSVO "you". I'd be looking at "the industry as a whole", not each
company separately.

it is (/would appear to be) not a useful tool when writing software
for an engineering product.

Blockchain isn't a tool, it's a process (or protocol if you prefer).

Though it seems to be something to do with accessing stored records
(let's call that a database, shall we?)

One way of thinking about it that it's to databases, what bitcoin is to
money in your bank account.
--
Roland Perry

In message , at 20:39:08 on Sat, 14 Jan
2017, tim... remarked:


"Roland Perry" wrote in message
...
In message , at 10:47:29 on Sat, 14 Jan
2017, tim... remarked:

just because you know that there is a shortage of workers in one
group cannot help you determine if there is a shortage in the other.

In case you hadn't noticed, the majority of programming requirement
is now for the online space.

agreed

but that's irrelevant to a discussion which stared with me saying

there isn't a shortage of IT staff in engineering

and you saving

yes there is

And the online paradigms are often new and evolving, thus it helps to
get new blood in.

I think that's insulting to experienced staff to say "we don't think
that you can learn this new skill"

The skill required is in imagining and devising whole new ways of
working.

I had this discussion very very early on in my career when real time
development was done on specialist development systems and moved to
being done on IBM PC's

Recruiters would say nonsense like you don't have PC experience, my
client can't use you - to which I could respond "but I do have
development on PC experience" (though I was pretty unique in that at
the time), but if I hadn't they would have been saying to a 28 year old
graduate "you can't be retrained to use a simple computer interface"
(that all our, left school at 16, admin staff are being retrained to
use) - Utter Bull ****!

I agree that in the environment you describe, the skills are portable,
and attitudes of employers and recruiters had not yet moved on. The
"whole new way of working" (which was probably coming in when you
started your career) was to program in high level languages rather than
assembler.

Thus it doesn't matter whether you know how to optimise assembler
routines on a pipelined TTL mainframe but people suspect you might not
be able to readily do the same on an 8086; having mastered C (or
whatever) that skill is indeed portable to any computer with a decent C
compiler.
--
Roland Perry

"Roland Perry" wrote in message
...
In message , at 20:30:07 on Sat, 14 Jan 2017,
tim... remarked:

Ah, a slight light dawns - you think Uber is just an App, and the
tooth fairly provided the backoffice/online platform?

There is no connection with this discussion on the way that "software
engineer" has been Hijacked

and Uber's requirement.

You are still insisting that it doesn't require software engineers to
build Uber's platform?

Jesus, no I am not

You really are not understanding the point that I made

Just to be clear, you *do* accept that the term "software engineering"
applies to the task of implementing Uber's platform?

like all software, yes

I have written Windows Applications in a past world (starting at 2.0)

Bully for you. Uber's backoffice/online platform is not an
"application".

the back office part isn't, and even when I did work on Win stuff I had no
experience of that.

As to the online part, surely it is, as in "there an app for that!"

In the days of Windows 2.0 there was a Windows app which purported to
produce customised Windows apps. The problem was that both the app itself,
and its offspring were excrutiatingly slow, and the offspring had a very
limited UI feature set.

but it was also possible to write "raw" windows code, that used an SDK.

Fast forward to today, and the way you make a new Android App is to use an
SDK on a PC (not an Android app on a phone).

This is no different to my writing ARM targeted code on a (Intel based) PC

I'm talking about software which is engineered to provide an
integrated solution, thus Google's search engine and cloud processing
counts, even though you need a browser and operating system on your
device to access it. Ditto eBay's trading platform.

But the point is that you were using this example as some sort of proof
that there is some similarity in the way that software developers work
proficiently on software for an engineering product.

All the deliverables above (Uber, Google, eBay) are engineering
products.

I don't agree

they use programs that run on general purpose computers (except for edge
cases like Google glass)

None of the companies substantive products requires "traditional"
engineering skills, except whilst writing software.

Is there an invisible "electronic" in front of "engineering" there?

No, that's just one option.

If so that's just one of dozens of types of engineering. If you have some
pressing need to include metal[1]-bashing into anything you are prepared
to call an engineering product then perhaps you aren't aware that Google
designs and builds its own data centres, full of generators, air
conditioning and all sorts of other non-softwary things.

[1] Semiconductors are metal for the purpose of this discussion

I know nothing about Blockchain,

QED, which is why it's necessary to recruit new blood which does.

Of course it's necessary to recruit more staff if you need them

But you will recall that the discussion was about getting skilled people
and the learning curve if you couldn't

Which is the situation today. A huge skills shortage in the areas under
discussion.

The one you are now discussing perhaps, but not where we came in

You don't recruit and train people to use random development environments
that don't bring anything to your type of product.

FSVO "you". I'd be looking at "the industry as a whole", not each company
separately.

I'm looking at the industry as a whole

This Blockchain tool/process appears to be targeted at database requirements
(if this isn't so you need to tell me)

So there is no point even thinking of using it on a product that doesn't
require a database.


it is (/would appear to be) not a useful tool when writing software for
an engineering product.

Blockchain isn't a tool, it's a process (or protocol if you prefer).

Though it seems to be something to do with accessing stored records (let's
call that a database, shall we?)

One way of thinking about it that it's to databases, what bitcoin is to
money in your bank account.

I have no idea what bitcoin is to my bank account

Bitcoin is a chimera

https://www.ft.com/content/b5d66ed8-...b-680c49b4b4c0

(Sorry, you have to register, but you can read it for free if you do)

tim

"Roland Perry" wrote in message
...
In message , at 20:39:08 on Sat, 14 Jan 2017,
tim... remarked:



I had this discussion very very early on in my career when real time
development was done on specialist development systems and moved to being
done on IBM PC's

Recruiters would say nonsense like you don't have PC experience, my client
can't use you - to which I could respond "but I do have development on PC
experience" (though I was pretty unique in that at the time), but if I
hadn't they would have been saying to a 28 year old graduate "you can't be
retrained to use a simple computer interface" (that all our, left school
at 16, admin staff are being retrained to use) - Utter Bull ****!

I agree that in the environment you describe, the skills are portable, and
attitudes of employers and recruiters had not yet moved on. The "whole new
way of working" (which was probably coming in when you started your
career) was to program in high level languages rather than assembler.

Thus it doesn't matter whether you know how to optimise assembler routines
on a pipelined TTL mainframe but people suspect you might not be able to
readily do the same on an 8086; having mastered C (or whatever) that skill
is indeed portable to any computer with a decent C compiler.

All my working experience post dates assembler

I wrote high level code in a variety of languages

BCPL, RTL/2, Coral 66, PL/M and even some Fortran XX (was it 77? CBA to
check) (FTAOD each language does not represent a new employer).

All written using either a specialist (and relatively very expensive)
development systems based upon the same processor that the final software
was to run on or cross compiled on a larger machine, usually a VAX (I'll
refrain from calling that a mainframe, but wont complain if you do).

Now almost everyone that wants microprocessor based solutions uses C/C++,
cross compiled on a PC.

Of course, in between, some people used C compiled on Sparc workstations,
but I managed to miss that in my career.

tim

In message , at 10:45:36 on Sun, 15 Jan
2017, tim... remarked:

Ah, a slight light dawns - you think Uber is just an App, and the
tooth fairly provided the backoffice/online platform?

There is no connection with this discussion on the way that
"software engineer" has been Hijacked

and Uber's requirement.

You are still insisting that it doesn't require software engineers
to build Uber's platform?

Jesus, no I am not

You really are not understanding the point that I made

Just to be clear, you *do* accept that the term "software
engineering" applies to the task of implementing Uber's platform?

like all software, yes

Good.

I have written Windows Applications in a past world (starting at 2.0)

Bully for you. Uber's backoffice/online platform is not an
"application".

the back office part isn't, and even when I did work on Win stuff I
had no experience of that.

As to the online part, surely it is, as in "there an app for that!"

In the days of Windows 2.0 there was a Windows app which purported to
produce customised Windows apps. The problem was that both the app
itself, and its offspring were excrutiatingly slow, and the offspring
had a very limited UI feature set.

but it was also possible to write "raw" windows code, that used an SDK.

Yes, however the projects I've been describing are mainly contained
within the online platform rather than the thin client.

Fast forward to today, and the way you make a new Android App is to
use an SDK on a PC (not an Android app on a phone).

This is no different to my writing ARM targeted code on a (Intel based) PC

Indeed, but can you justify your comment "there's an app for that" which
made it sound as if you thought the process of making an Uber app was
trivial?

A huge skills shortage in the areas under discussion.

The one you are now discussing perhaps, but not where we came in

Same area, it's just taken you a while to understand what it was we were
discussing.

This Blockchain tool/process appears to be targeted at database
requirements (if this isn't so you need to tell me)

So there is no point even thinking of using it on a product that
doesn't require a database.

Almost everything these days is data in a database.

it is (/would appear to be) not a useful tool when writing software
for an engineering product.

Blockchain isn't a tool, it's a process (or protocol if you prefer).

Though it seems to be something to do with accessing stored records
(let's call that a database, shall we?)

One way of thinking about it that it's to databases, what bitcoin is
to money in your bank account.

I have no idea what bitcoin is to my bank account

It's money whose existence is held in a distributed form, rather than
centrally in your bank's mainframe.

Bitcoin is a chimera

https://www.ft.com/content/b5d66ed8-...b-680c49b4b4c0

(Sorry, you have to register,

It's trivial to get round their paywall.

but you can read it for free if you do)

Is this the one (29/12/16):

"...most people in the financial world have written it off as a
failed experiment in digital finance, even though the idea
behind a core part of its technology - the blockchain, a
distributed ledger that simplifies transaction processing - has
since moved across into mainstream finance."

Many people would disagree that it has "failed", but as an example of a
widely used blockchain, it ticks all the boxes.
--
Roland Perry

In message , at 11:20:49 on Sun, 15 Jan
2017, tim... remarked:
The "whole new way of working" (which was probably coming in when you
started your career) was to program in high level languages rather
than assembler.

Thus it doesn't matter whether you know how to optimise assembler
routines on a pipelined TTL mainframe but people suspect you might
not be able to readily do the same on an 8086; having mastered C (or
whatever) that skill is indeed portable to any computer with a decent
C compiler.

All my working experience post dates assembler

I wrote high level code in a variety of languages

BCPL, RTL/2, Coral 66, PL/M and even some Fortran XX (was it 77? CBA to
check) (FTAOD each language does not represent a new employer).

You are describing a halfway house, where employers looking to fill a
vacancy for a Coral 66 programmer will be wanting to see that on their
CV, and not have to enquire how long they think that programmer would
take to 'convert' from BCPL. During that period you probably would have
to find an employer who was looking for a language had you could
demonstrate existing proficiency in.

Ahead of, as you rightly say, C becoming the market leader by a country
mile.
--
Roland Perry

"Roland Perry" wrote in message
...
In message , at 10:45:36 on Sun, 15 Jan
2017, tim... remarked:


Fast forward to today, and the way you make a new Android App is to
use an SDK on a PC (not an Android app on a phone).

This is no different to my writing ARM targeted code on a (Intel based) PC

Indeed, but can you justify your comment "there's an app for that" which
made it sound as if you thought the process of making an Uber app was
trivial?

because once again you have completely understood

I am simply talking about it requiring a skill set that is dissimilar to
that required for engineering (not engineered) products



A huge skills shortage in the areas under discussion.

The one you are now discussing perhaps, but not where we came in

Same area, it's just taken you a while to understand what it was we were
discussing.

It is you who have gone elsewhere

I am discussing my own original claim, nothing more

It really is rich, that when someone does comes back to justify a claim that
they made (something that is often lacking in poster's integrity - no
individual person intended here) you criticice me for not moving the flow
with you.

Lesson learnt, it will be me lacking that integrity in future.

tim