Best tips for beginning programmers?

Question

I'm just starting out learning to program. After tinkering with a couple of other languages I've settled on learning Python as my first programming language. I've learnt a couple of things the hard way:

• It's better to do a little programming every day than a lot one day and then none for ages
• Use an MP3 player to block out distractions
• Drink lots of liquid to help keep your brain active

What other useful little tips like this have people learnt the hard way that they'd like to pass on?

Duplicate

http://stackoverflow.com/questions/393946/what-would-be-the-best-programming-guideline-tip

Answer 1

• Learn the environment (IDE) well.
• Keep a couple books, few sheets and a pencil handy along with a fast internet connection.
• Be comfortable when you write anything.

And I have always found it very helpful to reinvent the wheel -- writing standard library routines by myself and comparing them with standard implementations.

Answer 2

It really helps to share some sample code with a more experienced programmer and ask for a critique.

Answer 3

As Warren Buffet once said, "Read, read, read".

http://www.joshwhitford.com/2008/03/01/postcard-from-warren-buffett/

Answer 4

Some tips:

• Interact with other programmers
• Learn about the theory behind what you are doing
• Write tests for little things to make sure you understand correctly how they work
• Always be ready to learn new stuff
• Don't want too much at the same time, start small.
• Learn an IDE, Learn your tools
• Watch screencasts
• Listen to podcasts
• Take enough rest
• Have enough time off of programming
• Get into usability early, to have a better understanding how users think
• Buy books and read them! One at the time, buy the next one when you've read the old one.
• Read source code from opensource projects you like, start small.

Answer 5

• Google, Google, Google!
• Find good tutorials online. When going through them, NEVER copy and paste code. You learn nothing that way. After you get the code working like in the examples, mess with it to see what things break, what things change, etc.
• Write a small program that you will find useful. It's good incentive to stay on task and will help you learn alot about real-world programming in the process.

Answer 6

Find a great mentor. On my second Coop from school, I learned most of my good programming habits because of my mentor.

Answer 7

• Figure out how to have fun with whatever you are doing.
• Don't work too hard--Work to live, don't live to work.
• You will make lots and lots of mistakes. Its ok.
• Never stop learning
• Don't get so comfortable in any one technology, process, or methodology that you can't adapt.

Answer 8

Pick a source control system and learn to make it a part of your programming process, right from the very start. I know far too many people that never "got into" source control and now have many poor habits that are basically a result of not using it.

Trust me, some day you'll be very thankful that you did.

Answer 9

• blog about what you have learned

Answer 10

Learn the fundamentals. Take an intro to CS class.

Answer 11

Never stop learning.

Enjoy life.

Read blogs.

Browse through Stack Overflow questions and answers...

I guess most of these tips apply to both beginners and experienced programmers. :)

Answer 12

• learn to accept being wrong, everyone is at some point or another
• write code
• should I learn multiple languages? YES, it's always better to have more tools in your toolbox.
• Don't become too dependent on your IDE, you should learn it well but there is a chance you will be hired by a business using other tools.
• save your code snippets, you can look back upon them, and improve upon them.
• take breaks, it's good on the eyes
• delve into each project optimistically, thinking it is within your capabilities before giving up on it.
• READ - keep up to date on the latest in software
• And last but definitely not least, don't be afraid to ask questions.

Answer 13

Like many of us, if programming is both your hobby and your job, make sure you balance your life and fit other important activities in.

From a goals perspective, I would say you should ask yourself what do you want to do with programming as a career? Don't say video games, that industry sucks for most programmers ;)

You could spend your whole life learning every language, platform, and quirk. I advise to not go too crazy, and realize learning new programming skills is usually part of the job description, and you will learn what you need to that way. In other words, it is good to be well rounded, but to achieve your goals: focus.

Answer 14

practice, practice, practice ... programming is like any other craftsmanship and wisdom comes with time and practice. think about some small projects for yourself (i.e.: your own text-editor, your own mp3 playing software, etc.) to develop and just do it. when you run into obstacles you cannot overcome (and you will) ask people in forums or other people you know that are programming and you will find a solution.

read the pragmatic programmer it will give you good advices and will map out way for you to become a better programmer.

