Hello Friends, I have a question and I needed an experienced programmer to answer me

First of all, sorry if my english is not the best...

Well Im new here as you probably guessed, and I would be glad if some experienced programmer, someone who works as a programmer, answers me. Im the kind of guy who passes his whole day inside his room, reading about programming, and programming... I have "programmed" for some time now, and I dont think Im a begginer... But I dont think I have the "level" of a profissional either...And thats what I wanted to ask... I know that Im not a begginer, and I know that Im not a expert either, Im somewhere in the middle... So my question, as you should already know, is "how do I know if I have what it takes to WORK as a programmer"? What do you think I should know to work as a programmer?

I really love programming, and if liking it makes me a good programmer, then theres no one better... But how do I know if my knowledge is enough to start working as a programmer?

I really like C and C++, and you know this two languages are for true developers, not the easiest... I think it would be easier to work as a vb or Java developer, but I want to be a C++ developer.... How do I know if I have what it takes to call myself a "C/C++ programmer"? Knowing all of the language features makes me a C++ programmer? What do I have to know?

Thanks

This is a good question, I'm interested in seeing the replies :)

From my experience, anybody can work as a programmer. Just do many interviews and one of them will be stupid enough to hire even someone who has never programmed before.

Quote:

---

Originally Posted by EVOEx

From my experience, anybody can work as a programmer. Just do many interviews and one of them will be stupid enough to hire even someone who has never programmed before.

---

But would it not be evident afterward that the individual has no experience?

Quote:

---

Originally Posted by pobri19

But would it not be evident afterward that the individual has no experience?

---

If anyone working on the company had any experience then, yes. And sometimes you may get fired in that case. But if not, you have plenty of time to completely start coding from scratch and learn while employed by a company.
In fact, some time ago I came to a company as a consultant. They had one coder who did produce some code, but when I looked at his code it looked vaguely familiar. After doing some researching I found out that the code was some slight modified portion of code from open source software.
After I found out, I studied more of his code. Every single bit of it was copied from open source projects or free source code on websites. The guy couldn't program at all. He could copy code and slightly modify it.
He was obviously fired immediately. But had I not come to the company, he would probably still be coding there now, copying code. And maybe after a while someone would find out the company violated the GPL and every other license on the planet.

My point is not that you shouldn't be a good coder to get a job. But you don't have to. Some companies will be stupid enough to hire bad programmers. You might even get some free posts on thedailywtf.com...

But do you, Dante, have the experience to be an actual coder in a valid company? Who knows? I've never seen any of your coding. So there's no way I can possibly tell. And even when you show code it begs questions like; did you use any tutorials to write it, did you copy anything from the web, and how long did it take you to write.

I find this thread interesting as im planning to start uni next year after hobby coding for almost a year and a half, I think after a year and a half of studying by myself (and i study alot) I know a fair bit but not near enough to get job. Not without proper training.

When trying to get a job as an entry level programmer, don't aim for the sky.
Do NOT think you can get a job as a "C++ programmer" or "Java programmer", or especially a "game programmer".
Take any entry level programming job you can get, which will likely involve on the job training for the tools and technologies being used.
The company will correctly assume you know nothing and set their expectations of you accordingly, assuming mainly you have a willingness to learn and perform rather than any preexisting knowledge whatsoever (as anyone who's been in the industry for a while knows, there's nothing more dangerous than a fresh graduate who thinks he knows things).

The job won't be glamorous, you may spend several months maintaining SQL scripts for some batch processes on the side of a mainframe application, but it's a programming job and you'll get hands on experience in how programming teams work.

I've been doing programming on my own for about 4 years now (no formal education at all), and just landed on a "game programmer" job as an intern (EA gave me an in-studio interview, too, but didn't want me in the end).

Hobbyist experience certainly helps a great deal. I got 3 job offers for "software developer" jobs, when most of my friends could only get QA positions, if even that.

How did you get around them asking for commercial experience or whatever? and did you show them a portfolio of work or what? What about them (i imagine) expecting formal qualifications? I am just interested as there is a lot of programming entry level and junior developer work here right now, a lot, the damn thing is they all asking .net or c# of one form or another so i will have to get that under my belt before i can even consider trying my luck like that. Well done yourself with the job though..was it in C++?

sometimes showing that the "requirements" make no sense helps.
Like they ask for someone in their early 20s (that's no longer legal, but reading between the lines it's usually obvious, like asking people for "our young and dynamic team") with at least 10 years of professional experience using Visual Studio 2010.

Quote:

---

Originally Posted by EVOEx

If anyone working on the company had any experience then, yes. And sometimes you may get fired in that case. But if not, you have plenty of time to completely start coding from scratch and learn while employed by a company.
In fact, some time ago I came to a company as a consultant. They had one coder who did produce some code, but when I looked at his code it looked vaguely familiar. After doing some researching I found out that the code was some slight modified portion of code from open source software.
After I found out, I studied more of his code. Every single bit of it was copied from open source projects or free source code on websites. The guy couldn't program at all. He could copy code and slightly modify it.
He was obviously fired immediately. But had I not come to the company, he would probably still be coding there now, copying code. And maybe after a while someone would find out the company violated the GPL and every other license on the planet.

