Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.programming > #5251 > unrolled thread

is it better to learn a couple of platforms/technologies or just one?

Back to article view | Back to comp.programming

Contents

  is it better to learn a couple of platforms/technologies or just one? fir <profesor.fir@gmail.com> - 2015-02-25 05:58 -0800
    Re: is it better to learn a couple of platforms/technologies or just one? Richard Heathfield <rjh@cpax.org.uk> - 2015-02-25 16:46 +0000
      Re: is it better to learn a couple of platforms/technologies or just one? fir <profesor.fir@gmail.com> - 2015-02-26 04:31 -0800
        Re: is it better to learn a couple of platforms/technologies or just one? Richard Heathfield <rjh@cpax.org.uk> - 2015-02-26 12:48 +0000
          Re: is it better to learn a couple of platforms/technologies or just one? fir <profesor.fir@gmail.com> - 2015-02-26 05:33 -0800
          Re: is it better to learn a couple of platforms/technologies or just one? Mark Carroll <mtbc@bcs.org> - 2015-02-26 13:47 +0000
        Re: is it better to learn a couple of platforms/technologies or just one? Mark Carroll <mtbc@bcs.org> - 2015-02-26 13:11 +0000
          Re: is it better to learn a couple of platforms/technologies or just one? fir <profesor.fir@gmail.com> - 2015-02-26 05:45 -0800
            Re: is it better to learn a couple of platforms/technologies or just one? Mark Carroll <mtbc@bcs.org> - 2015-02-26 13:56 +0000
              Re: is it better to learn a couple of platforms/technologies or just one? fir <profesor.fir@gmail.com> - 2015-02-26 06:20 -0800
                Re: is it better to learn a couple of platforms/technologies or just one? Mark Carroll <mtbc@bcs.org> - 2015-02-26 14:47 +0000
                  Re: is it better to learn a couple of platforms/technologies or just one? fir <profesor.fir@gmail.com> - 2015-02-26 07:17 -0800
                    Re: is it better to learn a couple of platforms/technologies or just one? fir <profesor.fir@gmail.com> - 2015-02-26 07:30 -0800

#5251 — is it better to learn a couple of platforms/technologies or just one?

I wonder as to above.. it seems that when i am doing programing i am 'in turns' optymistic and pessymistic about my energy and time, when i am optimistic i think it is okay to learn more technologies, when i am pesimistic i see it bad.. I wonder how it could be more sane answer to this not such based on "optimistic/pesimistic" as it seem weak as ground  to decisions..
recent times i seem to tend to be pessymistic.. some thoughts maybe?
(i know this is humanistic question hard to answer but maybe some kind of vision will appear)

[toc] | [next] | [standalone]

#5252

On 25/02/15 13:58, fir wrote:
> I wonder as to above.. it seems that when i am doing programing i am 'in turns' optymistic and pessymistic about my energy and time, when i am optimistic i think it is okay to learn more technologies, when i am pesimistic i see it bad.. I wonder how it could be more sane answer to this not such based on "optimistic/pesimistic" as it seem weak as ground  to decisions..
> recent times i seem to tend to be pessymistic.. some thoughts maybe?
> (i know this is humanistic question hard to answer but maybe some kind of vision will appear)


Here is one sensible path among many:

1) learn a procedural programming language *really* well (something like 
C or Pascal). You may already have done this, of course.

2) learn SQL. This is absolutely the most important 
non-programming-language technology you could possibly learn.

3) learn HTML if you haven't already, and then learn how to create 
dynamic Web sites with PHP. Learn how to make it join up with SQL to 
create data-driven Web sites.

4) learn object-oriented programming (C++, say). Then apply your 
learning to PHP. Object-oriented PHP is in big demand.

5) look in the job ads (even if you already have a job). Find a job 
you'd really like to do, except you can't because you don't know 
such-and-such (whether it's XML, or SOAP, or JavaScript, or CORBA, or 
whatever it is). Spend a couple of weeks learning that technology to see 
if you get on with it. If not, drop it, and at least you've learned what 
it is and what it's for. But if you do take to it, incorporate it into 
your out-of-hours programming.

6) find something in Knuth that you haven't implemented yet, and 
implement it. In other words, continue to advance your knowledge of 
computer science. There's more to programming than The Technology 
Flavour Of The Month.

7) go to Step 5.

-- 
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within

[toc] | [prev] | [next] | [standalone]

#5261

W dniu środa, 25 lutego 2015 17:46:44 UTC+1 użytkownik Richard Heathfield napisał:
> On 25/02/15 13:58, fir wrote:
> > I wonder as to above.. it seems that when i am doing programing i am 'in turns' optymistic and pessymistic about my energy and time, when i am optimistic i think it is okay to learn more technologies, when i am pesimistic i see it bad.. I wonder how it could be more sane answer to this not such based on "optimistic/pesimistic" as it seem weak as ground  to decisions..
> > recent times i seem to tend to be pessymistic.. some thoughts maybe?
> > (i know this is humanistic question hard to answer but maybe some kind of vision will appear)
> 
> 
> Here is one sensible path among many:
> 
> 1) learn a procedural programming language *really* well (something like 
> C or Pascal). You may already have done this, of course.
> 
> 2) learn SQL. This is absolutely the most important 
> non-programming-language technology you could possibly learn.
> 
> 3) learn HTML if you haven't already, and then learn how to create 
> dynamic Web sites with PHP. Learn how to make it join up with SQL to 
> create data-driven Web sites.
> 
> 4) learn object-oriented programming (C++, say). Then apply your 
> learning to PHP. Object-oriented PHP is in big demand.
> 
> 5) look in the job ads (even if you already have a job). Find a job 
> you'd really like to do, except you can't because you don't know 
> such-and-such (whether it's XML, or SOAP, or JavaScript, or CORBA, or 
> whatever it is). Spend a couple of weeks learning that technology to see 
> if you get on with it. If not, drop it, and at least you've learned what 
> it is and what it's for. But if you do take to it, incorporate it into 
> your out-of-hours programming.
> 
> 6) find something in Knuth that you haven't implemented yet, and 
> implement it. In other words, continue to advance your knowledge of 
> computer science. There's more to programming than The Technology 
> Flavour Of The Month.
> 
> 7) go to Step 5.
> 
most people learn this way - wide range of technologies, I stil wonder/consider if this is a good way as this is damn time consuming and if i should go 'wide' or 'narrow' (began to think that narrow is the way, this is like knowing a lot of people against knowing the few)

[toc] | [prev] | [next] | [standalone]

#5262

On 26/02/15 12:31, fir wrote:

<snip>

> most people learn this way - wide range of
 > technologies, I stil wonder/consider if this
 > is a good way as this is damn time consuming
 > and if i should go 'wide' or 'narrow' (began
 > to think that narrow is the way, this is like
 > knowing a lot of people against knowing the few)

It depends on your goal. If you want to become a very, very productive 
programmer, learn one language REALLY well, and take on new technologies 
only when you are absolutely sure that you can't do without them.

Unfortunately, this strategy doesn't work in the stupid stupid world of 
employment. If you want a job, you have to be able to boast proficiency 
in Technology Flavour Of The Month. So you have three choices when faced 
with a job advertisement requiring Technology X:

1) don't apply for the job;
2) lie on your CV, gen up on Technology X in the few days before the 
interview, and apply in the hope that they won't ask you too many hard 
questions about X;
3) already be proficient in Technology X.

1) doesn't get you the job.
2) is dishonest. I've never done this myself, but I've known plenty of 
people who have, and who have thrived (or thriven), learning Technology 
X "on the job". Eventually, they may even become competent at it, but by 
this time the world has moved on and they are reduced to lying on their 
CV again if they ever want to switch jobs.
3) means you spent time learning Technology X that you could have spent 
in other ways (eg learning Technology Y), which means you have trouble 
applying for jobs requiring Technology Y.

This is all stupid, but it's the way the world works.

The way the world *should* work is that companies hire bright people, 
regardless of whether they know CORBA or Zend or Bogalog or whatever the 
technology is.

Does this ever happen? I don't know, but somehow I doubt it.

-- 
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within

[toc] | [prev] | [next] | [standalone]

#5264

