|
See, a definite answer is hard to give but let's look at it this way. You don't know how to swim and you don't know the depth of the water but you are told to jump into the river. Do you thinking that when you're in that river you'll be able to start learning basic swimming procedures like floating and strokes? I think knowing the basics will help on the way.
|
|
|
|
|
If I don't know the language, how would I understand what someone is asking me to do?
CQ de W5ALT
Walt Fair, Jr., P. E.
Comport Computing
Specializing in Technical Engineering Software
|
|
|
|
|
eh?
Business requirements all the way down to stories and pseudo code should all be language agnostic. There may definitely be technical hurdles depending on the framework you're using, but that should not e issue until you're well and truly neck deep.
cheers,
Chris Maunder
The Code Project | Co-founder
Microsoft C++ MVP
|
|
|
|
|
eh? Oh you austral/canadians.  
I promise that if you ask me in Russian to work on a project, the chances of me understanding it are really, really slim.
CQ de W5ALT
Walt Fair, Jr., P. E.
Comport Computing
Specializing in Technical Engineering Software
|
|
|
|
|
Man up and stop ya whining!
I dunno - these young kids, too scared to do a fair day's work. When I was a lad...
cheers,
Chris Maunder
The Code Project | Co-founder
Microsoft C++ MVP
|
|
|
|
|
Chris Maunder wrote: these young kids, too scared to do a fair day's work. When I was a lad...
Yeah, I know what you mean. 
However, whatever I do is by definition a Fair day's work. 
CQ de W5ALT
Walt Fair, Jr., P. E.
Comport Computing
Specializing in Technical Engineering Software
|
|
|
|
|
I like to dive in and then i try to understand syntax and all necessary things.
Rating always..... WELCOME
The only reason people get lost in thought is because it's unfamiliar territory.
|
|
|
|
|
Agree! 
// ♫ 99 little bugs in the code,
// 99 bugs in the code
// We fix a bug, compile it again
// 101 little bugs in the code ♫
|
|
|
|
|
|
Was going to make a long-requested app for in-house use. The "power-that-is" insisted I write it using Visual FoxPro.
His reasoning was, as one might expect, inane. Particularly so since Micro$oft announced they are dropping the language. Furthermore, he insisted that it be incorporated into another application which is already rather monolithic and suffering under its own weight. There is even more to this adventure, and the depravity only gets worse.
Progress was slow and error rate was high, wasting company time (mine and the requester's).
I was wondering: are programmers allowed an occasional summary execution to keep the management herd appropriately culled?
| "The difference between genius and stupidity is that genius has its limits." - Albert Einstein | | "As far as we know, our computer has never had an undetected error." - Weisert | | "If you are searching for perfection in others, then you seek disappointment. If you are seek perfection in yourself, then you will find failure." - Balboos HaGadol Mar 2010 |
|
|
|
|
|
I believe that before actually getting into the coding part, it's good to set some time aside and look at how the language works. Does it look very similar to what you already know or so (Let's think C++ and C#)? Or will it require quite an amount of understanding before something in the task gets done?
I would say that analyzing these would give you a great idea about where you stand. That should give you a headstart on what you need to learn and would prevent any situations where you would have to face your boss at the last minute and say "I need more time". The answer will be "Great. So remind me again why you didn't tell me sooner about this?"
My Blog
My Achievements:
* Posted 25,000th message in GIT O_O
* Official supporter of the "thatraja's GIT Meet Sponsor Foundation"
What you do, when you don't know what to do is what you do when you don't want to do what you do.
|
|
|
|
|
Write a couple small programs on your own first. Find out what the language can do and how to do some of the things that you suspect may be required in your own throw away apps before you have to make it work in an application that you could have a long shelf life. Best to do it outside of the microscope of an actual project.
Also you want to know a little bit more about what you are doing before you have a project manager or owner or sponsor breathing down your neck about deadlines.
The likelihood of having to learn a whole new language from scratch is probably much more rare than having to learn a new technology or technique, but you may go through many of the same pains. Think about learning reflection, regular expressions, jquery, css, wcf, wpf, nhibernate, mvc, etc. In all of these cases, you could still be programming in c# but feel like you have a new language to grapple with.
|
|
|
|
|
I learn best by doing. I would agree with the first two options: dive in and learn as you go AND learn before starting. An iterative approach works well. Learn a little, apply a little, learn a little more, apply a little more and so on. Important to take time to learn the language while solve the problem. I've found, even after years of experience, I still need to take time to dive deeper into nuances of a language, especially any new features of the language.
|
|
|
|
|
I agree; I think I'd start on a small aspect of the final system/program whatever it was that I'd then re-write once I learned more about the language.
|
|
|
|
|
If the project used some obscure language that wouldn't be used in other projects then I would consider not doing it, or at least not putting to much time into learning the language in depth
I know the language. I've read a book. - _Madmatt
|
|
|
|
|
your manager and lead programmers decide that it's best to tackle the new project at hand in a language that you don't know. And you are given a choice to either remain in that team or move to any other team that continues to use the language you are comfortable in.
What would you do and why?
(I hope no body mind this being asked here.)
|
|
|
|
|
Learn new stuff.
Always learn new stuff.
Cos I like learning new stuff and get bored easily.
Every man can tell how many goats or sheep he possesses, but not how many friends.
|
|
|
|
|
Depends on the relationship within the team, don't like the manager or majority of co workers within team. move.
have a decent professional relationship with the team and get along with everyone learn new language.
either way i think most of us would probably do a little research on the language whichever team we ended up in :P
|
|
|
|
|
The answer would very much depend on the circumstances - is that language adoption step in the right direction regarding technology, someone's career aspirations and interests and many other things.
Most people wouldn't react the same way if offered (today) to do the HTML5 of some future Win 8 development (whatever the platform might be) - or offered something along the COBOL/classic VB/ FORTRAN line.
General answer to this question is almost imposible to give.
|
|
|
|
|
I absolutelly agree with this opinion.
On the other side, tools are just... tools.If you are an experienced, expert software developer, and you have a clear vision of the solution to the problem you must face... tools come in second place. Solving the problem is the hard part.
|
|
|
|
|
Your life doesn't depend on the answer you give in this survey, and the question, when you think about it, is "Are you brave or foolhardy enough to dive in without checking the depth of the water".
Obviously specific circumstances mean a different specific answer, but that rule applies to almost everything except mathematics. Go crazy and give us the 75% applicable answer.
cheers,
Chris Maunder
The Code Project | Co-founder
Microsoft C++ MVP
|
|
|
|
|
Despite my comment, I have already gone crazy and voted.
Still, the question could have been much better formulated; Not everyone would come to same conclusion as you. I haven't.
|
|
|
|
|
In 1997, I was walking around the pond in back of our office in Marlton, NJ while my boss puffed away on his Marlboro beside me as we discussed the state of affairs on one of my projects. I asked him, incidentally, how many programming languages (including OS script languages and assembly languages) he'd used professionally. He'd lost count; by that time, I myself was up to about eight or ten and was busy learning a new one called PL/Trim (a "4GL" used at that time (and maybe still) by Boeing and three other customers, of whom we might have been the smallest). All their software was in PL/Trim except for some library routines written in C.
In 2001, I got a job to develop an interactive voice-response (IVR) application very similar to the one I'd built in 1998 in Visual Basic - only this time, I had to build it in Java, a language with which I was barely familiar, and I had to find a test platform to run it on. I did both, and had a working prototype ready in three months.
Back at the beginning of my programming career, my first permanent programming job required a C programmer, which I had become without benefit of formal training - my debugging technique in C was sufficiently sophisticated that my new boss decided I was worth the risk. So even then, I was working with languages that I was learning as I worked.
It still stuns me sometimes how many programmers out there have never, ever programmed outside of one or two languages, usually their primary development language and the script language used by their primary operating system.
|
|
|
|
|
Agreed! More or less in order, I've programmed professionally in IBM 1620 assembly, FORTRAN, Algol, Basic, Z80 assembly, Forth, Pascal, C, C++, Prolog, Java, VBA, VB, C#, Javascript, PHP, PIC assembly, F#, and probably a few more. I've also programmed for curiosity or fun in GOTRAN, PL/I, COBOL, SNOBOL, Python, Ruby, and who knows what else. Besides JCL's, etc.
It always amazes me that there are programmers who are afraid of diving in and learning a new language on the fly.
CQ de W5ALT
Walt Fair, Jr., P. E.
Comport Computing
Specializing in Technical Engineering Software
|
|
|
|
|
Actually, I can read the code in Visual Basic language as my co-worker writes. However, I can't write in that language. I can manual convert the VB code into c#.
|
|
|
|
|
Well I use a mix of the first two options.
I start by learn the fundamentals then dive in... increasing my knowledge as I get more involved.
The shadow of the past is reflected in the future!
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