---

LOL. Wow, that's freaking hilarious.

Quote:

---

Originally Posted by rogster001

How did you get around them asking for commercial experience or whatever? and did you show them a portfolio of work or what? What about them (i imagine) expecting formal qualifications? I am just interested as there is a lot of programming entry level and junior developer work here right now, a lot, the damn thing is they all asking .net or c# of one form or another so i will have to get that under my belt before i can even consider trying my luck like that. Well done yourself with the job though..was it in C++?

---

I guess it's partly because I applied through my school's co-op (internship) program, as an electrical engineering student... so they know what to expect.

I'm assuming "real" software developers get paid more than $20/hr :P. But it's about as high as internship positions pay around here. And the job is pretty cool (very few people can get developer jobs in second year).

I did show them a few of my bigger personal projects, and they asked me tons of questions on those. I think it really helps because it shows them you are really passionate about programming, not just trying to get ANY job. I've also participated in programming competitions with pretty good results, so that could have helped, too. They also asked me some very technical questions about C++ and programming in general.

C# is listed as a requirement, and I plainly told them I know nothing about it. They didn't mind. They said it's just for tools and I can probably pick it up on the job quickly (both EA and the company I'm actually going to be working for). The "actual" codebase is in C++, so they are a lot more concerned with that.

I'd say give it a try anyways! As long as the job is not purely .net/C#. They don't really expect you to be experts in those languages either, just enough to get by, and know how to Google the rest.

Quote:

---

Originally Posted by Dante Wingates

I really like C and C++, and you know this two languages are for true developers, not the easiest... I think it would be easier to work as a vb or Java developer, but I want to be a C++ developer.... How do I know if I have what it takes to call myself a "C/C++ programmer"? Knowing all of the language features makes me a C++ programmer? What do I have to know?

---

If you really want to be good at C++, then just keep using it and you will eventually be good at C++. Don't doubt whether you can or cant make it. Or as Yoda says "Do, or do not; There is not try".

Becomming a virtuoso pretty much just takes time and dedication.

Quote:

---

Hobbyist experience certainly helps a great deal. I got 3 job offers for "software developer" jobs, when most of my friends could only get QA positions, if even that.

---

Since C++ is rarely taught in any schools now one should not under-estimate the value of coding on your own time and continually learning more and more about the language and the application of it.

Coding on your own time shows me:

• Initiative
• Willingness to learn
• Most likely has good problem solving skills or is continually refining them
• Passion - not everyone is sick enough to code at home
• Does not rely solely on one source for all their programming knowledge - knows how and where to find solutions

Having interviewed many graduates I can say that about 90% of them only did programming while at school. Most of them stopped coding the day they graduated. This doesn't show me they can hit the ground running when they come on board.

The most important thing you can do before an interview is prepare. Read Bjarne's book or read another book but at least prepare to answer difficult problems and show some code on the old whiteboard. Right now if you are familiar with C++ and you have significant experience with it at home or professionally your skills will be attractive to a C++ studio and possibly a C# studio since you can pick that up very quick if you know C++. Most schools are still teaching Java which doesn't help any of the companies that do not use it. One could say that fundamental CS transfers to every language and it does but in my experience most candidates are Javaites in that they know CS only as much as it relates to Java...which isn't helpful at all. Someone along the way told them that if they know Java then they know or can do C++ and in my experience this is simply not the case.

It's also very good to be honest in your interview. Don't embellish your resume b/c you probably will be asked about it and if you just plain don't know something then say so. However if you know how to find solutions and how to research that is just as valuable or IMO more valuable than knowing the answer. C++ knowledge comes down to exposure levels. Some have more exposure to more technologies and more intricate portions of the language and others have less exposure. However if you are very comfortable with the language and you can do well on a C++ test (Brainbench or the like) then I would certainly encourage you to apply. If you are going to apply at a game studio make sure you are a gamer and love games. You should be familiar with the industry, it's various popular engines, and you should know what you like and dislike about certain games and certain engines. That will look very good. Most game studios will be looking for a 4-year degree but not all of them require it and because most colleges don't teach a lick of C++ studios are realizing that C++ programmers are becoming more scarce by the day. If someone asks you to write code to allocate some memory and all you can write is Java code...knowing that the primary language is C++ or C#...then you probably are not going to get the job.

Last I checked there are a lot of game studios hiring. I know for a fact that Stardock is hiring as well as many other studios. Check the jobs section at www.gamasutra.com or you can also google for indie game companies. You are probably more likely to get on at an indie studio than a big name studio like EA. I'm sure Infinity Ward is looking for people now that their core staff quit or were pushed out due to internal issues. Several of my former co-workers either came from game studios or have moved on to game studios so it's not impossible to get in.

