www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - carreer opportunities

reply llee <llee goucher.edu> writes:
I'm currently enrolled in Goucher college as a computer science major. I've
been programming in D for several years as a hobby, and would like to pursue it
as a career. It seems that the market is dominated by C++ and D programmers
will have a difficult time finding employment. Does anyone know of any
programming firms looking for people possessing skills in D? It's unfortunate
since D seems superior to both C, and C++. Hopefully the situation will change
in a few years as D increases in popularity. 
P.S. There are currently a number of certifications that C++ programmers can
pursue to demonstrate their knowledge of the language. Are there any available
for the D community?
Jun 26 2007
next sibling parent Christopher Wright <dhasenan gmail.com> writes:
llee wrote:
 I'm currently enrolled in Goucher college as a computer science major. I've
been programming in D for several years as a hobby, and would like to pursue it
as a career. It seems that the market is dominated by C++ and D programmers
will have a difficult time finding employment. Does anyone know of any
programming firms looking for people possessing skills in D? It's unfortunate
since D seems superior to both C, and C++. Hopefully the situation will change
in a few years as D increases in popularity. 
 P.S. There are currently a number of certifications that C++ programmers can
pursue to demonstrate their knowledge of the language. Are there any available
for the D community?

D has little commercial countenance at present. Most places either value performance or can go with a virtual machine with a giant standard library. If the former, C++ and C have much wider support and are more stable in terms of language features and compilers. If the latter, D doesn't have a sufficient collection of libraries to interest them. Currently, the best (read: most popular) options are Java, C++, and C# if you want to do mainstream applications development, C and C++ if you want to do systems work. It's also good to have experience in Python and Perl these days, and maybe Ruby. Bourne scripting, too, if you're doing anything that might possibly relate to Unix. But D? I like it, it's my favorite language...it's got pretty much no commercial prospects for the next year. It's a matter of libraries, politics, and current investments.
Jun 26 2007
prev sibling parent reply John Demme <me teqdruid.com> writes:
llee wrote:

 I'm currently enrolled in Goucher college as a computer science major.
 I've been programming in D for several years as a hobby, and would like to
 pursue it as a career. It seems that the market is dominated by C++ and D
 programmers will have a difficult time finding employment. Does anyone
 know of any programming firms looking for people possessing skills in D?
 It's unfortunate since D seems superior to both C, and C++. Hopefully the
 situation will change in a few years as D increases in popularity. P.S.
 There are currently a number of certifications that C++ programmers can
 pursue to demonstrate their knowledge of the language. Are there any
 available for the D community?

Don't become a D programmer. Don't become a C++ programmer. Don't become a C# or a Java programmer. You really don't want to become a Ruby or Python programmer. Just be a programmer. (Or engineer, architect, designer.. whatever) Get the basics down, and program as much as you can in as many different languages are you possibly can. The closer you get to guru status, the less the language matters. In the end, they're all just syntactical sugar hiding the assembly (which isn't really the lowest level.) It's better to think of languages as tools in the tool box. D may be one hell of a Swiss army knife, but you wouldn't build a machine shop with just a lathe (not a very good one at least.) Plus, If you program for any significant length of time, you'll have to learn some new languages. Anyway- programming is about solving a problem, not how you express the solution. IMO, certifications are worthless. Personally, I shy away from gigs for "C++ programmers" and the like, because I'm a problem solver, not a C++ monkey. That said, it is unfortunate that D doesn't have wider acceptance. I guess companies like to standardize on languages since they think it will make code more readable to the general employee coder populace and thus increase code reuse and cut development time- too bad that's not the case. Intelligent programmers are what make for good code. Hawk yourself, not the language. Work with intelligent people, and the development environment will follow. Sorry to get preachy, but IMO, people get way too hung up on the language. The biggest thing I look for in a gig (well, after money, that is) is the people I'm working with. I'll program in any language if I can work with smart people. By the way, the D community is filled with smart people. D is a great language, but I've stuck with it mostly because of the community, not D itself. -- ~John Demme me teqdruid.com
Jun 26 2007
next sibling parent gogamza <madjakarta gmail.com> writes:
thanks for good article.
I felt good impression.

I love D language too, but I can't use in my Work. because of it is my own
preferance, not my co-worker.