question everything and think about better solutions - never accept anything said or written from no one - don't mind how accepted or well respected the one is (to err is human). if you think about a specific problem (even if it is solved) you will understand it's nature and you can learn from it. (learning is everything and good programmers are good learners).

Answer 15

Some things I learned the hard way:

Comment your code any time you write something that isn't super obvious so that when you come back to it in the future you will be able to figure out what you were doing.

Don't be afraid to write long variable and function names if it will improve the readability of your code.

Don't try to accomplish too much on one line of code. It makes the line more difficult to read, and makes debugging more difficult when it doesn't work.

Answer 16

I'm a beginner myself, the thing that shocks me the most is, I never really understood how big and in depth a discipline computer science is. As you get more and more into it you realize how important the basics really are. Other than that the hardest part for myself has been getting out of tutorial land, and writing your own code. Project Euler has been very helpful for me, writing your own answer to a problem is in my mind what programming really is. The language is just part of your tool box. Anyway, the best advice I've seen in this thread so far is, take a break. The key to life is balance.

Good Luck!

Answer 17

You are going to make more mistakes than you did learning to walk. They will be stupid, trivial, obvious mistakes and you will feel like you're way out of your depth.

After a while, the mistakes you make will become more complex. You'll find yourself stepping through code that you wrote only weeks ago and you will be disgusted at yourself. These mistakes will be more difficult to fix.

Fixing them will make you better.

Answer 18

Don't expect it to be easy.

Answer 19

Ask questions.

Never be afraid of asking more experienced programmers for help. Mostly we all love what we do, and we love to feel like an expert; there is nothing so satisfying as explaining a tricky concept to someone and seeing the scales fall from their eyes.

So ask questions of your peers and colleagues. Obviously, you should think about the problem / issue for yourself first and see what you can find out, but always remember that the chances are (in a work environment) that there is an expert sitting less than 20 feet away [c.f. the internet, 20ms away!].

Answer 20

I'd second the environment point though I'd call a few other things in as the environment, besides the IDE:

1. Version Control -> Sourcesafe, Subversion,. perforce, git, or whatever use something to backup versions of your code and keep track of where it is going.
2. Development methodologies -> Waterfall and agile are but two of many different approaches to software development which is mostly a formalized way to program in my mind.
3. Deployment machines -> Are you writing web applications, windows applications, console applications, Facebook or iPhone apps or something else? Is there a production machine and development machine or is it all done on the same box?
4. Bug tracking -> How are things found that need to be fixed and what schedule this needs to be done in?
5. Project management -> Which features/enhancements go in and when?
6. Testing -> Unit tests and integration tests.
7. Understand what hardware parts matter a great deal to what you are doing. Another way to put this is to think about what parts of the computer do you consider required for a development machine: Quad-core CPU, high-end graphics card, high-speed network throughput, dual monitor support, wireless network connectivity, RAM, hard drive speed, hard drive size, hard drive type(SSD or not)

Those are just some of the other things that go in to what makes for better programming. This may take some time to fully get into the swing of things but they are useful.

Answer 21

People will tell you not to reinvent the wheel. Ignore them. You will never understand how wheels are made until you build a few.

Answer 22

you don't need a computer to program.

one my favorite college programing experiences was writing my lisp homework on paper at a coffee shop. Not having a computer forces you to be the compiler/interpreter and really think through what your code is doing. Without the immediate feedback, you avoid a common beginner programmer mistake of getting stuck in a edit-compile loop trying to tweak parameters at random until you get something that works, without knowing why it works.

Answer 23

Find somebody who you're gonna bug with questions when you get really stuck :) (this is not a joke)

Books often copy from one another, but having a human explain the problem with lots of "really stupid simple questions" often works (hell, this site was based upon that idea).

Answer 24

More a big tip, but hope it'll help:

Nothing motivates like necessity. I never feel like I've really learned a programming language/environment/paradigm until I've build something 'real' with it.

Pick a project, or make one up. Make sure it's fairly big in scope, and ideally something that you can keep expanding. Also ideally make it something you'd like to use, or at least can see how people would want to use it. It doesn't have to be unique - maybe a photo gallery, or a social networking site, or something.

Figure out how to build it in your language using any and all available means (Google, books, SO, friends/peers).

Answer 25