Moved to GD.

Quote:

---

Originally Posted by EVOEx

But do you, Dante, have the experience to be an actual coder in a valid company? Who knows? I've never seen any of your coding. So there's no way I can possibly tell. And even when you show code it begs questions like; did you use any tutorials to write it, did you copy anything from the web, and how long did it take you to write.

---

Well, to be honest I do read a lot and often use what I've read in pratice, but the reason I started programming was mainly because I dont like being dependent of something to do something... For example: many times I've seen ppl talking about what they did, when they would never be able to do it without the program they used... And who was the real responsable for their "deeds"? The one who made the program... It just would not feel right to me to take credit for something that wasnt me the one who did.

This is the same reason that makes me liking C++ so much, and even the reason that made me learn enough english to write, read and understand ppl talking... Years ago when I first tried to program it was in Visual Basic... But I hated the fact that Visual Basic was so "IDE dependent"... I made many programs using vb, but I really didnt felt that was me the one who did it(as I said before; dependent of a program), even though I avoided using the visual interface the more I could... In the end, I always wanted to have control over what I was doing, and that led me to C++...

Many times what I like to read and understand are things that people say that are useless today... Like low level programming, writing a program without any help(like IDE)... I know that IDEs are a great help, yes, but I always seek to know what is going on behind the scenes... I wanna know how a function does something in particular, not what it does... I dont know assembly yet, but I'll give it a try sonner or latter...

What I talked until now was all about how I treat things, not my actual "level"... But lets say that I can express my toughts in C++, and always was able to make what I wanted... if I cant work as a programmer yet, I think sonner or latter I'll be able to... What made me coming here and asking this question was just because many people that I know always say that studing alone is useless and that without some certificate I'll never get anywhere... I've heard things like that for more than 3 years now, but recently I thought "Will I ever get anywhere, or is it all useless?"...

I must confess that in the beggining I did not intended to work as a programmer, but after so much time spent programming I cant really imagine working as anything else...

Can someone say what I should know before trying to work as a programmer? Is C/C++ enough? This way I would know if I already have what it takes, or if I dont know something yet, then I'll know what I need to know.

thanks

@bubba. wow thanks for some great advice there from the -other side of the desk- that is some good food 4 thought and great points in there for cover letters. in general i am interested t hear what sort o standard project may be done by final year graduate, the tech level reached compard to equivalent coding of 4year hobbyist say

Quote:

---

Originally Posted by cyberfish

I'm assuming "real" software developers get paid more than $20/hr :P.

---

don't be so sure...
$20 an hour is a pretty decent salary for a programmer with severa years' worth of experience here, more than a junior would get on his first job.

Of course that doesn't include benefits like pension plan, company health insurance plan, maybe a company car, cellphone, etc.

For me it just happened. One day I was doing night shift backups on a IBM ES9000 at my first job in Alcatel, with only self-taught programming knowledge in Pascal and DBase, the next day I was learning about programming said mainframe in Cobol.

Didn't do it for long though. Before my experimental period finished, not knowing for sure if I was going to stay, I looked for and found a better job at a company that was looking for experienced Clipper programmers. Having only dabbled in Clipper, but because I was confident of my abilities (back then programmers were like needles on a haystack), I thought it would be a good idea to apply. I was accepted and it took me maybe a couple of weeks to get up to speed with the rest of the team.

From then on, I became a professional programmer. I also became someone who didn't want to be a professional programmer. The profession choose me.

I used to be a youth pastor and then a factory worker. All along the way I coded into wee hours of the night doing this or that. I started way back in the DOS 2.10 days with BASIC and then moved to C++ in the early 80's. Because of this I was able to get a lot of exposure to interrupt handlers, DSP chips, DMA, VGA/SVGA, and other nasties we take for granted today. Then I started learning assembly language which really opened things up for me as far as code goes. When it came time for school I chose a different path which turned out to be something I really did not enjoy doing. For some time the members on this board encouraged me to apply for a professional programming job and b/c I was intimidated by not having an actual CS degree I didn't. Finally I grew tired of my work at the factory and just sat down one night and sent out resumes. I was completely shocked by the results. Many phone calls came in and although they were looking for P2's they were still interested in me. Finally I applied at one company and everything worked out. They even waited for my wife to have our child so I could come interview. Amazing.

Now that I have been programming in the workplace for about 3 years I can say that my worst fear was absolutely absurd. I was only intimidated at work for about the first month or so until I realized that my vast range of experiences both in programming and management made me more than qualified for the job at hand.

Since then I can say that moving to professional programming was the best decision I ever made. And while I can't say there aren't days where I just want to stay home with the fam I can say that the job is extremely rewarding, challenging, and a lot of fun.