so I have using D  in my paper work of my own study.


~gogamza


John Demme Wrote:

 llee wrote:
 
 I'm currently enrolled in Goucher college as a computer science major.
 I've been programming in D for several years as a hobby, and would like to
 pursue it as a career. It seems that the market is dominated by C++ and D
 programmers will have a difficult time finding employment. Does anyone
 know of any programming firms looking for people possessing skills in D?
 It's unfortunate since D seems superior to both C, and C++. Hopefully the
 situation will change in a few years as D increases in popularity. P.S.
 There are currently a number of certifications that C++ programmers can
 pursue to demonstrate their knowledge of the language. Are there any
 available for the D community?

Don't become a D programmer. Don't become a C++ programmer. Don't become a C# or a Java programmer. You really don't want to become a Ruby or Python programmer. Just be a programmer. (Or engineer, architect, designer.. whatever) Get the basics down, and program as much as you can in as many different languages are you possibly can. The closer you get to guru status, the less the language matters. In the end, they're all just syntactical sugar hiding the assembly (which isn't really the lowest level.) It's better to think of languages as tools in the tool box. D may be one hell of a Swiss army knife, but you wouldn't build a machine shop with just a lathe (not a very good one at least.) Plus, If you program for any significant length of time, you'll have to learn some new languages. Anyway- programming is about solving a problem, not how you express the solution. IMO, certifications are worthless. Personally, I shy away from gigs for "C++ programmers" and the like, because I'm a problem solver, not a C++ monkey. That said, it is unfortunate that D doesn't have wider acceptance. I guess companies like to standardize on languages since they think it will make code more readable to the general employee coder populace and thus increase code reuse and cut development time- too bad that's not the case. Intelligent programmers are what make for good code. Hawk yourself, not the language. Work with intelligent people, and the development environment will follow. Sorry to get preachy, but IMO, people get way too hung up on the language. The biggest thing I look for in a gig (well, after money, that is) is the people I'm working with. I'll program in any language if I can work with smart people. By the way, the D community is filled with smart people. D is a great language, but I've stuck with it mostly because of the community, not D itself. -- ~John Demme me teqdruid.com

Jun 27 2007
prev sibling next sibling parent Robert Fraser <fraserofthenight gmail.com> writes:
Agreed.

I went into college knowing HTML and a little Java. After a year of college, I
knew a lot more Java, a little C, and had started learning D and PHP on my own.
After 6 months (so far) of an internship, I know a lot more Java, a whole lot
of Perl, some Ruby, the core of SQL, a good deal of Transact-SQL, and some Bash
scripting (not really a language, but whatever)... all after being hired as a
software developer on a system written entirely (or so they said in the
interview) in Java. Turns out, amazingly enough, that one language really
doesn't work for everything. Luckily, most (imperative) languages require
roughly the same skill set, so learning new ones just gets easier.

John Demme Wrote:

 llee wrote:
 
 I'm currently enrolled in Goucher college as a computer science major.
 I've been programming in D for several years as a hobby, and would like to
 pursue it as a career. It seems that the market is dominated by C++ and D
 programmers will have a difficult time finding employment. Does anyone
 know of any programming firms looking for people possessing skills in D?
 It's unfortunate since D seems superior to both C, and C++. Hopefully the
 situation will change in a few years as D increases in popularity. P.S.
 There are currently a number of certifications that C++ programmers can
 pursue to demonstrate their knowledge of the language. Are there any
 available for the D community?

Don't become a D programmer. Don't become a C++ programmer. Don't become a C# or a Java programmer. You really don't want to become a Ruby or Python programmer. Just be a programmer. (Or engineer, architect, designer.. whatever) Get the basics down, and program as much as you can in as many different languages are you possibly can. The closer you get to guru status, the less the language matters. In the end, they're all just syntactical sugar hiding the assembly (which isn't really the lowest level.) It's better to think of languages as tools in the tool box. D may be one hell of a Swiss army knife, but you wouldn't build a machine shop with just a lathe (not a very good one at least.) Plus, If you program for any significant length of time, you'll have to learn some new languages. Anyway- programming is about solving a problem, not how you express the solution. IMO, certifications are worthless. Personally, I shy away from gigs for "C++ programmers" and the like, because I'm a problem solver, not a C++ monkey. That said, it is unfortunate that D doesn't have wider acceptance. I guess companies like to standardize on languages since they think it will make code more readable to the general employee coder populace and thus increase code reuse and cut development time- too bad that's not the case. Intelligent programmers are what make for good code. Hawk yourself, not the language. Work with intelligent people, and the development environment will follow. Sorry to get preachy, but IMO, people get way too hung up on the language. The biggest thing I look for in a gig (well, after money, that is) is the people I'm working with. I'll program in any language if I can work with smart people. By the way, the D community is filled with smart people. D is a great language, but I've stuck with it mostly because of the community, not D itself. -- ~John Demme me teqdruid.com

