Si está satisfecho con el código, publicarlo siempre es útil. Soy gerente de contratación de ingenieros, e incluso si el proyecto no es impresionante, me gustaría explorarlo para tener una idea de:

• Si el ingeniero tiene suficiente motivación interna para publicar proyectos paralelos

• Si el código parece seguir la mayoría de las mejores prácticas. No tendré que enseñar a los ingenieros las mejores prácticas si se unen a mi equipo

• Buscando un código bueno, limpio y probado.

¡Si está orgulloso de ello, incluya el enlace!

Deberías.

Su repositorio de github es la única evidencia disponible para ellos de que puede escribir o diseñar cualquier cosa. Sí, su contenido de github podría mejorar. Puse el mío como un motivador para mejorar mis capacidades de ingeniería de software. Mi github está lamentablemente desactualizado, pero me divierte ver dónde estoy en comparación con dónde estaba. Mostrar algo es mejor que no mostrar nada, siempre que el algo que muestres sea positivo, como tu competencia :)

Además, tu enlace de github es tu forma de decir que sabes cómo usar github. En realidad, tuve que aprender los componentes internos de github para hacer eso, pero esa es otra historia para otro día. Como mínimo, publicar tu cuenta de github debería motivarte a aprender todo lo que puedas sobre github. No hay nada como ser demasiado bueno en github :)

Ser un buen ingeniero de software es un proceso, no un punto de terminación para un proceso. A medida que mejora y se vuelve más astuto como solucionador de problemas, sus contenidos de github se vuelven más sofisticados. Y no, el proceso no tiene un punto final :)

En términos de qué publicar, el código que resalta su control sobre los fundamentos está bien. La basura no lo es. La línea entre las cosas buenas y la basura puede ser borrosa. Mi norma es que no publico nada que no pueda justificar como publicable.

Si tuviera una entrevista en mi empresa, le le preguntaríamos si tenía una cuenta de github (o algún otro repositorio de código público) al principio del proceso de contratación.

Dependiendo de sus responsabilidades, buscaremos rasgos específicos (en realidad, más la ausencia de rasgos indeseables) para tener una idea de

• sus capacidades reales versus sus experiencias declaradas
• cuánta capacitación sería necesaria para integrarse en un equipo de proyecto

Entonces, junto con mis predecesores, Recomiendo encarecidamente incluirlo.

Editar 04/2016: re Rasgos indeseables

Feliz coincidencia ... hace solo unos días me encontré con este artículo, que lo resume muy bien para el lado del "programador" de los empleados.

En el nivel de "personalidad" ... es difícil decirlo sin entrar en un monólogo extenso. Recientemente uno de mis clientes me felicitó por cómo siempre logro proyectar tranquilidad y escucharlos, pensar en los problemas antes de presentar una solución, mientras que otros consultores "solo quieren hacer lo suyo" y cobran mucho. A lo que respondí "Dejé mi ego atado en el maletero afuera en el estacionamiento". También han escuchado "No sé, tengo que buscarlo", "Problema interesante, déjame experimentar un poco, sin cargo", "Podría hacer eso, pero si compras X, estarás mejor off "de mí.

TL; DR: estrellas de rock, ninjas del código, magos de la tecnología pura: no. Humano generalmente competente: sí.

Yo digo que sí. Como líder técnico que también hace entrevistas, me gusta ver el código de las personas y, sinceramente, no estoy buscando un código de calidad, aunque eso se notaría si fuera el caso. Se trata más de: ¿Puedes mejorar? Puedes aprender Puedes crecer Para mí, el repositorio ideal es uno que comienza con una aplicación de calculadora realmente vieja y mal hecha y luego el último compromiso es un proyecto de pasión personal con múltiples niveles de complejidad. No es necesario que sea perfecto o bueno. Solo necesito ver si puedes crecer. El candidato ideal es un candidato que sea extremadamente receptivo al cambio y no tenga miedo de aprender cosas nuevas.