Lesson learned. Don't let anything intimidate you out of your career choice. If you are young enough and have the chance to attend university for computer science then by all means do so. However if you are older, as I was, and already have a degree in another field but have significant programming experience and knowledge then go for it.

I can guarantee one thing....if you don't apply you won't get a programming job. The one difference between me and those that have a CS degree is I tend to think outside of the box that colleges put them in. It is the same for me when it comes to ministry. Since I was formally trained in the area I am more apt to follow what my professors told me works and what I should never do which sort of puts me in a box. Others who minister and have little formal training but just have a passion for it are often times a bit more effective than someone like me b/c they don't have the 'box'. I see this all the time in the programming field as well. It doesn't happen to everyone and some who have attended college could care less what they were told to do and not to do. But, in general, I find that higher education often does try to put you into a box or mold and later in your career as things and times change...it is often very hard to adapt.

This thread is kind of silly.

Being good at something is as much about having confidence in it as it is about experience. If you walk into a room knowing you can solve whatever problem gets thrown at you, other people will pick up on it... even if you actually can't.

Programming isn't about languages or styles or syntax or experience. Programming is about solving problems - if you can solve a problem, you can program. In some cases, the problem you're trying to solve is "how do I implement this solution in that language?"... but it's still just another problem. Professional programmers don't care about what languages they know, and most employers don't care about what languages they know. All people care about is results.

The short version is when you're "ready" to program professionally, you won't need to ask. Confidence has to be earned, but when it's there you'll know it.

Quote:

---

The short version is when you're "ready" to program professionally, you won't need to ask. Confidence has to be earned, but when it's there you'll know it.

---

That is silly.

Quote:

---

Professional programmers don't care about what languages they know, and most employers don't care about what languages they know.

---

Equally as silly since every job posting requires one or more of certain languages.

Quote:

---

All people care about is results.

---

And how do you get results when you don't know the languages?

Quote:

---

Programming is about solving problems

---

....in code.

Problem solving ability alone does not make you a programmer but knowing how to solve problems as a programmer makes you a better one.

Quote:

---

Originally Posted by Bubba

I used to be a youth pastor and then a factory worker...

---

I was almost moved to tears by this Bubba (happy tears, of course). Great story about bringing your nocturnal activities into the light and finding your path, dude.

Quote:

---

Originally Posted by Bubba

And how do you get results when you don't know the languages?
....in code.
Problem solving ability alone does not make you a programmer but knowing how to solve problems as a programmer makes you a better one.

---

I think you have to think about a problem largely in terms of the language you are using. I know there is a lot of theoretical algorithm analysis around that is language independent, and a solution from one language almost always can be found in another* -- BUT I think the many of the "tools" you have are not conceptualized much in that theory. They tend to be real aspects of a real language or technology, not abstract components of problem solving in some vague general sense. It's easy to imagine what a great movie you could make, however, that is not most of the real work, time, and concentration that needs to happen before the movie is finished. Of course, a great idea is always a great idea.

Either that or most of the problems I seem to need to solve have to do with a language/technology and it's use. :p

* altho they can involve exploiting radically different possibilities

Quote:

---

I was almost moved to tears by this Bubba (happy tears, of course). Great story about bringing your nocturnal activities into the light and finding your path, dude.

---

Hehe. I didn't want to divulge my entire life story but did want to encourage the OP. :) It almost felt like a 'one time at band camp....' story. :D

Often things in life don't go exactly as we would like or envision. So I played the hand of cards I was dealt the best I knew how and it worked out. Would I like to return to school at some point to further my education? You bet. But for right now making money is working out just fine for me.

So to the OP...go for it. Do what you can now to prepare and then start sending out resumes or applying to colleges if you are at that point in your life. And by all means come back and share with us how you are doing along the way.

As a person with little formal training on the software end of things (Started in hardware) one basic thing that helped get my foot in the door so to speak at least three times in my career was to have an example of your work handy. When I started and had no "professional" experience I wrote an electronic resume, literally a (then DOS-window based) program that when run allowed the user to see the kinds of stuff I had coded in my own time. The kicker was to distribute the source code to it along with the resume. So while I had no professional experience, I was able to demonstrate that I understood UIs (the resume itself), good clean coding practices (the source), OO (which was a big draw at the time) and so on. This allowed me to make the jump from hardware-only work into software. Yes it took a few interviews but I made it into a software consultancy.

Later when I was trying to get to the "big leagues" (Southern California in the dot-com boom) I wrote a Windows-based version of the same thing which landed me a key position at Kinkos corp. headquarters in Ventura CA. Then many years after that I moved to an area that most employers demanded degrees, I ran an open source project on Source Forge and ran a number of articles in a known trade rag. That helped get me the gig I have today.

Oh as for the fellow who said languages don't matter,that is bunk. If you know the secret to the universe but have no way to express it, does it really matter?

Quote:

---

Originally Posted by Bubba

