Evaluating different kinds of code in a programmer's portfolio

Question

I'm soon going to look for a new job and is trying to put together a portfolio. I have a hard time deciding which of my projects that I should include. I've decided to categorize different kinds of projects and then get some feedback from the community as to what kind of code should be part of a portfolio.

Type A: These projects are written in a group with a tight deadline. Due to the iterating nature of the project and involvement of many people, at least one of the following three suffers; design, documentation or implementation. The goal wasn't always (perfectly) set when the project started, much was designed as the team went along. If something wasn't working smoothly, it was changed.

• Good: Almost all of these projects are games, which is good since I want to get into the games industry. It also shows that I can function in a team and adapt quickly to the designers tweaking the game idea. But most importantly, it shows that I can deliver a working product and the end of the deadline including all fundamental ideas.
• Bad: As stated above, the code usually suffers from the time pressure and changing project goals. And since it was written in a group, there is no way to tell what I wrote and what somebody else wrote.

Type B: These are small projects and written solely by myself, with no time pressure or bumps along the road of any kind. The project goal was clearly defined and set in stone before it was started. The code itself is very good written and documented.

• Good: These projects shows what a great programmer I am. My attention to detail, abstract thinking and thorough design documentation.
• Bad: I personally think that everyone can show the qualities mentioned above given no restrictions regarding time and effort spent on the project. So this only shows what coder I am under perfect conditions, something you rarely see in the industry.

Type C: These are my involvements in open source projects. Submitted patches and fixed bugs.

• Good: These projects best shows my ability to grasp a codebase that's both mature, established and to me foreign. And like B, I can spend enough time to come up with a really great solution to a problem. And like A, it shows I can function when coding with others. Also, due to the nature of open source projects, the bugs and changes are very clearly documented, so its not hard to find and point out the parts I've written.
• Bad: Since I've only written parts, I can pick the parts I'm good at, skipping the rest. Although the quality is probably better, it doest show that much versatility compared to B.

Good answers include one or more of the following:

• A fourth category
• Which category best suits a programmers portfolio
• How to display the code I've written in case of type A and C
• More good and bad things about any of the types

Also note that I've read other questions here on SO regarding the portfolio's importance compared to a cover letter, resume, recommendations and so on. The question isn't about how much time or emphasis I should put on the portfolio, rather on what's going to be in it and how it is to be presented.

Answer 1

Whatever else you do, when you write up your portfolio, try to avoid needlessly emphasising things.

Answer 2

There is no need to show something even you know is 'not perfect' and explaining what the conditions were (tight deadline, etc). The decision of hiring you is not based on discussing why something is better or worse, just show the parts of work you're happy with, that's PR.

There is no need to give too much details to the ones who hire you, just tell them the best parts, the ones you listed in 'good'. The 'bad' you can tell on a cigarette talk to other programmer folks.

Categories? For me: show 'commercial' and 'non-commercial', I think that's sufficient for the client/recruiter. They want your work to make them money. Convince them it can.

Answer 3

I'm revisiting my company website and have decided to list the following:

• Big Projects They cost a lot in either time, money or resources. These project are all about team work and often overcoming non-technical problems. They are usually often not complex from a technical perspective.

• Complex Projects. Difficult from a technical perspective. The kind of project where you need to hit the high notes.

• Curiosity Projects. Code that I've written for my own amusement or as a self-learning aid.

• Open Source Projects. Contributions to the greater good.

Answer 4

Does anybody still look at code these days? Maybe show not source code but some projects online and point out which parts of it you have implemented?

Your source code, good or bad, a new place will likely require you to adopt their source code style policy.

Answer 5

I would present type C projects (open source), and name type A projects, just to state that you were working on complex things with a tight schedule not only coding for fun opensource.

If you can't say specifically what you did in those, just say what was your role at that time.

Answer 6

Why don't you rewrite one of the games to show off your good coding skills, and just include that among your personal projects? Don't include any code that has more than a few WTFs per minute, no matter what else it demonstrates.