Patrones: El libro del GoF fue el primero masivamente popular, pero ni fue el primero, ni es el único libro sobre patrones, ni es el de mayor aplicabilidad, ya que el contexto de los patrones ahí descritos son interfaces de usuario. Tenemos por ejemplo la serie de ”Pattern Oriented Software architecture” que describe patrones en varios dominios de aplicación, incluyendo sistemas en red,concurrentes y sistemas distribuidos. También está la serie Pattern Languages of Program Design, que inició tan solo 1 año después de la publicación del GoF y que cuenta con 5 volúmenes. También está el libro de Fowler: Pattern Languages of Application Architecture, que se enfoca más al tipo de problemas que eran más comunes entre los desarrolladores de aplicaciones tipo ‘enterprise’ y a las mejores soluciones conocidas en el momento de su aplicación (muchas de ellas todavía vigentes hoy en día). NO HAY 1 LIBRO DE PATRONES POR EL CUAL SE DEBA COMENZAR.
Principios de Diseño.Estos principios son solo un conjunto mínimo de programación OO en pequeña escala. A medida que se desarrolla software de mayor tamaño, otros principios y patrones son necesarios ya que SOLID no basta. Por otro lado, la tecnología OO no es la única existente ni la mejor en cada situación. Cabe la pregunta: ¿Hay principios de diseño universales independientes de la tecnología OO? Seguramente sí, y es obvio que sería conveniente para todos nosotros identificarlos y conocerlos, ya que la tecnología OO es de aplicabilidad contextual y temporal.
Métodos:Más que aprenderse cada uno de estos métodos, creo que conviene más entender los principios que están detrás de ellos. Muchos de estos métodos difieren en los comos, pero comparten los mismos principios. transparencia y honestidad, retroalimentación temprana, no hacer grandes promesas incumplibles, pero sí pequeñas promesas con mayor probabilidad de ser cumplidas, reconocer que los desarrolladores de software deben ser los expertos en el tema y por tanto deben decidir en la manera en que se organizan, las herramientas que seleccionan, el proceso que siguen, etc. así como el reconocimiento de la responsabilidad que todo esto conlleva. Entendiendo los principios y el por qué de las cosas, importa poco si un equipo sigue scrum, crystal o inventa su propia metodología a la cual eventualmente alguien dará un nombre, lo que importa es que están asumiendo su rol, responsabilidad y en base a ello están organizando su trabajo.
Disciplinas: Sin comentarios, todas las mencionadas son importantes, aunque sin duda falta agregar varias, entre ellas: manejo rigurosos de versiones, revisiones de código, inspecciones de seguridad, entrega continua (solo para expertos), evaluación de atributos de calidad, refactorización, etc.

JJ, muchas gracias por este post, y una disculpa por no haberlo leído y comentado antes.
Saludos!

En el primer código podría ser, sustituyendo la llínea 09 y 10 por:
new Thread(() => method1(temp)).Start();

En el segundo código, cambiando la línea 9 por:
Task.Factory.StartNew(() => method1(temp));

O no estoy viendo algún otra cosa?

Gracias por los comentarios!