Equally as silly since every job posting requires one or more of certain languages.

And how do you get results when you don't know the languages?

....in code.

Problem solving ability alone does not make you a programmer but knowing how to solve problems as a programmer makes you a better one.

---

The time it takes people to learn to solve all kinds of difficult problems and write algorithms - years. The time it takes to learn a new language which is similar to one you already know - weeks (possibly less).

One thing I've learned so far - language is the least of your problems.

Quote:

---

Originally Posted by maxorator

The time it takes people to learn to solve all kinds of difficult problems and write algorithms - years. The time it takes to learn a new language which is similar to one you already know - weeks (possibly less).

One thing I've learned so far - language is the least of your problems.

---

That's preposterous. If you want to count your infancy and childhood as time spent learning problem solving, okay. But if you are trying to claim that you spend most of your time as a programmer doing problem solving sans coding, I'm kind of curious what kind of programming that amounts to.

The time it takes to get a basic grasp of "algorithms" as concept if you can program, and you have never heard the word "algorithm" before -- less than one day, most likely less than 1/2 hour.

The time it takes to understand and implement a particular algorithm -- 10 minutes to two weeks.

The time it takes to learn a new language at a basic level -- days to weeks.

The time it takes to learn something resembling a level of expertise or mastery with a language -- months and years.

Quote:

---

Originally Posted by MK27

That's preposterous.

The time it takes to get a basic grasp of "algorithms" as concept if you can program, and you have never heard the word "algorithm" before -- less than one day, most likely less than 1/2 hour.

The time it takes to understand and implement a particular algorithm -- 10 minutes to two weeks.

The time it takes to learn a new language at a basic level -- days to weeks.

The time it takes to learn something resembling a level of expertise or mastery with a language -- months and years.

---

The numbers you give are consistent with the statement you claim is "preposterous", so I'm not sure what your point is exactly. Explaining to someone who is clueful what the word "algorithm" means does in fact take ten minutes, as you state. Teaching someone to come up with their own algorithms does in fact take forever, as the bit you quoted states, and as you confirm with your last point. There is not in fact a contradiction here.

Quote:

---

Originally Posted by Thinias

Being good at something is as much about having confidence in it as it is about experience. If you walk into a room knowing you can solve whatever problem gets thrown at you, other people will pick up on it... even if you actually can't.

---

As practical interview advice, I would say that this is sound advice: you want to project confidence as it inspires confidence in you. But when we talk about it objectively, it is rubbish: if you actually can't, then you are not confident; you are over-confident, and you are not actually as good as you think you are. If you do not pull up your socks fast, you will end up like the fellow that EVOEx talked about in post #5.

Quote:

---

Originally Posted by Thinias

Programming isn't about languages or styles or syntax or experience. Programming is about solving problems - if you can solve a problem, you can program.

---

I can agree with the idea that programming is really about solving problems, but to call languages, styles and experience irrelevant sounds naive. Learning the syntax of a programming language is one thing, but one also needs to learn the associated idioms and conventions. This comes with experience in using it. A consistent failure to use appropriate idioms, and poor style, ultimately stifles problem solving in the given programming language; even if you manage to cope, you may adversely affect the problem solving efficiency of a maintainer of the code that you write.

The "language is irrelevant" argument here is indeed rubbish. How many questions are asked on the very forum that start out something like "I know how to solve this on paper but I can't get started on the code <or cannot make the code do it>"? I have seen folks in my career that could look at a piece of hardware (that they knew of course) that could state the exact voltage/logic level on any pin on any chip in the system at any given millisecond yet could not apply logic to troubleshooting that same machine and were baffled when they actually had to work on the device. Equally I have worked in IT shops where someone BSed their way into a programming job w/o knowing the language/system and were quickly found out and ran out on a rail.

Its equal parts love of the biz (both from a pure problem-solving standpoint and a general work-environment), knowing your problem domain (so you can solve the problems) and knowing your language (so you can properly express your solutions). The folks who say you can learn to program any language well in two weeks are either geniuses or idiots; my experience says the latter. Even making a conceptually small jump from C to C++ can yield C++ files that look like and are designed like C code (no objects, no proper use (if any) of the STL) and so on. Worse, if you work on a team with such a stunted knowledge-base the rest of the team will be up to speed and you will be playing catch-up, if you catch up at all.

Programming in and of itself isn't about experience but doing it for a living is.

Quote:

---

Originally Posted by tabstop

Teaching someone to come up with their own algorithms does in fact take forever, as the bit you quoted states, and as you confirm with your last point. There is not in fact a contradiction here.

---

Okay, but in that case the analogy would be to coming up with your own language, which will take even longer. If someone is talking about the time required to learn some syntax (a few weeks), that compares to the time required to learn an existing algorithm, not to invent new ones.

