Well if HR brings in a person inexperienced in the language then I'd blame HR, as it's certainly not the person's fault
Paired Programming... Does it work?
- Thread starter MrMcPhee
- Start date
Well if HR brings in a person inexperienced in the language then I'd blame HR, as it's certainly not the person's fault
A programmer is a programmer. You're using their design, modeling and intuition. You wouldn't employ a typist for programming. Long, long gone are the days of code cutting. 
Besides, having to take on new languages is the norm for programmers, unless you are archaic enough to let the language dictate what is applicable, instead of the needs of the project?
Besides, having to take on new languages is the norm for programmers, unless you are archaic enough to let the language dictate what is applicable, instead of the needs of the project?
Would be keen to try pairs programming but in our place it is just not feasible. We work on small projects teams and the resources would never be available. Also most of the work I do is SharePoint development so its not developing all the time. One day writing batch scripts for some admin stuff, then building webpart the next etc etc.
Definitely wouldn't call myself a full time developer! I think pairs programming would work until I had a lot more experience. The buddy wouldn't like me constantly googling for how to do something!
Definitely wouldn't call myself a full time developer! I think pairs programming would work until I had a lot more experience. The buddy wouldn't like me constantly googling for how to do something!
A programmer is a programmer. You're using their design, modeling and intuition. You wouldn't employ a typist for programming. Long, long gone are the days of code cutting.
Besides, having to take on new languages is the norm for programmers, unless you are archaic enough to let the language dictate what is applicable, instead of the needs of the project?
I totally disagree.
The market is still swamped with programmers which just cut code without a single thought to design or modelling. Some don't even possess basic logical thinking or intuition either.
Unfortunately the good ones are few and far between.
If a project has 200,000 line of source written in Java then, unfortunately, any new recruits are going to have to know Java. That's just how it is. I wouldn't call this archaic. Maybe I misunderstood what you meant.
We're in differing markets and/or paradigms
We're writing mostly bespoke software, green field stuff, but we do apps that are legacy and are still our bread and butter work - though that doesn't stop us from moving onto other platforms depending on the requirements. A couple of the apps were written in VB (classic) but we've got modules written with .NET, Smalltalk, Java, and some small pieces in various script languages (PHP/Perl/other). All depending on what is needed for the task. If it's a new web service, then it's likely to be .NET for WCF. If a need web portal is needed, Smalltalk (and Seaside) for anything significant, or PHP/JSP for smaller stuff.
Basically, we're not lumbering ourselves with one platform and language.
I do agree the market is swamped with code cutters, but that's just the employment market.. the business market needs designers and architects, not glorified secretaries.
We're writing mostly bespoke software, green field stuff, but we do apps that are legacy and are still our bread and butter work - though that doesn't stop us from moving onto other platforms depending on the requirements. A couple of the apps were written in VB (classic) but we've got modules written with .NET, Smalltalk, Java, and some small pieces in various script languages (PHP/Perl/other). All depending on what is needed for the task. If it's a new web service, then it's likely to be .NET for WCF. If a need web portal is needed, Smalltalk (and Seaside) for anything significant, or PHP/JSP for smaller stuff.
Basically, we're not lumbering ourselves with one platform and language.
I do agree the market is swamped with code cutters, but that's just the employment market.. the business market needs designers and architects, not glorified secretaries.
It sounds like you have lots of little projects on the go, with new ones arriving all the time. Therefore it's no surprise that you can recruit easier because you can simply give one of these "green field" projects to your recruit and let him get on with it. Nor is it surprising that you choose the most appropriate language/tool for each project. Wouldn't everyone?
Unfortunately for us any new recruit has a rather large code base to become familiar with before they can even begin making worthwhile contributions to it.
This is an epic tangent BTW
Unfortunately for us any new recruit has a rather large code base to become familiar with before they can even begin making worthwhile contributions to it.
This is an epic tangent BTW
Pah, Tangents are nothing new to Agile
We've got huge legacy codebases as our bread and butter work, with the green fields projects on the sides. 90% of our workload is with legacy apps, and some of it hideously nasty (the app is now nearly 15 years old so no surprises really.)
We've got huge legacy codebases as our bread and butter work, with the green fields projects on the sides. 90% of our workload is with legacy apps, and some of it hideously nasty (the app is now nearly 15 years old so no surprises really.)
Besides, having to take on new languages is the norm for programmers, unless you are archaic enough to let the language dictate what is applicable, instead of the needs of the project?
What size company do you work for?
Everywhere I've been, which has mostly been large companies - in the tens of thousands of employees, has had policies about the languages/frameworks that can be used regardless of suitability for the project.
Of course they're not going to limit things completely so you end up with ludicrous choices of languages for what you want, but at the end of the day introducing something new increases risk to the business as well as making it more of a headache for the various support teams.
Would be nice to be able to pick a language purely because we thought it was the best choice for the current project!
Currently I'm in a small company, but have worked for tansnational companies before, and I can appreciate the difficulties involved in integrating a new language into a large company, but tbh.. it's still not that much of a headache. Support groups will have to learn for any given new product, and a massive majority of problems with the product will/are reported for the developers to investigate anyway.
Most large companies will have policies on language choice based on one simple presumption: Who can they blame if it goes breasts up. This means, of course, that Open source is out the window. Java has Sun to blame, and .NET of course has Microsoft. There is also the intergration (which some regard as their monopolisation) of .NET with Windows.
Most large companies will have policies on language choice based on one simple presumption: Who can they blame if it goes breasts up. This means, of course, that Open source is out the window. Java has Sun to blame, and .NET of course has Microsoft. There is also the intergration (which some regard as their monopolisation) of .NET with Windows.
Last edited: