Using the grid in hammer is an easy way to stay organized. It is a good idea to keep all world geometry on the larger grid lines (32, 64, 128). Using the grid lines will also help a lot when you need to texture the brushes.
Notice in the image how all of the world geometry is either on the 32 or 64 lines.

Adjusting the grid

• In the top left corner there are 2 buttons that have a small grid icon with a plus or a minus.
  
• Pressing these will either divide the current grid in half or make it twice as large.
  
• To find out what the current grid size is look at the bottom right corner where it says "Snap on Grid: # "

Nodraw should be the most used texture in all of your maps. Using nodraw will make your map run faster because the computer will not draw it. Place the nodraw texture on any faces that the player cannot see.
All of the nodraw faces you see in the image above have a usually func_detail covering them however the func_details were are hidden in the picture.

Never never ever draw a box around the map. It will create hundreds or even thousands of unnecessary visleafs (which is very very bad). Drawing a box around the map will cause the map to lag a lot. Instead use the pointfile to find the leak and fix it. it is under the "map" menu next to "file". To find the leak click on the "Load Pointfile" button. Hammer will display a prompt, click yes. You will now notice a red line in the viewports. This indicates the path of the leak. Then just make a brush to seal the map. Remember, only world geometry can close the map, func_details or func_brushes will not work.

Func_details are entities in hammer that do not affect visibility. They are not part of the main structure of the map and are sometimes used for decoration. The use of func_details reduces the number of unnessecary visleafs. This will make your maps compile and play faster.

Using Func_Details
To use func_details find a brush that does not affect your visibility. Then press Ctrl T to bind it to a func_detail. Func_details are commonly the brushes around fizzlers, under buttons, and static panels.
All of the highlighted objects in the image are func_details.

For this example we will use 2 buttons firing an output to open a door.

OR GATES:
Or gates are the simpilest gates to make because it does not require any extra effort. For this example we will use 2 buttons firing an output to open a door. An OR Gate will make either the first OR the second button open the door when it is pressed. When you put 2 inputs into a door from 2 buttons for example, hammer automatically uses an OR Gate from the 2 inputs into the door. Then when the first button or the second button is pushed the door will open.

AND GATES:
For this example we will use 2 buttons firing an output to open a door. An AND Gate will have both the first AND the second button needed to be pressed to open the door. To create an AND Gate we use an entity in hammer called math_counter. To use it simply have the buttons fire the output to the math counter. You also wanto to change the "via this input" to add*, and the parameter to 1.Then in the class info for the math_counter set the "Maximum Legal Value" to the number of buttons that all need to be activated to open the door (In this case it is 2). Finally in the output tab of the math_counter you want to create an output "OnHitMax, (doorname), open,". You also want to have the door close when you don't have all of the buttons pushed so you would create another output "OnChangedFromMax, (doorname), close". Compile the map and test if it works.

NOT GATES
NOT Gates are relatively simple to make. They are easy because you don not need to add any extra entities. First we need to know what a not gate (or inverter) is and how it would be used in Portal. A NOT Gate is used to invert the output. For example if you wanted a door to be open when a button was NOT pressed. In this case we would go to the Outputs tab on the button and change "Onpressed" to "OnUnPressed". This also works for all of the other input devices such as laser catchers and triggers.

*If you had a nand (A not/and) gate then you would use subtract.

Logic_Relays are a great way to keep organized. The purpose of logic_relays are to group outputs together. Logic_relays are used in the middle of an normal output. So instead of directly firing the output to the door for example, you would trigger a logic_relay that would have an output to open the door. There are 5 outputs inputs for a logic_relay, trigger, fire user 1, fire user 2... After you make an input. Place the desired output in the logic_relay. That's it you're done.

There are a lot of people with only basic knowledge of hammer and probably could not create a whole chamber from scratch. However they would like to add something to their level that they can not add in PTI whether it is retexturing a wall or adding a radio. Most people think it is easiest to decompile the PTI map into hammer and then make any changes they need to it. My opinion on this is that you should not do this. If you have ever decompiled a PTI map you will notice that PTI uses a func_instance for everything in the chamber.
If you you were to open up one of these func_instances you would see lots and lots of logic_relays and some other entities mixed in as well. What this means is PTI is extremely inefficient. instead of an output going from a button to a door you would have 2 or 3 relays in the middle of them. Adding logic_relays is a great way to stay organized are not a problem, unless you have 2 or 3 of them between every single entity in your map. This is what PTI does. This is one of the reasons why PTI maps are anywhere from 3 or 8 Mega-Bytes. The average optimized hammer map should be only 2 or 3. The next way a decompiled map is inefficient is the textures. All textures that the player can not see should be nodraw. In a PTI map almost all of the brushes are completely textured and you will rarely see nodraw.

So in conclusion in is inefficient to convert a map from PTI to hammer. It is best to properly use hammer and build the map from scratch if you are going to put in the effort to change something in your map.

If you are new to hammer you can comment on this guide and I will try my best to help you.

Tutorial Recommendations:

• Official Valve written tutorials: https://developer.valvesoftware.com/wiki/SDK_Docs
  
• TopHattWaffle video tutorials: http://www.tophattwaffle.com/tutorials/

It is important to get into good saving habits. Saving should be fast and easy so there is no reason why you should not. Simply press Ctrl S whenever you are in hammer to save. I usually save everytime I finish a collection of entities or whenever I compile.