My point is the implementation in language takes longer, and is more real work, than working out the algorithm to implement. Also, a lot of "algorithmic" problem solving takes place with the language itself. For example, someone was showing me an algorithm to do permutations with recursive python "generators" last week. It's all of a half dozen lines, but you could not abstract it meaningfully from python. Ie, while there are no doubt all kinds of permutation algorithms around, that one is essentially python specific -- you could unfold it and do the same thing in BASIC maybe (not), but I'm not sure what the point of that would be. You could also describe it in terms completely abstracted from python and make it seem as if it is generic, but that is so much about theory that it really has no bearing at all on the practice.

IMO, all specifically OOP algorithms are like this -- they are about using very concrete elements of computer programming languages, they are not the product of abstract "problem solving" separate from the use and comprehension of the/a language.

Quote:

---

Originally Posted by MK27

That's preposterous. If you want to count your infancy and childhood as time spent learning problem solving, okay. But if you are trying to claim that you spend most of your time as a programmer doing problem solving sans coding, I'm kind of curious what kind of programming that amounts to.

---

Actually I have spent quite a lot of time doing problem solving. If I can't think of an original problem, I try IOI or USACO tasks.

Quote:

---

Originally Posted by MK27

The time it takes to get a basic grasp of "algorithms" as concept if you can program, and you have never heard the word "algorithm" before -- less than one day, most likely less than 1/2 hour.

---

In that time you can explain that an algorithm is something that takes input, processes it and gives output. Nothing more. For example how long would it take to thoroughly complete and understand all the chapters of CLRS? And that's only the tip of the iceberg. A very small tip of it.

Quote:

---

The time it takes to understand and implement a particular algorithm -- 10 minutes to two weeks.

---

That's assuming you KNOW how to implement it. But algorithms can be very complex - there are problems only a few programmers are able to solve. It's not like reading a novel. It's not like "I have 30% of it figured out. I will figure the rest out tomorrow." Problem solving is trying to tackle the problem in different ways. Sometimes you will spend hours without any breakthroughs. It's science. It's art.

Quote:

---

The time it takes to learn a new language at a basic level -- days to weeks.

The time it takes to learn something resembling a level of expertise or mastery with a language -- months and years.

---

There's only one language to master - the programming logic, or pseudocode, whatever you call it. The rest is details.

If I can choose between a book about a programming language or a book about algorithms, data structures et cetera, I choose the latter. That's why I've never bought a book about a programming language.

Quote:

---

Originally Posted by maxorator

There's only one language to master - the programming logic, or pseudocode, whatever you call it. The rest is details.

---