Jun 27 2007
prev sibling next sibling parent Walter Bright <newshound1 digitalmars.com> writes:
John Demme wrote:
   IMO, certifications are worthless.

Yup. FWIW, I have no programming certifications. My 'certification' is mechanical engineering. I could (well, used to be able to) design you a nice jet engine.
Jun 27 2007
prev sibling next sibling parent reply Sean Kelly <sean f4.ca> writes:
John Demme wrote:
 
   IMO, certifications are worthless.

In programming, I'd agree. But some other areas, perhaps not. Getting a Cisco certification can double the salary of a net admin, for example.
   Personally, I shy away from gigs for "C++ programmers" and the like,
 because I'm a problem solver, not a C++ monkey.

The problem is that job requirements are often very specific these days, and the front-line recruiters often don't know anything about the jobs they're recruiting for. Telling them "I'm a problem solver" implies "I don't know anything about keywords X, Y, or Z." If the front-line person is a headhunter or a HR rep for a large company, that can mean never hearing about a job in the first place, or simply not getting an interview if you do. It's really ridiculous how hiring practices work these days, but in general, it pays to put every acronym, language, etc, that you know on your resume and can help to specifically target the ones you enjoy working with during your job search. For example, I've had people ask what my "specialty" is before, and an evasive answer can be enough to end the conversation. I'll admit what confuses me most about the way things work now is non-compete agreements vs. the desire for specialists. Employers typically want to hire someone with very specific, focused, and current experience in a particular area, which is inherently incompatible with non-compete agreements (at least in theory). Fortunately, they aren't generally enforcible.
 That said, it is unfortunate that D doesn't have wider acceptance.  I guess
 companies like to standardize on languages since they think it will make
 code more readable to the general employee coder populace and thus increase
 code reuse and cut development time- too bad that's not the case. 

I think D will break into the market through small shops, who have a smaller associated cost for adopting a new language or technology. Large companies often use a really horrid selection of tools and such, simply because they've been around long enough that it's easy to hire people that know the thing, infrastructure is built internally to support it, solid service contracts may exist for the associated products, etc.
 Sorry to get preachy, but IMO, people get way too hung up on the language. 
 The biggest thing I look for in a gig (well, after money, that is) is the
 people I'm working with.  I'll program in any language if I can work with
 smart people.

In light of what I said above, if you don't want to get pigeonholed as a Visual Basic programmer (for example), then consider avoiding jobs using Visual Basic. That said, the people are the deciding factor for any job. If you don't get along with them, look elsewhere. Sean
Jun 27 2007
parent reply John Demme <me teqdruid.com> writes:
Sean Kelly wrote:

 John Demme wrote:
 
   IMO, certifications are worthless.

In programming, I'd agree. But some other areas, perhaps not. Getting a Cisco certification can double the salary of a net admin, for example.

I'm not familiar with the Cisco certification, and I can't comment on pay concerning certs, but what I can say is that I've known a few A+ and MCSEs not worth their salt- so clearly the cert (in those cases) didn't mean much.
 
   Personally, I shy away from gigs for "C++ programmers" and the like,
 because I'm a problem solver, not a C++ monkey.

The problem is that job requirements are often very specific these days, and the front-line recruiters often don't know anything about the jobs they're recruiting for. Telling them "I'm a problem solver" implies "I don't know anything about keywords X, Y, or Z." If the front-line person is a headhunter or a HR rep for a large company, that can mean never hearing about a job in the first place, or simply not getting an interview if you do. It's really ridiculous how hiring practices work these days, but in general, it pays to put every acronym, language, etc, that you know on your resume and can help to specifically target the ones you enjoy working with during your job search. For example, I've had people ask what my "specialty" is before, and an evasive answer can be enough to end the conversation.