W dniu czwartek, 26 lutego 2015 13:48:03 UTC+1 użytkownik Richard Heathfield napisał:
> On 26/02/15 12:31, fir wrote:
> 
> <snip>
> 
> > most people learn this way - wide range of
>  > technologies, I stil wonder/consider if this
>  > is a good way as this is damn time consuming
>  > and if i should go 'wide' or 'narrow' (began
>  > to think that narrow is the way, this is like
>  > knowing a lot of people against knowing the few)
> 
> It depends on your goal. If you want to become a very, very productive 
> programmer, learn one language REALLY well, and take on new technologies 
> only when you are absolutely sure that you can't do without them.
> 
> Unfortunately, this strategy doesn't work in the stupid stupid world of 
> employment. If you want a job, you have to be able to boast proficiency 
> in Technology Flavour Of The Month. So you have three choices when faced 
> with a job advertisement requiring Technology X:
> 
> 1) don't apply for the job;
> 2) lie on your CV, gen up on Technology X in the few days before the 
> interview, and apply in the hope that they won't ask you too many hard 
> questions about X;
> 3) already be proficient in Technology X.
> 
> 1) doesn't get you the job.
> 2) is dishonest. I've never done this myself, but I've known plenty of 
> people who have, and who have thrived (or thriven), learning Technology 
> X "on the job". Eventually, they may even become competent at it, but by 
> this time the world has moved on and they are reduced to lying on their 
> CV again if they ever want to switch jobs.
> 3) means you spent time learning Technology X that you could have spent 
> in other ways (eg learning Technology Y), which means you have trouble 
> applying for jobs requiring Technology Y.
> 
> This is all stupid, but it's the way the world works.
> 
> The way the world *should* work is that companies hire bright people, 
> regardless of whether they know CORBA or Zend or Bogalog or whatever the 
> technology is.
> 
> Does this ever happen? I don't know, but somehow I doubt it.
> 
for CV reasons it is probably better to know wide but i am more interested in some much more depth/"true" reasons, 
(what will make me stronger superhero,)

the question is banal but i find taking some meaningfull answer is extreamally important yet hard to get

(i mean not random shallow answer but something deapth meaningfull here)

[toc] | [prev] | [next] | [standalone]

#5266

Richard Heathfield <rjh@cpax.org.uk> writes:
(snip)
> The way the world *should* work is that companies hire bright people, 
> regardless of whether they know CORBA or Zend or Bogalog or whatever the 
> technology is.
>
> Does this ever happen? I don't know, but somehow I doubt it.

It /does/, but it's uncommon. For instance, when my employer went out of
business during the credit crisis, I got back into mainstream full-stack
stuff -- PL/pgSQL, Hibernate, Struts, Spring, Lucene, JavaScript etc. --
through being hired by such a company. You have to look for ones who
hire a lot of new graduates from good universities and expect them to be
able to work on the whole codebase (so they expect one to learn on the
job). As a professional used to managing teams on multiple projects at
once, this new job at a place used to hiring new graduates was a pain
from the point of view of now just being junior and working on only one
project while managed by people with more years in that company but
rather less experience overall than I -- it was more a word of mouth
thing that colleagues learned I could actually help with shell
scripting, LaTeX, image transformation, etc. too outside the role I
officially had -- but it was a nice holiday from having a more stressful
position and really boosted my resume with the latest buzzword
technologies for the next round of job applications.

Unfortunately, it takes a good programmer to know one, and the good
programmers are mostly busy doing work they're needed for instead of
filtering through job applicants. You're right: there's an issue.

And, related to my other post in this thread, it now occurs to me that a
mix of, say, Standard ML and Java will help me when I have to use Scala,
which I have seen just a few paid positions for. For this kind of thing,
when I apply for a job using a language I've not used before, I normally
offer to supply code samples, and if they'd like to specify a small
problem for me to work on and provide a solution in that language before
they agree to interview me, then for some of them that's just fine and
actually rather appreciated (some pick Project Euler problems). Also,
there are other large employers who have their own in-house stuff like
InterSystems Caché where they don't really expect to hire people who
already know MUMPS or whatever.

-- Mark

[toc] | [prev] | [next] | [standalone]

#5263

fir <profesor.fir@gmail.com> writes:
(snip)
> most people learn this way - wide range of technologies, I stil wonder/consider if this is a good way as this is damn time consuming and if i should go 'wide' or 'narrow' (began to think that narrow is the way, this is like knowing a lot of people against knowing the few)