Totally and completely disagree with this, that was my point about python generators (nb, I don't use python personally) and OOP. Pseudocode is a pointless wet paper bag in that case, unless it looks exactly like OOP in a real language. In that case, your pseudo code is not generic -- it could not be used in C/C++, etc.

Which I guess there is the joke about python being pseudo code. However, I still think knowing some of the "details" about real syntax can save you way more time, and result in much better code, than anything you will get out of sitting around pseudocoding.

I'm also kind of guessing that 95-99% of what you do is in one language only and always has been, so this is your perspective. I'm gonna say C/C++ is a single language in this sense, because they use the same basic syntax and rules (with slight variation).

The fact that there are many complex algorithms in the world is interesting, but irrelevant. All you are saying there is that some things are harder than other things. You could spend your entire life just reading about algorithms and never programming at all. Likewise, you could spend your entire life programming and never bother to read about algorithms at all. So there is enough to do in both realms to occupy everyone forever. That does not make it worthwhile in the pursuit of some goal beyond just learning algorithms and churning out code.

I partially agree with max.

I think that on the subject of programming languages, syntax is the least relevant aspect. They do tend to be grouped into families, so it's fair to assume moving from one family of languages to another may be a bit of a hurdle. (It was a little hard for me to revisit Delphi just last year. The syntax was giving me trouble).

But I think the real hurdle, where the notion that the programming language matters in the context I think is being debated here, is programming paradigms. That's what can take years to master. And where a switch from one paradigm to another may involve a completely different process to solve the same problem.

EDIT: As for pseudo-code, I'd drop it as an example, Max. Pseudo-code does not necessarily -- neither it has to -- map to a syntax in any way. It simply describes a process. It has no functional use beyond its descriptive ability.

Quote:

---

Originally Posted by MK27

The fact that there are many complex algorithms in the world is interesting, but irrelevant. All you are saying there is that some things are harder than other things. You could spend your entire life just reading about algorithms and never programming at all. Likewise, you could spend your entire life programming and never bother to read about algorithms at all. So there is enough to do in both realms to occupy everyone forever. That does not make it worthwhile in the pursuit of some goal beyond just learning algorithms and churning out code.

---

You don't have to read that much about algorithms. You can program them. And by doing that you improve your chances of solving the next problem. And by a problem I mean one that needs a creative solution that is not just a copy-paste from an algorithm book. Algorithm books just give you a jump start. They show you how many different ways there are to solve a problem. It's inspiration. No matter how many algorithm books you read, you still have to use your own head if you face a real problem. This means it's not good to only read about them - the best way is to mostly solve problems and sometimes read if you find something that could improve your way of thinking.

Fair enough. I'm not going to press the point because that implies a polemic that I think is a little silly, or that I think studying algorithms is useless, which I don't. And polemics for it's own sake is just entertainment :p

However, "problem solving" is not going to help me learn how to program the for the linux kernel or the apache request cycle. That means studying a specific technology, which is more a language oriented task.

Quote:

---

Originally Posted by Mario F.

But I think the real hurdle, where the notion that the programming language matters in the context I think is being debated here, is programming paradigms. That's what can take years to master. And where a switch from one paradigm to another may involve a completely different process to solve the same problem.

---

And paradigms are essentially artifacts of languages, which is why I used the OOP example.

Quote:

---

Pseudo-code does not necessarily -- neither it has to -- map to a syntax in any way. It simply describes a process. It has no functional use beyond its descriptive ability.

---

I'd rather see examples/description in any real language rather than pseudo code, to be honest. I've done the Java "hello world" afternoon because of that. Maybe when I find a real machine with paper tape sliding back and forth and "TURING" stamped on the side I'll change my mind. Which is not to say that turing completeness is not an entertaining thing to contemplate, but please: when was the last time this contemplation meant anything to a piece of code you wrote?

Most of all, my motive for feeling this way is a conviction that using more than one language seriously, in earnest, regularly, provides a bigger perspective than not doing so. That implies you learn something from the language and the way it works. I learnt a lot about perl by learning C, and a lot about C++ from perl. I am not a platonist, so I don't really see the significance or value of contemplating an "ur-sprach", either wrt to human or artificial languages; to me it's better to focus on C/C++ or perl rather than on the possibility of this "one language to master - the programming logic". It's not a necessary concept at all, nothing is accomplished pursuing it, and reifying it probably even worse.

Quote:

---

Originally Posted by Mario F.

EDIT: As for pseudo-code, I'd drop it as an example, Max. Pseudo-code does not necessarily -- neither it has to -- map to a syntax in any way. It simply describes a process. It has no functional use beyond its descriptive ability.

---

Actually my point was that if you know how to describe a process, you're only a small step away from programming it. So basically: "mastering pseudocode" = learning how to describe processes = learning how to solve problems. It's a metaphor.

Quote:

---

Originally Posted by maxorator

Actually my point was that if you know how to describe a process, you're only a small step away from programming it. So basically: "mastering pseudocode" = learning how to describe processes = learning how to solve problems. It's a metaphor.

---

Ok, I can see your point. Taken.

Just one pet pevee though. Pseudo-code has been, at least for me, only useful after the fact; as a means to describe to others a found and tested solution. I never, that I remember, even once used pseudo-code during the analysis stage.

In retrospect, having worked integrated in teams for maybe 90% of my career, I could find that curious. Can it be that not even once I felt the need to describe to my team mates a possible solution to a problem, or them to me? The answer is yes, of course. But that has been done always through code. Pseudo-code couldn't help us, really. It would just get in the way. We would then have to map that to the programming language and test. And what if the solution is not ideal? Go back to pseudo-code?

Pseudo-code doesn't really help you reach a solution; it simply describes it, after the fact. It's a good publishing tool. The ability to solve the problem is tied to the programming language, your knowledge of it and how well you dominate the programming paradigm you propose solving the problem with.

Pseudo-code in programming is the equivalent of English in aeronautics. It is great to explain how planes fly, but you needed math to actually find why they fly.

Quote:

---

Originally Posted by Mario F.

Pseudo-code has been, at least for me, only useful after the fact; as a means to describe to others a found and tested solution. I never, that I remember, even once used pseudo-code during the analysis stage.

In retrospect, having worked integrated in teams for maybe 90% of my career, I could find that curious.

---

Pretty interesting, but makes sense. AND I'd wager that it's true for 90% of other programmers. Like I said:

Quote:

---

I'd rather see examples/description in any real language rather than pseudo code, to be honest. I've done the Java "hello world" afternoon because of that. Maybe when I find a real machine with paper tape sliding back and forth and "TURING" stamped on the side I'll change my mind.

I am not a platonist, so I don't really see the significance or value of contemplating an "ur-sprach", either wrt to human or artificial languages; to me it's better to focus on C/C++ or perl rather than on the possibility of this "one language to master - the programming logic". It's not a necessary concept at all, nothing is accomplished pursuing it, and reifying it probably even worse.

---

That's not to say there is no such thing as logic, just that you have it PERFECTLY incorporated right there in the/a real programming language. ABSTRACTING anything from that and trying to refer to the "universal logic of programming" in terms of some language that no one uses to program with seems misguided to me (that is, a heritage of Platonism, which infects many of our institutions at the highest level). Those real languages are the product of applied logic.* I'd also bet dollars to donuts that Anglo-American philosophy (which is very logic centric) has completely collapsed as a field since I was in university because all those new students would rather study programming in a post WWW world. Abstract pure logic is a dead horse of some sort. Probably a unicorn or Pegasus.

* so put on your pompous ass coat when you stray from that, please :p

Pseudocode is what's in your head before you translate it into a specific programming language. At least this is the way it works for me. I never think of a problem in the context of a specific language. But when I need to write it, I always use a real programming language.

Quote:

---

Originally Posted by maxorator

Pseudocode is what's in your head before you translate it into a specific programming language. At least this is the way it works for me. I never think of a problem in the context of a specific language. But when I need to write it, I always use a real programming language.

---

Again, I'm guessing that when you say "I always use a real programming language" you mean C/C++ 95% or more of the time. I'm not knocking that, I'm just suggesting something about the nature of the "pseudocode" in your head. This idea about "translation" sounds very artificial/false to me. That's like saying, I don't think in English, I think in ur-sprach, then I translate it into English when I talk. There is some truth to that, but it is not so clean cut. And in fact, it's mostly English.

I think if you had to work in a number of (high level) languages all the time, you might find you tend to approach (significant aspects of) a problem in terms of the language you are suppose to use at the time (eg: class or no class? generator or no generator? regexp or no regexp?). If it's always the same language, you won't notice this.

There are similarities and there are differences. The desire to reduce or eliminate the differences is misguided(/Platonic) -- you loose possibilities there. Hence, "reductionism". It does have a place, but it's limited. Like pseudocode.

I'd rather think in C/C++ (or perl, etc) than think in pseudocode.

Quote:

---

I never think of a problem in the context of a specific language.

---

This much I agree with. When it comes to figuring out the general solution or approach to a problem that is not a language specific issue. However at some point the design becomes implementation and at that point the programmer must figure out how to implement said solution or approach in the language of choice. So at some point the problem does become a language specific issue. It does not mean the problem can not be solved and thus the solution implemented in other languages but it does mean you, as the programmer, must figure out how to implement said algorithm in a specific language. Sometimes the approach does become language specific for language specific issues such as performance, memory management, etc,. etc. Sure the algorithm and solution is the same but the impl of it is prob very different from language to language.

So for me during design I would wholly agree you would never think of the problem in terms of language A or B. But during implementation there comes a point at which one must think of the problem in terms of language A or B in order to be effective. Personally pseudo-code has never helped me one bit. I find UML class diagrams much more informative and also prefer sequence diagrams over pseudo code.

But alas we digress from the topic. Back to the OP's original question. The general consensus here is that you can indeed become a programmer if you so desire. If you are young and about to enter your college years then go for it and study CS or EE. If you are older and not able to do this then you could do some online classes, create a personal portfolio of your best at-home projects to show what you can do, and then send out your resume to companies that fit the bill for you. Probably the biggest hurdle in programming yet also the biggest help is what you see here in this thread. You can't get two or more programmers in the same room to agree on everything nor agree on very many things. However it is my opinion that this kind of banter and going back and forth in a team atmosphere produces some very good software in the end provided there is leadership and guidance along the way. At some point compromises must be made and as the team begins to focus on the same goal whilst everyone puts forth their best efforts that is where magic happens. Software development is primarily about teamwork and being a team player.

I meddle with code off and on in my spare time and really enjoy it. Oftentimes I've thought about whether or not I could eventually get good enough to actually work as a coder, but to be honest I have absolutely no idea what programming jobs actually entail, as in what they expect you to know, how fast they expect you to work, what kind of paradigms you should have under your belt etc.

Part of my problem is that aside from reading the occasional book and getting the syntax down, I've pretty much learned how to construct programs through trial and error. As a result, I have absolutely no confidence that if I showed one of my programs to a professional programmer, he wouldn't look at it and laugh. Years ago I learned how to program with AMOS on the Amiga. The manual pretty much just went through the syntax and the commands one by one and yet I managed to piece together a pretty major application with a funky GUI that I programmed completely from scratch. All the algorithms in the program were the result of brute force thinking and I have no idea whether I was being really clever, or way off.

I'm just starting to read Steve McConnell's excellent "Code Complete" and that's giving me some more confidence in terms of knowing how things are done in the professional world...conventions, paradigms, style etc. It also gives you an insight into how development teams work. I know I'll never have time to go to college, I'm 37 and running a pretty time intensive business (which is why I got back into coding, to write some console based programs in C to help me with the employee scheduling and the books etc). And although I still think of myself as a complete newbie, I have just managed to get through all 27 of the excellent "Programming Paradigms" lectures on Stanford's YouTube channel, which made me realize that I have a deeper facility with C (and even Scheme!) than I ever thought I had. I'm pretty sure a sizable proportion of working programmers were self taught, so there's hope for me yet!