Yeah- it's unfortunate. I generally put the acronyms and buzzwords in my resume as well, for those reasons. It's not that I refuse to go out for jobs like that, they just get marked down in my book. Same goes for jobs where I gotta go through HR or a headhunter. I've applied for them, but not with the same vigor. I'd much rather work for a small company where the guy doing the hiring knows that HR and headhunters aren't much better than a decent grep! (Read: the guy wants smarts, not buzzwords)... In my (albeight limited experience) these are the environments where ya get the most exposure to experience. Just my preference, by the way! I know many, many people who like working for large companies. I'm not a fan, but maybe that's just because I'm not much of a social animal!
 
 I'll admit what confuses me most about the way things work now is
 non-compete agreements vs. the desire for specialists.  Employers
 typically want to hire someone with very specific, focused, and current
 experience in a particular area, which is inherently incompatible with
 non-compete agreements (at least in theory).  Fortunately, they aren't
 generally enforcible.

It's not just the non-compete agreements. I've been told that a lot of the IP agreements aren't enforceable, either. Ya know the ones that basically claim ownership of your soul? I hate those things!
 
 That said, it is unfortunate that D doesn't have wider acceptance.  I
 guess companies like to standardize on languages since they think it will
 make code more readable to the general employee coder populace and thus
 increase code reuse and cut development time- too bad that's not the
 case.

I think D will break into the market through small shops, who have a smaller associated cost for adopting a new language or technology. Large companies often use a really horrid selection of tools and such, simply because they've been around long enough that it's easy to hire people that know the thing, infrastructure is built internally to support it, solid service contracts may exist for the associated products, etc.

I agree. I guess that this is the answer to the original post, then! If you wanna program in D professionally, your best shot is to go for a small shop and prove it's a good tool!
 
 Sorry to get preachy, but IMO, people get way too hung up on the
 language. The biggest thing I look for in a gig (well, after money, that
 is) is the
 people I'm working with.  I'll program in any language if I can work with
 smart people.

In light of what I said above, if you don't want to get pigeonholed as a Visual Basic programmer (for example), then consider avoiding jobs using Visual Basic. That said, the people are the deciding factor for any job. If you don't get along with them, look elsewhere.

Speaking of VB, one of my oldest clients (and now a good friend of mine) is a VB guy. He never made the jump to C and skipped right on over to VB. Needless to say, I rag on him all the time for it. One of these days I'll get him to learn D! -- ~John Demme me teqdruid.com http://www.teqdruid.com/
Jun 27 2007
parent reply Walter Bright <newshound1 digitalmars.com> writes:
John Demme wrote:
 Yeah- it's unfortunate.  I generally put the acronyms and buzzwords in my
 resume as well, for those reasons.  It's not that I refuse to go out for
 jobs like that, they just get marked down in my book.  Same goes for jobs
 where I gotta go through HR or a headhunter.  I've applied for them, but
 not with the same vigor.  I'd much rather work for a small company where
 the guy doing the hiring knows that HR and headhunters aren't much better
 than a decent grep!  (Read: the guy wants smarts, not buzzwords)... In my
 (albeight limited experience) these are the environments where ya get the
 most exposure to experience.

Lots of larger companies have to sift through vast quantities of resumes. So they use (you guessed it) computer programs to do the initial sort. Those programs are pretty dumb, and just pull out keyword or phrase matches. So, if you don't use the buzzwords, no human will ever even see your resume. Of course, a much better way to get jobs is by cultivating relationships with people in your field. Around the Seattle area, coming to the NWCPP meetings is a very good way to get to know the local programming community.
Jun 27 2007
parent Sean Kelly <sean f4.ca> writes:
Walter Bright wrote:
 
 Of course, a much better way to get jobs is by cultivating relationships 
 with people in your field. Around the Seattle area, coming to the NWCPP 
 meetings is a very good way to get to know the local programming community.

