Most important concepts to learn for a new developer (Top 50)

[Trinity]

This seems to become a real interesting topic. :-)

And inspirational I think to read other peoples reflections on the topic.

And a philosophical question: It's sure possible to write programs without any clue of the internal architecture of a CPU. But will one ever become a good programmer without that knowledge?

I have reflected a lot over that question for a while - started after I began using FreeBASIC and joined this forum...
I think that that entirely depends on what you want to do and who is judging.
I mean , having attended this forum for a while I have realized that quite a lot of the forum members here are rather skilled , some more than others , and some know more about a certain niche of stuff than others do - at least it seem to be so.. And that is kind of the point that I am also trying to lead up to here. I mean , each have their own inclination , and we may have been lead to use FreeBASIC for different reasons , and some are so much more interested in one thing than the other. So does that make A a better programmer than B ? I think not necessarily, except of course if there is a job opening that needs to be filled.
I would how ever argue that to be a good programmer one have to have an interest in getting the most out of the programming language that one uses, which also means trying to explore it in a positive manner (I am too new to FreeBASIC to specify on that topic) , so that one at least from the angle that oneself have have a rather good knowledge of the language (again we do not all have the same angle I think).
Personally I do have clues of the internal architecture of a CPU but not much more. Not sure if it will ever be more than that , I'd like to but not sure that it ever will , but in the end of the day then me not hired by anyone to program then what matters to me is if I am satisfied myself :-)

[marcov]

Well, if that isn't the most important skill, debugging is. Learn several different ways to debug. Learn to use a variety of debugging tools such as debuggers, memory debuggers, profilers, call tracers, static analyzers (good tools aren't as important as your wits when debugging, but I love it when I can solve what should have been a real headscratcher in 60 seconds flat by using valgrind)

I second that.

[BasicCoder2]

...And beyond this point it becomes difficult to create a generally valid list of things to learn, for it depends on what kind of software you want to write. E.g. for programming CNC machines it is essential to know about the Bresenham Algo, while is's quite useless for a bookkeeping software.

Learning to program doesn't determine what you can program. Having programming skills doesn't enable you to program anything. Being able to write doesn't mean you can write about anything. A professor in a human language will not mean he/she can write a best selling novel just as many advanced programmers could never write a best selling computer game.

And a philosophical question: It's sure possible to write programs without any clue of the internal architecture of a CPU. But will one ever become a good programmer without that knowledge?

There are levels of understanding. The world is modular. If you know how the module behaves you can use it. Knowledge of the CPU and how it works is not required unless you are in the business of making them. Being able to make a cpu doesn't mean you will be a better programmer than someone else who may be more knowledgeable in other areas required to write said program. Someone with a knowledge of OpenGL without any understanding of how it works will produce better 3d stuff in a shorter time than I am doing with FreeBasic and its lower level graphic commands. I understand the working principles of a cpu to the extent I could build a simple one out of relays or transistors or integrated circuits but that doesn't help me with the 3d graphic's math.
.

[deltarho[1859]]

The world is modular. If you know how the module behaves you can use it. Knowledge of the CPU and how it works is not required unless you are in the business of making them.

That is a contradiction if ever I saw one.

I believe that knowledge of the CPU is neither a necessary nor a sufficient condition for being a good coder. It may help in being a better one but it does not follow.

I understand the working principles of a cpu to the extent I could build a simple one out of relays or transistors or integrated circuits but that doesn't help me with the 3d graphic's math.

It might if you could leverage the CPU cache to your advantage.

[BasicCoder2]

The world is modular. If you know how the module behaves you can use it. Knowledge of the CPU and how it works is not required unless you are in the business of making them.

That is a contradiction if ever I saw one.

How is it a contradiction? Knowing how something behaves is not the same as knowing how it works.

I believe that knowledge of the CPU is neither a necessary nor a sufficient condition for being a good coder. It may help in being a better one but it does not follow.

Which is what I wrote.
.

[deltarho[1859]]

Knowing how something behaves is not the same as knowing how it works.

I agree. I treated them as the same because you used them in the same paragraph. My mistake.
Having agreed to your first statement I cannot agree to your second statement because you used 'works' and I didn't use 'behave' or 'works'.

If you came back to me saying that I am being pedantic then you would have my agreement again. <smile>

[dodicat]

If you know the inner workings of a cpu then you will say that it is necessary to know this.

If you don't know the inner workings of a cpu then you might say that it is not necessary, and if you are young and ambitious you might feel a bit intimidated by those with the superior knowledge.

Maybe learning a bit of Intel assembler using cpu registers and mmx and sse and the like would be part way to add confidence and extra skill.
And this is an option if you use FreeBASIC.

[deltarho[1859]]

If you know the inner workings of a cpu then you will say that it is necessary to know this.

Well, whilst not being an expert I know more than a bit of asm, mmx and sse and still say that it is not necessary to "know the inner workings of a cpu." Having said that I have a long way to go to match the author of Optimizing subroutines in assembly language so, perhaps, I may change my mind if ever I did. <smile>

I agree with "would be part way to add confidence and extra skill" in the same vein as my "may help in being a better one". I have just removed a sock for quoting myself. So, I would say it would broaden one's knowledge - I wouldn't describe it as superior knowledge as that, to me, sounds elitist.

Having said that I know of a least one successful Windows' developer who would not recognise asm if it hit them in the face; although they ceased to be "young and ambitious" some time ago.

[lizard]

Arrays with more dimensions or types (UDTs) are a very important thing in programming and makes many tasks easier, shorter and more elegant. But for Newbies this concept seems to be difficult to understand. Here things become abstract. Many people who don't have real feeling for programming will not master this hurdle.

An related error message is "segmentation fault" which means in many cases the program tries to write or read to array fields that not exist.

