Learning Tips For Newbies to Veterans

Hi Kevin,

Thanks for the tips.

Here's is my ultimate Tip # 1:

Backup. backup backup.

.

You're going to learn a lot on TeamTreehouse, but many of the things you learn you may not use professional (for a job) right away.

The human memory being what it is, you'll forget and then there will come a day when you say:

"Hey wasn't there something on Treehouse about that --where did I put

that zip file I downloaded (and maybe added to)...?"

Treehouse may not be available for forever (and/or your subscription may run out).

Archive all it's content offline (when/while you still can).

---

That fact is if you spend a lot of time on a project,

where you not only learned a lot of things but create a number of interesting variations,

always remember to back things up to different media

(not just your hard drive that could go belly up as they usually do).

---

The comment thing you mentioned is important because

you may have to rely on those comments to try and figure out where your head was at

last time you edited the code

(or to add notes about how the instructor said this was supposed to work).

---

Be systematic about file naming for different code/packaging revisions.

It really doesn't matter what the "system" is you use as long as it has meaning for you and you can remember it many months (or even years) down the road.

Having to go through hundreds of gigabytes of source to find a a particular code snippet is not fun.

---Although file search tools at the O/S level have greatly improved,

sometimes you just can't remember the right

search term that will bring up the desired results.

---

The single most important thing you will learn as you become a better coder is to think logically.

This doesn't always mean to think in a way

that comes up with the most clever or efficient code, though.

Tip 2:

Do not spend a lot of time trying to re-invent the wheel.

Every time you decide to start a new coding/development project (or get assigned one at work),

always take time to research what is out there --what others trying to do

sorta the same thing has produced for code and used as a coding technique.

.

Make the assumption:

"I'm sure some else had has to this before - I just need to find out what went before and use that

as my starting point instead of opening an IDE or editor and just start spewing out code".

So all you need to do is find that person's repo online and fork it.

You can also try to find a blog post about a similar project and it may give you clues as to an approach to take.

Effectively working tip #2 can save untold hours of dead ends and unnecessary code debugging.

---

Tip #3:

At every stage in the projects development have some code that works.

.

I see it constantly on programmers forums --the uploading of code that not only doesn't work

but probably never worked.

It's a hopeless mess of snippets copied and pasted together.

Usually the "glue" code (the code that may have allowed one of these snippets to be working code)

has been edited out (or failed to be copied/pasted) because the coder/programmer didn't

feel it was "pertinant" to his end goal.

Ideally you start with some code (that is hopefully "semi-related" to the functionality you need)

then you start refactoring (slowly), testing the code revisions constantly

to make sure the code is doing something (working) as you work toward

getting the functionality you want.

---

If you work a particular code branch and no matter what you do you still can't get anything to work

then go back to the last code revision that did work (what might be called 'the trunk') and

figure out a new way to branch out the code to go in the direction you want.

This sound so simple and obvious to say, but again, I've seen so many people who post

on programmer's forums who become "task bound".

They feel their brilliant insights into what code (or code technique) should be used,

when they are told that many others have tried that same approach and all have failed.

Then a different approach is suggest and the comeback is:

"But I've already wrote all this code...and I totally understand it..and

I don't want to learn a new approach because it's just to hard/different".

.

Here's the bottom line --it's not working, so go back to what did work, and go in a different direction.

..or give up the project altogether if you can't debug your mind enough to adapt the code to move forward.

This is directly in line with what Kevin said:

"it's how you adjust and learn that sets you apart from other programmers."

They just never warn the newbies enough how painful that process can sometimes can be..