Definitely. The ACM holds regular meetings and such as well, though their guild membership fee can be off-putting. Sean
Jun 27 2007
prev sibling parent reply eao197 <eao197 intervale.ru> writes:
On Wed, 27 Jun 2007 08:26:14 +0400, John Demme <me teqdruid.com> wrote:

 Don't become a D programmer.  Don't become a C++ programmer.  Don't  
 become a
 C# or a Java programmer.  You really don't want to become a Ruby or  
 Python
 programmer.

 Just be a programmer.  (Or engineer, architect, designer.. whatever)

It looks like: "Don't become a stomatologist. Don't become a surgeon. Don't become a oculist or a otolaryngologist. You reallu don't want to become a cardiologist or a neurologist. Just be a doctor!" If someone want to be a good D programmer (or C++, or C#, or Ruby) -- let it be. Almost any language has a lot of dark corners, idioms and best practices which a developer need to know to write efficient and bug-free programs. And it is very good if there is a language guru in your team who can help in searching bugs or bottlenecks. Obviously, the good knowledge of some language (or even languages) is not enough to be a good specialist. To be good specialist one needs good knowledge of his problem domain (embedded real-time software, very large databases, compilers, telecommunications, etc). Switching from one domain to another is not an easy task now. It's harder that ten years ago and will be much harder in the future. But at starting point in the start of career becoming a D programmer is much better than becoming abstract 'problem solver'. -- Regards, Yauheni Akhotnikau
Jun 27 2007
next sibling parent reply John Demme <me teqdruid.com> writes:
eao197 wrote:

 On Wed, 27 Jun 2007 08:26:14 +0400, John Demme <me teqdruid.com> wrote:
 
 Don't become a D programmer.  Don't become a C++ programmer.  Don't
 become a
 C# or a Java programmer.  You really don't want to become a Ruby or
 Python
 programmer.

 Just be a programmer.  (Or engineer, architect, designer.. whatever)

It looks like: "Don't become a stomatologist. Don't become a surgeon. Don't become a oculist or a otolaryngologist. You reallu don't want to become a cardiologist or a neurologist. Just be a doctor!"

Hearts and nerves aren't going to go away anytime soon, languages will come and go! When's the last time you programmed in PL/M? (I'd ask about Fortran, but for all I know you're a math guy.) Plus: I don't know a whole lot about becoming a doctor, but as I understand it, when you go you med school- that's what you do! Become a doctor! As I understand it, doctors won't typically specialize until after their residency via a fellowship, if they specialize at all. Anyone to confirm/deny? I don't really know what I'm talking about here. Anyway, specializing in a bodily system is more like specializing in a particular problem set (like getting a PhD- which I am in the process of considering, by the way.) Languages are more like tools. I'm not discouraging anyone from learning any particular language in significant depth. You're right- it's always great to have language gurus on the team, since they can spot a dumb sh*t issue a mile away. However, IMO a guy who really only knows a language and doesn't have any engineering skills, doesn't make for a great software engineer. It's like the difference between knowing a CAD software and being able to design a part. The guy who knows the CAD software real well is pretty helpful, but if he can't design the part, he's not an engineer. That's not to say he's not useful, however. I'm probably taking this to more of an extreme than I intend, but I'll say this: the smartest people I've worked with have told me that when it comes to hiring, they'll take smart and eager to learn over familiarity with the tools anyday. -- ~John Demme me teqdruid.com
Jun 27 2007
parent eao197 <eao197 intervale.ru> writes:
On Wed, 27 Jun 2007 21:24:00 +0400, John Demme <me teqdruid.com> wrote:

 eao197 wrote:

 On Wed, 27 Jun 2007 08:26:14 +0400, John Demme <me teqdruid.com> wrote:

 Don't become a D programmer.  Don't become a C++ programmer.  Don't
 become a
 C# or a Java programmer.  You really don't want to become a Ruby or
 Python
 programmer.

 Just be a programmer.  (Or engineer, architect, designer.. whatever)

It looks like: "Don't become a stomatologist. Don't become a surgeon. Don't become a oculist or a otolaryngologist. You reallu don't want to become a cardiologist or a neurologist. Just be a doctor!"

Hearts and nerves aren't going to go away anytime soon, languages will come and go! When's the last time you programmed in PL/M? (I'd ask about Fortran, but for all I know you're a math guy.)

I'm not a mathematician. I learnt computation mathematic (sorry, I don't know presice English term) in my University. But almost all my career I write libraries and frameworks for different areas and build different systems from them. I wrote my first program in Basic on tiny Soviet computer BK-1001 with 16K RAM in 1989. Then I learnt Pascal, C, x86 ASM, FoxBase, Prolog and C++ in the University, then was Java, then Ruby. I'm a C++ programmer since 1993. Now I use C++ and Ruby, sometimes D.
 Plus: I don't know a whole lot about becoming a doctor, but as I  
 understand
 it, when you go you med school- that's what you do!  Become a doctor!   
 As I
 understand it, doctors won't typically specialize until after their
 residency via a fellowship, if they specialize at all.  Anyone to
 confirm/deny?  I don't really know what I'm talking about here.

 Anyway, specializing in a bodily system is more like specializing in a
 particular problem set (like getting a PhD- which I am in the process of
 considering, by the way.)  Languages are more like tools.