[BasicCoder2]

I don't remember having any problem understanding or using TYPEs.
As for complete newbies to programming I suspect there are probably none here anyway.
The active forum posters appear to be old programmers 50+.
.

[coderJeff]

The active forum posters appear to be old programmers 50+.
.

LOL. Is 50+ a quantity of users, or your guess at average age in years? Both?

---
Tough to give priority to most import things to learn. So many ways to "program" things. In old days, only way to make things work was to know the hardware. Ultimately, giving instructions to a machine. Needed to know how the machine worked to give it the right instructions. Nowadays, with abstraction, frame works, and virtual machines, it's not the same.
---
I recently read something along the lines of the importance of smart data structures and dumb algorithms ... and I agree. But years ago, at the beginning, I don't think I would have understood, while learning binary, machine word sizes, modular programming, recursion, and other fundatmental programming concepts, etc.

[BasicCoder2]

Nowadays, with abstraction, frame works, and virtual machines, it's not the same.

There are however some fundamental programming concepts which are common I think to all languages including Assembler code.
Higher level languages (beyond a basic Assembler of machine code mnemonics) allow the layering of higher level abstractions but they are themselves built out of these more fundamental operations.
I like the way this introduction uses more than one language to demonstrate how things can be coded.
http://holowczak.com/programming-concep ... ogrammers/
Much like the educational value of the Rosetta code examples.
http://rosettacode.org/wiki/Rosetta_Code
.

[speedfixer]

Perhaps a little off-topic.
I think the 50+ yo posters may be remembering back to the days when learning to program was the goal, and BASIC allowed them to see results quickly and inexpensively.

You did NOT have to pay anyting extra: most of the small systems had a BASIC that either came with or was easily acquired with the system.
You did not have to spend long hours setting up the environment for it.
You did not have to wait to see results of your success or failures. (VERY important - this feedback loop.)

Others were pushing the envelope:
All the programs one could poke into memory, all the OS and system stuff you could dump easily and learn from.
No hard drive to damage with your assembler experiments.
Real programming concepts could be learned relatively painlessly. (c or c++ from scratch - who HASN'T had real pain from learning?)

Then the teachers had to go and say: learning BASIC damages the new programmer.

Tell that to all the new wave pioneers that bagan with BASIC that rewrote language and internet history.

Now, there is an expectation that someone will grasp OOP, pionters, code-reuse, indirection - all in the first programming class. I helped two wives and a son through computer degrees. This expectation just isn't possible for the average person with an average desire to learn the cool profession - programming. (Maybe *I* should have the Comp Sci degree. Naw: would have been too much fighting with all the teachers who said: "Never do this: ...")

But if one really has drive and desire - he accepts the pain of learning the way the schools teach it: c or c++ and an all-at-once approach that drives many away.

ALL of the 'modern' concepts can be taught with a modern BASIC - without the pain of all the indirection required to get meaningful output from a c language. (Unless you use one of the big IDEs that don't even let you see what is behind the curtain. You learn how to put together puzzle pieces, not write good code.)

And - joy to us oldtimers - along comes the new wave of BASIC's that lets us do very close to all that stuff we stayed away from in c, etc. when we were younger. AND learn/use all the newer concepts that took a little time to get comfortable with.

::end of my opinion

- - -

My take on important concepts:

1 - what are variables - advanced: UDTs, inheritance, OOP
2 - program flow (SUBs, GOTO, functions) - advanced: threads
3 - building block concepts, program structuring - advanced: design for reusable code
4 - pointers - advanced: indirection (of so many flavors)

Could be more sections; could be other organization of concepts.

Learn the basics, get some visible results and gratification from your efforts, then go to the advanced.

The worst that happens in the structured learning environments is the failure to recognize that not everyone learns the same concepts from the same method of teaching. Second: not recognizing that some concepts just have to be learned before others - and then not being a true teacher and helping the student in trouble get past his problems.



David

[lizard]

Now we are writing about what new developers should learn (experienced ones are knowing this since decades) it should be mentioned that is very useful to make backups of the previous work on usb-stick here and there. Nothing is more annoying as if all the work is destroyed by one button click or a harddisk crash.

I do it this way: saving the code i am working on every 20-60 min with numbers behind, like test-01.bas, test-02.bas and so on. Sometimes you see you have moved in wrong direction. Then you may want to go some steps back and start again from an earlier point,

[xlucas]

Uhm.... you can learn many things as you get skilled in programming, but when you say "concepts", it sounds like mostly theory, even though it doesn't have to. If you learn on your own, you come up with your own concepts instead. I believe the important thing is that you learn the skills, not the concepts, although standard concepts help when developing in a team, but that comes later.

I reckon the skills that are fundamental for a programmer are the ability to recognise an error both at runtime and while reading the code and this feeling of "visualisation of the program's virtual gears as they move" that you get when you're using a program, you know. Very tiny things we tend to forget about were essential when we learnt them and seem obvious now. Like realising there are 11 numbers from 0 to 10, not 10, so if you print a 10 character long string at position 10, the last character will be at position 19, not 10. It's simple logic. I think this kind of understanding has to become automatic and is the most important type of concept one has to learn.

About OOP, of course, others may think diferently, but I personally have never used it and I've been able to do everything I want. I also don't abuse multi-threading. It really is not as essential as it may seem. Why let the CPU manage my time sharing when I can do it myself? Sometime it's good, but not always.

About debugging, yeah, I remember QuickBasic's debugger was very useful to me. Watching a variable and placing stops, specially. When I moved to other programming languages, I stopped using debuggers and I had become good enough at realising where I had made a mistake so that wasn't a terrible switch to me, but at the beginning, I would have abandoned many projects if I hadn't had that, I think.