You can read about the purpose of this list and how to use it here.
Also, the list of resources is here.

1. general implementation
2. concepts
   1. harvested framework
      watch out so you don't fall into the trap of building frameworks up front. It's generally better to let them show themselves in your code and then you go from there.
   2. YAGNI
      So it's important to be careful and not think "You Aren't Going to Need It" (YAGNI) too often when it comes to operational mechanisms. Using YAGNI often will cost too much when it comes to adding the mechanism if (or rather when) you will need it. Remember, the idea with YAGNI is that the cost of adding something is pretty much the same now and later, in which case you can always wait until you really need it. When the cost is low now and high later, and there's a good chance you will need it, you should make a different decision.
      going for a Query Object, especially a domain-specific one, or the Specification pattern is to start by going too far, too quickly, don't you think? Let's go for the simplest possible and only consider two of all possible criteria for now
      The third solution could be to create an interface called ICustomer (or something similar, or let Customer be an interface) and then create a stub implementation of the interface. Again, that feels like overkill right now, and what would the purpose be when moving forward? To be able to swap ICustomer implementations? Is that really something I expect? No, I don't, so until proven wrong, I decide that this isn't the solution I am going to start with.
      Well, what value does the factory really add? Not anything yet. It just adds a bit of complexity. I really should have at least started without the factory, because it shouldn't be around if it doesn't add value. It feels strange to refactor away from a factory. But it's just a sign that I got carried away and started out with a too detailed design from the beginning.
      B4
   3. whiteboard or sketchpad for software design meetings
      Diagrams are a means of communication and explanation, and they facilitate brainstorming. They serve these ends best if they are minimal.
      resources
      B1
   4. Strategic Design Decision Making
      Strategic design requires minimalism and humility
      resources
      B1
   5. source control
      1. SVN
   6. Software Factories
      The idea of Software Factories is to have two lines in the software company. One line creates architectures, frameworks, and such to be used for families of applications. The other line creates the applications by using what the first line has produced, and thereby amortizing the cost of the frameworks on several projects
      A problem is that it's troublesome to just invent a framework. It's probably a better idea to harvest instead. Another thing that is somewhat problematic with Software Factories, though, is that they probably require pretty large organizations before being efficient to use
      At the heart of Software Factories is that of Domain Specific Languages
      resources
      B4
   7. risk management
      except when the team has proven skills and the domain is very familiar, the first-cut system should be based on some part of the CORE DOMAIN, however simple.
      the CORE DOMAIN is high risk because it is often unexpectedly difficult and because without it, the project cannot succeed.
      resources
      B1
   8. project documentation
      Documents Should Complement Code and Speech
      resources
      B1
   9. continuous integration
      The key to significantly reducing integration problems is to generate your builds automatically and to use an incremental integration strategy where all the code is rebuilt and tested at least daily, if not continuously. The idea is that if your recently added code breaks a build, you either fix it immediately or roll back the changes to restore the system to the last known good state.
      resources
      B4
   10. bug fixing
       It's a good idea to use TDD and refactoring for bugfixing also. First expose the bug with a red test, then solve the bug so you get green, and then refactor.
       resources
       B4
   11. Big Design Up-Front (BDUF)
       I think it's pretty well known that a Big Design Up-Front (BDUF) has some big problems. At the same time, most often we know some things from day one. It's a matter of balance.
       resources
       B4
   12. automated build & deploy
       code & implementation
       E2

You can find the entire list of techniques in progress in the Development base concepts category. Please feel free to leave any comments or suggestions which could make these lists more useful for everyone.

Also, if you are interested in learning these skills you can try the Developer training modules.