I think there is some background that students must take during studying in university. For programmer it should include: basic data structures and algorithm, basic OS organization principles, basic compiler-related topics (grammars, parsing), basic databases principles (relational and object-oriented), some from functional and logic programming, some from mathematics, and so on. This background, IMO is like first years in medical university. But I think that strong knowledge in some language is necessary to successful start at the first job. Because it allows you to concentrate on problems domain, not on a language. (I don't know the situation in West Europe and USA, but here in former USSR there is some specific in equcation and hiring.)
 However, IMO a guy who really only knows a language and doesn't have any
 engineering skills, doesn't make for a great software engineer.  It's  
 like
 the difference between knowing a CAD software and being able to design a
 part.  The guy who knows the CAD software real well is pretty helpful,  
 but
 if he can't design the part, he's not an engineer.  That's not to say  
 he's
 not useful, however.

I worked with a very smart guy who was (and now is) a language guru and simply an encyclopaedia-man. He wrote programs very slowly. But he was very very useful member of our team. Also I think that it is impossible to learn someone to solve problems. It is a kind of human possibilities. Some people can detect and formalise problems, but unable to solve them. Some people can solve problems, but unable to organize proper implementation. Some people can write a lot of code but can't make good design.
 the smartest people I've worked with have told me that when it comes
 to hiring, they'll take smart and eager to learn over familiarity with  
 the
 tools anyday.

Yes. We're trying the same. But it is a very difficult task. But there is another side of the problem -- it is good to work with people who are smarter then you. But what worries me: do they want to work with me? -- Regards, Yauheni Akhotnikau
Jun 27 2007
prev sibling parent Bruno Medeiros <brunodomedeiros+spam com.gmail> writes:
eao197 wrote:
 On Wed, 27 Jun 2007 08:26:14 +0400, John Demme <me teqdruid.com> wrote:
 
 Don't become a D programmer.  Don't become a C++ programmer.  Don't 
 become a
 C# or a Java programmer.  You really don't want to become a Ruby or 
 Python
 programmer.

 Just be a programmer.  (Or engineer, architect, designer.. whatever)

It looks like: "Don't become a stomatologist. Don't become a surgeon. Don't become a oculist or a otolaryngologist. You reallu don't want to become a cardiologist or a neurologist. Just be a doctor!" If someone want to be a good D programmer (or C++, or C#, or Ruby) -- let it be. Almost any language has a lot of dark corners, idioms and best practices which a developer need to know to write efficient and bug-free programs. And it is very good if there is a language guru in your team who can help in searching bugs or bottlenecks. Obviously, the good knowledge of some language (or even languages) is not enough to be a good specialist. To be good specialist one needs good knowledge of his problem domain (embedded real-time software, very large databases, compilers, telecommunications, etc). Switching from one domain to another is not an easy task now. It's harder that ten years ago and will be much harder in the future. But at starting point in the start of career becoming a D programmer is much better than becoming abstract 'problem solver'.

Developers do specialize, but it's not in programming languages where it is relatively easy to transition to another language (especially in static, imperative style languages). Specializations for computer scientists/engineers are stuff like network administration, web applications development, game development, embbeded systems development, telecommunications, etc., where there is a lot of area-specific knowledge to be learned. -- Bruno Medeiros - MSc in CS/E student http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D
Jul 01 2007