I think the most important thing is to find a particular task that you want to accomplish and start writing a program to do that for you. If you just follow tutorials and such you will quickly loose interest and motivation (at least I do). If, however, you have something that you need to accomplish, you will find learning how to do it much more interesting and rewarding as you will enjoy your progress and results on every step. You will think of new features that would make your program better and at the same time you'll learn a lot by getting all the parts done.

Some things that I have found to be interesting perl projects for me have been:

• writing various linux scripts to do stuff - automate stuff, parse web pages, etc
• various small web pages - online gallery, temporary file/pic upload page, etc. I even wrote a small/basic personals site at one point just to play around with php/mysql at the time.

From then on you can get the help on the web (google), at various forums (here), IRC chat rooms (freenode?), etc.

Answer 26

Write big projects!

I don't know why most of my friends that actually program where so afraid to do big programs at the beginning, i did (quite horrible) very big stuff, dedicated tons of hours to do a couple of games(multi player, with animation and a lot of detail) when i was first learning Java 5 years ago. The game was fun, but the server would die after 10-15 users online. I learned so much from the experience that now I'm better than most of my friends because they are still afraid of big challenges.

They are still afraid of using threads, and they cannot undertand them outside of the trivial examples they did in school. They dont have any idea what a macro is and why would anyone be interested in learning LISP(when they can do EVERYTHING in VB or asp). They refuse to write their own widgets or do a user interface without the help of an IDE and most of all they dont see any need in source/bug control, because everything they do is quite small.

So for me, in my case, in my experience, thats the best advice i can give, really give your 101% to one huge project by yourself... its going to suck, but you will learn more than reading a pile of books, following all the tutorials or participating in any open source project. (maybe a mentor can teach more... but its different, you should try to do both)

After you've done that, it will make sence to read the pile of book, follow the tutorials and participate in open source stuff!

Answer 27

Try to learn to debug without having to actually compile the code. It's a good skill to have and plus you learn the language really well in the process. Speaking of debugging, learn to use a debugger. Print statements are easy and all, but some things you just can't debug without stepping through to see what your code's actually doing. And lastly, I'm assuming you're still in school. Take a big project class, and take as many as you can (NOT AT THE SAME TIME), they are probably the most useful actual programming experience you will gain academically.

Answer 28

• Read Pragmatic Programmers
• Actually write code
• Think/Design before you code
• Enjoy programming
• And learn a few language with different paradigms, i.e. java, haskell, scripting, etc.

Answer 29

Somethingt hat others haven't pointed out yet: RTFM

So often you'll get stuck and don't know what to do. But every language usually has an authoritative book/documentation that will have the answer. You just have to use a little effort and look for it.

Answer 30

RE: Drink lots of liquid to help keep your brain active

Don't drink too much liquid, or you'll end up running to the toilet non-stop. I'm afraid no MP3 player in the world can block out that distraction. ;)

• Learn by watching others - I always learn a lot by peeking at what others do, and how they do it.
• Write yourself, don't copy/paste.
• Build larger projects from smaller projects - don't start your programming career by trying to re-write Windows.

Answer 31

One of the best tips which I learned is that there is NO SUBSTITUTE for long and descriptive variable-names.

When I first started programming in BASIC we were restricted to single-letter or letter-plus-one-digit variables. So we had to make do with variable names like A, A1, A$, A1$, A(), A1(), each of which is a separate variable. The first two are numeric, the second two are text strings and the last two are functions.

Try going back to maintain a program using that sort of nomenclature six months later. It was, and is, probably faster to do a complete re-write than to even attempt maintaining code written like that.

Several years later, I started programming in COBOL which is a verbose language at the other end of the scale. It had code like "ADD INVOICE-TOTAL TO MONTHLY-PURCHASES GIVING STATEMENT-TOTAL.". What a joy to behold six months later. I knew exactly what the variables represented, and it was all self-commenting.

I have since moved to other languages, including Java and C. But I have always tried to carry along the use of long and descriptive variable names which I learned in COBOL, even if (as in C) the language itself doesn't care whether you use 'a1' or 'invoice_total'.

Of course, you may say that a long-winded variable-name gets in the way of your being in the Zone. That's what text editors are for. Use the 'a1' if you like temporarily, just rename it to 'invoice-total' later with 'find and replace'.

Personally speaking, I still reckon that using long descriptive variable names from the very start helps in visualising the logic better.