Do be prepared for your narrow expertise to become obsolete. I first
learned this after knowing the Commodore 64 inside out just in time for
everyone to be buying Amigas instead, though learning assembler helped
to then make C easier to learn. I was just reading an article on
comp.lang.postscript about how obsolete that is becoming -- I'd
profitably spent many hours writing in that, but if starting from
scratch it's not what I'd now choose. With a range of languages, it's
easy to hit the ground running in the new language du jour. For
instance, the given list included nothing like Mercury but, for
instance, a combination of C and Lisp help make JavaScript to make more
sense or, for my part, in my current job I was writing some Python last
week: I've never even sat down for a week with a book on Python, but I
am getting on easily with it through having previously done Perl 5 and
Haskell (significant whitespace, list comprehensions, lambdas, etc.).
Or, as another example, a combination of Modula-3's generics and Lisp's
macros helped me get to grips with C++, then those helped me get going
with Java (objects, threading, dynamism, etc.), and a combination of
object-orientation and Standard ML helped me impress at the OCaml
segment of a job interview even though I'd not used it previously. After
the investment in a diverse enough background, the resulting flexibility
is very useful. Truly new big ideas in language design don't come very
often, so once you've made that investment, it's not so hard to keep it
up to date: so, don't be daunted, it'll get easier. For instance, my web
stuff is getting out of date, but once I do finally get around to
learning about HTML5 canvases, SVG, etc., I expect that anything from
knowing PostScript to having written AWT LayoutManager instances may
well help me in that.

-- Mark

[toc] | [prev] | [next] | [standalone]

#5265

W dniu czwartek, 26 lutego 2015 14:12:00 UTC+1 użytkownik Mark Carroll napisał:
> fir <profesor.fir@gmail.com> writes:
> (snip)
> > most people learn this way - wide range of technologies, I stil wonder/consider if this is a good way as this is damn time consuming and if i should go 'wide' or 'narrow' (began to think that narrow is the way, this is like knowing a lot of people against knowing the few)
> 
> Do be prepared for your narrow expertise to become obsolete. I first
> learned this after knowing the Commodore 64 inside out just in time for
> everyone to be buying Amigas instead, though learning assembler helped
> to then make C easier to learn. I was just reading an article on
> comp.lang.postscript about how obsolete that is becoming -- I'd
> profitably spent many hours writing in that, but if starting from
> scratch it's not what I'd now choose. With a range of languages, it's
> easy to hit the ground running in the new language du jour. For
> instance, the given list included nothing like Mercury but, for
> instance, a combination of C and Lisp help make JavaScript to make more
> sense or, for my part, in my current job I was writing some Python last
> week: I've never even sat down for a week with a book on Python, but I
> am getting on easily with it through having previously done Perl 5 and
> Haskell (significant whitespace, list comprehensions, lambdas, etc.).
> Or, as another example, a combination of Modula-3's generics and Lisp's
> macros helped me get to grips with C++, then those helped me get going
> with Java (objects, threading, dynamism, etc.), and a combination of
> object-orientation and Standard ML helped me impress at the OCaml
> segment of a job interview even though I'd not used it previously. After
> the investment in a diverse enough background, the resulting flexibility
> is very useful. Truly new big ideas in language design don't come very
> often, so once you've made that investment, it's not so hard to keep it
> up to date: so, don't be daunted, it'll get easier. For instance, my web
> stuff is getting out of date, but once I do finally get around to
> learning about HTML5 canvases, SVG, etc., I expect that anything from
> knowing PostScript to having written AWT LayoutManager instances may
> well help me in that.
> 
but if you know 20 various wide-span technologies it costs time counted in years.. Hadnt you find that maybe when sparing this all time and investing in
narrow work wouldnt be better?

I personally find this variety of technologies probably as a kind of vampire that drians my time.. Though 
i am not quite sure what to think on 
it, those two routes are really quite
quite different : learn all this technologies we know and go to that
party, or take a lone path and alienate
yourself ;/

I began to think that this crowd party
is a dead end way and it is realy better to alienate (though is harder as people
like to do what others do) This is anyway importand decision so i am blinding/circulating here

[toc] | [prev] | [next] | [standalone]

#5267

fir <profesor.fir@gmail.com> writes:
(snip)
> but if you know 20 various wide-span technologies it costs time counted in years.. Hadnt you find that maybe when sparing this all time and investing in
> narrow work wouldnt be better?
(snip)

In a nutshell: you do end up knowing some things narrowly, but once you
know a few different kinds of things, each extra thing is less and less
extra effort, so the cost isn't as awful, and in the longer term pays
back handsomely. Also, ideas from one can help you see new ways to do
things in what you know narrowly. This is how languages develop, indeed:
a lot of the "new" things that come to a new version of what you
currently use and understand really well, will actually be old things
from other languages with which you're already familiar. And, where you
have a choice in language, you will be able to choose a good tool for
the job.

