Best Practices

I had to write this out for work, but I felt it would probably be useful for others. While this was written mainly in reference to .NET development, most of these points translate to development in general.

1. Reuse code as best as you can. If you know there is something that was used to fix a problem in another project make it generic and common. We want as few lines of code in the code base as is neccesary to get the job done.
2. ReSharper is probably one of your best friends when developing code in .NET (Resharper is available here)
3. Code Repositories should not be considered optional. Check in early, check in often.
4. Continuous Integration should be your religion, and if your code breaks the build, FIX IT BEFORE YOU LEAVE. Other people like to get work done too.
5. TDD is mandatory - write tests *before* you develop functionality
• Resharper is excellent for this and helps tremendously
• If you have to temporarily disable a test use the Ignore attribute with a reason. This makes it easier to track, and allows us to see a print out on CI so we can make fun of you for not fixing the test later.
• TDD will be your friend if you ever have to refactor the code. You will thank yourself later. (And you will refactor the code. OVER AND OVER AND OVER)
6. When Resharper makes a suggestion for code clarity as a general rule follow the suggestion. The one exception to this is when a LINQ statement makes the code less legible.
7. Cyclomatic complexity is bad. Keep nested loops and if statements to a minumum unless ABSOLUTELY neccesary.
8. Optimal method length is 5 - 10 lines (This will also make it much easier to wrap tests around.)
9. Use guard statements to simplify methods.
10. SOLID is not optional (Definition is below)
• Single Responsibility - object should have only a single responsibility
• Open Closed Principle - classes should be open for extension, closed for modification
• Liskov Substitution Principle - Methods that use a base class should also be able to use classes derived from that base class
• Interface Segregation Principle - many client specific interfaces are better than one general purpose interface (i.e. don't use huge-ass interfaces)
• Dependency Inversion Principle - Depend on Abstractions, not on Absolutes i.e. Use a base class in the parameter definition for a method rather than a derived class. (see Dependency Injection which is a great tool for TDD)
11. DRY - Don't Repeat Yourself (EVER!)
12. Mocking is fun. Especially the coding kind for tests. ( I personally like MOQ)
13. usewhitespacetoenhancereadability
14. Do not use regions. PERIOD. If you need to hide something, your method is too long.
15. If you have to write comments on every other line, your code probably isn't very readable.
• use descriptive variable names
• use smaller private methods with descriptive names.
• EXCEPTION: jokes in the code are ok.
• use comments to explain "why" something is done that way, the code should explain "what" is being done.

For further reading:

* CLR via C# revision 3 (Jeffrey Richter)

* Framework Design Guidelines: Conventions, Idioms, and Patterns for Reusable .NET Libraries (Krzysztof Cwalina and Brad Abrams)

* Test-Driven Development in Microsoft .NET (James W. Newkirk and Alexei A. Vorontsov)

* Working Effectively with Legacy Code (Michael Feathers)

* Design Patterns: Elements of Reusable Object-Oriented Software (Erich Gamma, Richard Helm, Ralph Johnson, John M. Vlissides)

Things NOT to do during the hiring process

Yesterday I went on a twitter rant (You can follow me on Twitter here) about ways to piss off an interviewer and be sure that you are not invited back. I felt the need to summarize and hopefully help out others in the future.  For clarification, I am a Software Engineer, so most of this advice will be tailored for Software Engineers.

Resume


1. Don't have a resume longer than two pages
Even if you have done something as cool as writing the software that makes the Kinect work, moved Facebook operate on OpenStack, wrote part of EC2, or improved search times on Google by 1000%, I don't need to know every step that you took along the way. Give a brief two or three line synopsis of the project with some of the main technologies you used and let me ask questions about it.

How to lose double points: Explaining that you used the basics of an API or Framework. For example: I used List<> in C# to create a collection, or used GET statuses/show/:id in the twitter API to get the single status by Id.

2. Don't have anything on you resume you aren't willing to talk about
Anything on your resume is fair game. When you say I don't want to talk about that, or I don't remember much about that project, and it happened within the last couple of years I am going to immediately come to two conclusions:

1. You are probably lying about working with the technology on that project and just put it on there to try and impress me. 
2. You are desperate for work and put just about any buzzword on your resume that you could come up with to try and get your foot in the door

3. Don't Copy and Paste
Resumes are fairly tedious to read as it is. When you copy and paste the same line into multiple jobs it screams "I'm trying to fluff up my resume and make myself look way more awesome than I probably am"

In the Technical Screen

1. Don't try and make up an answer
If I ask you a question, chances are I know the answer, and I probably know it very well. That means if it sounds like you are starting to make something up I will ask a follow up. If I'm feeling generous I will let you go just far enough to know that you have no clue what you are talking about before moving to a different subject.

No one knows everything. Some questions that I ask are asked simply to see if a person will willingly say "I don't know the answer to that question", and will either:

1. Ask more about it. 
2. Write down the question with the intent of looking it up later.

2. Answer the question that I am asking
If you are unclear what I am asking, ask for clarification. Don't try and and change the answer towards something you know. I asked the question about a specific technology for a reason. \

3. "Like", "so" and "um" should be avoided at all costs
If you use these words so often that an interviewer can't concentrate on what the rest of your answer is, chances are you are not going to get called back.

4. Don't argue with me.
You will disagree with an interviewer from time to time, and if you decide that you won't be able to work with that person because of a philosophical difference, then by all means don't take the job. I may love Python you may love Ruby. If you want the job don't tell my Python sucks.

Questions to ask Interviewer


1. Don't ask me when you can start
You come off as arrogant, not self assured.

2. Don't ask if there is any reason you wont get this job
That question alone in an interview is the reason why you won't get the job. It makes me uncomfortable and quite frankly there is always a reason to not give a person that job.

3. Don't have no questions
It shows me you've done no research, and that you haven't gleaned any information about the way the company works from our conversation. It shows a lack of interest in the position.

Things you should know

• Know what Object Oriented Programming is.
• Learn Design Patterns. Be able to explain at least one in detail and it better not be a damn singleton.
• Make sure you know at least one scripting language/Dynamic Language (Perl, Python, Lisp, Ruby, JavaScript, PowerShell)
• Make sure you know at least one statically typed language (C++, C#, Java, Objective-C)
• Be able to speak about an interesting problem you solved in detail