It also helps in staying employed: if you can do a few things, then you
can slide a bit in your job toward the things you can see that your
employer needs and few of your colleagues can give. (For instance, in a
group of mostly Java and JavaScript programmers now, I'm currently
increasing my involvement in the C++ stuff that our users are wanting
more from us in.)

-- Mark

[toc] | [prev] | [next] | [standalone]

#5268

W dniu czwartek, 26 lutego 2015 14:56:41 UTC+1 użytkownik Mark Carroll napisał:
> fir <profesor.fir@gmail.com> writes:
> (snip)
> > but if you know 20 various wide-span technologies it costs time counted in years.. Hadnt you find that maybe when sparing this all time and investing in
> > narrow work wouldnt be better?
> (snip)
> 
> In a nutshell: you do end up knowing some things narrowly, but once you
> know a few different kinds of things, each extra thing is less and less
> extra effort, so the cost isn't as awful, and in the longer term pays
> back handsomely. Also, ideas from one can help you see new ways to do
> things in what you know narrowly. This is how languages develop, indeed:
> a lot of the "new" things that come to a new version of what you
> currently use and understand really well, will actually be old things
> from other languages with which you're already familiar. And, where you
> have a choice in language, you will be able to choose a good tool for
> the job.
> 
> It also helps in staying employed: if you can do a few things, then you
> can slide a bit in your job toward the things you can see that your
> employer needs and few of your colleagues can give. (For instance, in a
> group of mostly Java and JavaScript programmers now, I'm currently
> increasing my involvement in the C++ stuff that our users are wanting
> more from us in.)
> 
this is common opinion, but is it really true? i know this opinion for years as most people share it, but i got a bit of experience and i seem to see like something opposite, learning new techs/platforms makess me feel better etc but not S O much (and a lot of time consumed in meantime, i disagree they are so cheap, they are damn expensive imo)..
well i will see right now im still damn confused

[toc] | [prev] | [next] | [standalone]

#5269

fir <profesor.fir@gmail.com> writes:
(snip)
>> In a nutshell: you do end up knowing some things narrowly, but once you
>> know a few different kinds of things, each extra thing is less and less
>> extra effort
(snip)
> this is common opinion, but is it really true?
(snip)

Well, I just gave the example of writing some more Python last week
despite never even having taken a week out to sit down and study it
(much as I might like to). So, I think it is.

Of course, mostly one is paid for getting things working, not for deep
knowledge. Still, a lot of habits that encourage maintainability (good
naming, good separation of concerns, etc.) are quite transferable.

-- Mark

[toc] | [prev] | [next] | [standalone]

#5270

W dniu czwartek, 26 lutego 2015 15:47:15 UTC+1 użytkownik Mark Carroll napisał:
> fir <profesor.fir@gmail.com> writes:
> (snip)
> >> In a nutshell: you do end up knowing some things narrowly, but once you
> >> know a few different kinds of things, each extra thing is less and less
> >> extra effort
> (snip)
> > this is common opinion, but is it really true?
> (snip)
> 
> Well, I just gave the example of writing some more Python last week
> despite never even having taken a week out to sit down and study it
> (much as I might like to). So, I think it is.
> 
> Of course, mostly one is paid for getting things working, not for deep
> knowledge. Still, a lot of habits that encourage maintainability (good
> naming, good separation of concerns, etc.) are quite transferable.
> 
running something 'in short' is possible
(like 3 days adventure that you find quite interesting and only 3 days wasted)
but deep knowledge of python or other consumes much more time.. and maybe could be a great waste for someone for who those are side technologies.. depends on point of view maybe, and it is somewhat really hard to avoid those (wastefull?) side tehnologies in a world where everyone treats them as an advantage nice to learn (like lemmings?) instead of focusing on something more strightforward
(?)

[this above is written a bit warped, maybe a little joke, but here is really some trouble and unclearity what to do that concerns me; ]

[toc] | [prev] | [next] | [standalone]

#5271

W dniu czwartek, 26 lutego 2015 16:17:54 UTC+1 użytkownik fir napisał:
> 
> [this above is written a bit warped, maybe a little joke, but here is really some trouble and unclearity what to do that concerns me; ]

(i started to think of this alternative maybe about 5 years ago and still had not build any answer, I am only quite sure that this is quite important dilemate/fork to take)

[toc] | [prev] | [standalone]

Back to top | Article view | comp.programming

csiph-web