¿Cuál es la diferencia entre trabajar en una compañía de software y una compañía cuyo enfoque está en otro campo? [cerrado]

Recientemente, una agencia de publicidad local se me acercó con una oportunidad de trabajo. Traen todo el desarrollo web / interactivo internamente y lo agregan a su equipo de desarrollo.

Me estoy cansando de mi trabajo corporativo cómodo pero aburrido, y estoy intrigado por el puesto.

Habiendo trabajado solo para tiendas de software donde el negocio principal estaba haciendo software, me preocupa que no pongan énfasis en las prácticas de software de calidad, ya que el desarrollo no es el foco de su negocio.

¿Podría alguien con experiencia en comparación / contraste trabajar en una compañía de software con trabajar en una compañía que tiene un equipo o departamento interno de desarrollo de software?

Dependerá de la empresa. Pero generalmente, si no es su enfoque principal, el software será de menor calidad. El proceso, si tienen alguno, será menos estricto. La prueba no existe. Y el trabajo en general es menos desafiante técnicamente.

Querrán que funcione, y que funcione ahora, y eso será lo suficientemente bueno.

Pero algunos lugares están a la moda del desarrollo de software, incluso si son tiendas de mamá y pop que hacen algo completamente diferente. Depende de que el liderazgo empresarial esté abierto a las buenas ideas, el liderazgo tecnológico sepa lo suficiente como para hacerlo bien y tenga personas que puedan explicar una buena idea. ¿Cuál podrías ser tú?

Entrevista a la empresa. Pregúnteles si sabe / se adhiere a la prueba de Joel. La mayoría de ellos son buenos puntos. Vea si entienden la deuda técnica y el mítico hombre-mes. ¿Quién es su gerente de proyecto, qué proceso utiliza y qué tan geek es?

Hay una gran diferencia. En el primero, eres parte de un centro de ganancias. En este último, eres parte de un centro de costos. ¿Adivina cuál recibe un mejor tratamiento?

Ahora trabajo para una compañía de software y estoy MUCHO más feliz de lo que estaba en mi último trabajo, donde todo era despidos y outsourcing todo el tiempo, y los desarrolladores eran vistos como widgets fácilmente reemplazables (en lugar del corazón de la compañía).

Los programadores siguen siendo programadores. El hecho de que el producto principal de la compañía no sea software no significa que un programador no necesite las mismas comodidades.

He trabajado en el departamento de TI de grandes empresas desarrollando software para uso interno; He trabajado en compañías que desarrollan software para el mercado; y he trabajado en agencias que realizan desarrollo web para clientes.

Y no diría que hubo alguna diferencia entre esas diferentes compañías en términos de la importancia de impulsar la productividad.

Mantener productivos a los programadores es vital independientemente de qué tipo de desarrollo estén haciendo esos programadores. Y diría que mantener contentos a los programadores y hacer que trabajen para usted es aún más importante cuando son programadores de mantenimiento en el departamento de TI de una empresa que no es de software.

La diferencia depende en gran medida de la propia empresa; He trabajado en buenas compañías que no son de software y en terribles compañías de software. Sin embargo, en promedio, esto es lo que he encontrado:

Empresa no relacionada con el software

Se hace hincapié en hacer las cosas rápidamente, sin pensar en la calidad o el mantenimiento a largo plazo. Los desarrolladores suelen ser técnicamente ignorantes más allá de lo que han hecho en el pasado o durante su tiempo en la empresa, y a menudo intentan introducir nuevos conceptos (ORM, principios SÓLIDOS, TDD, etc.) se encontrarán con confusión o despido inmediato. La gente tiende a centrarse más en "remolcar la línea de la empresa".

Compañía de software

Énfasis en hacer las cosas sin sacrificar la calidad. Es más probable que los compañeros de trabajo se mantengan actualizados con la tecnología (ya sea que puedan utilizarla o no en el trabajo) y, a menudo, vean cómo pueden integrar nuevas ideas o marcos en la rutina diaria para mejorar el software. Si aún no están familiarizados y utilizan conceptos como TDD, ORM, SOLID, etc., probablemente lo hayan escuchado y estén más dispuestos a evaluarlos.

De nuevo, esto depende de la compañía final. Trabajé en una compañía que no es de software con un equipo extremadamente ágil que adoptó TDD y ORM y me enseñó mucho sobre la ingeniería de software adecuada, y trabajé en una pequeña compañía de software que escribió el código de espagueti VBScript del peor tipo y tenía más de 50 desarrolladores que cada uno tenía que trabajar en diferentes páginas para evitar que las cosas se rompieran, y toneladas de burocracia incluso para un cambio menor. Sin embargo, cuanto menos dependa externamente la empresa del software, es más probable que el entorno sea muy pobre para el desarrollo del software.

He trabajado como el único desarrollador de software en un piso de personas que no son de software, y creo que la independencia es aún más importante en ese caso. Cuando no tiene docenas de personas que usan las mismas herramientas, debe tomar muchas más decisiones: qué lenguaje usará, qué compilador, qué servidores, etc. Los desarrolladores solitarios necesitan más libertad para instalar, evaluar y administrar software eso se da por sentado en un entorno grupal.

Una diferencia con certeza será menos énfasis en los gastos generales y la cinta roja que tiene que pasar en una tienda de software corporativo. Descubrirá que podrá tener un control mucho más granular sobre todos los aspectos de sus proyectos.

Un profesional es que esto puede ser refrescante ...

Sin embargo, resultó terriblemente para mí personalmente, pero eso puede ser porque elegí mal. Una gran desventaja es que ya no estás atado al pan de cada día del negocio y en cambio eres un gasto administrativo. Los controladores de presupuesto me trataron como si yo personalmente tomara dinero de sus billeteras y procedieron a "golpearme como una mula alquilada", por así decirlo. Para mí fue una prueba exasperante y agotadora, por lo que debe buscar cuidadosamente signos de este tipo de actitud cuando se entrevista.

Ya hay algunas respuestas geniales aquí, pero me gustaría hacer referencia a un enlace a la transcripción de la segunda parte de una charla que Joel Spolsky dio en la Universidad de Yale:

Joel Spolsky - Talk At Yale Parte 2 de 3

Allí habla sobre la diferencia entre programadores "internos" y programadores que trabajan en compañías de software / tecnología.

Sus tres puntos principales son:

• Cuando eres un programador interno, nunca puedes hacer las cosas de la manera correcta. Siempre tienes que hacer las cosas de la manera más conveniente.

• Como programador interno, una vez que un software es "suficientemente bueno", deja de trabajar en él. Cuando desarrolla "productos" de software, puede hacerlos hermosos.

• Cuando eres programador en una empresa de software, el trabajo que estás haciendo está directamente relacionado con la forma en que la empresa gana dinero. Eso significa, por un lado, que la gerencia se preocupa por ti.

Personalmente, he trabajado tanto en compañías de software como en compañías que no son de software a lo largo de mi carrera, y aunque siempre hay excepciones a cada regla, estoy de acuerdo con los puntos de Joel, ya que la gran mayoría de las compañías parecen estar de acuerdo con ellos.

Una diferencia importante es que al trabajar en una tienda de software probablemente esté ayudando a generar empleos dentro de la empresa. Trabajando en el departamento de programación. en general, un tipo diferente de empresa significa que usted está escribiendo software para reemplazar a las personas. Es una realidad deprimente con la que lidiar. Dicho esto, una agencia de publicidad puede muy bien ser una bestia completamente diferente. Más como una tienda de desarrollo web dentro de otra compañía, sería mi suposición.

Bueno, según mis observaciones, hay al menos dos casos en los que seguir las fronteras de la compañía de software en materia de supervivencia profesional .

El primer caso es si uno está totalmente interesado en la codificación: dame 80 ... 90 ... 100% de tiempo para codificar o me muero . En las tiendas de software, esto es casi un hecho, como si todos supieran cómo llegar allí porque, bueno, porque todos están haciendo exactamente eso. Pero afuera , existe un riesgo muy alto de no lograrlo. Uno puede llegar a ser tan bajo como 50, 40, 30% (mi carga de codificación personal una vez bajó al 20% - ¡no es broma, medí en JIRA !) No es porque "ellos" no quieren que codifiques, no, pero quieren , pero ... puede que simplemente no sepan cómo.

El segundo "riesgo mortal" es si alguien tiene serios problemas de comunicación. Esto puede ser problemático incluso en las tiendas de software, claro, pero al menos hay buenas posibilidades de sobrevivir y vivir una vida productiva agradable sin interacciones perturbadoras. :) Sin embargo, en las compañías que no son de software, tales posibilidades son mucho más bajas; todo lo contrario, es casi inevitable que uno eventualmente tenga que hacer un gran esfuerzo para educar a algún extraño en los fundamentos de TI solo porque de lo contrario será imposible hacer el trabajo.

Bueno, excepto por los dos casos mencionados anteriormente, no conozco ninguna otra razón fuerte para encerrarse estrictamente en las compañías de software. Ahora, ¿qué lado preferir? Por lo que puedo decir, esto es más una cuestión de gustos, de qué tipo de diversión hace más clic en ti.

Ambas partes ofrecen sus propias formas distintas de divertirse. No es fácil de describir.

Yo diría que las compañías de software son más divertidas para aquellos que buscan "altas calificaciones", mientras que las externas les entusiasman a aquellos que luchan por "una gran diferencia". Pienso en esto de la siguiente manera (los números de nota a continuación se inventan solo para simplificar hacer un punto) ...

• En la firma de software, uno tiene la oportunidad de ofrecer 100 funciones al año, la marca más alta que nadie ha logrado aún. Va a ser difícil, va a ser difícil, va a ser superior , con una mejora del 50% sobre 70 características al año. Gran desafío, de verdad.
• Al mismo tiempo, en una empresa externa , uno tiene la oportunidad de ofrecer 50 funciones al año, el mayor impulso que nadie haya logrado. Va a ser difícil, va a ser difícil, va a ser grande , con un increíble aumento del 500% sobre un promedio de 10 funciones al año. Gran desafío, confía en mí.

Tenga en cuenta que las posibilidades de obtener un aumento del 500% en la compañía de software son insignificantemente pequeñas en comparación, y respectivamente, las posibilidades de lograr 100 características son insignificantemente pequeñas en el exterior .

Las mejores calificaciones a un lado amplían nuestra comprensión de los límites profesionales, mejorando nuestro conocimiento sobre cómo hacer las cosas mejor. La gran diferencia en el otro lado tiene un profundo impacto en la cultura de la empresa, mejorando el conocimiento externo sobre cómo hacerlo correctamente.

Ahora, si tiene una clara preferencia por uno u otro, ya sabe qué lado tomar. O, si no está decidido, simplemente siéntase libre de moverse entre ellos como lo desee. :)

Felicitaciones a la respuesta del centro de costo vs beneficio.

He estado en ambos y preferiría una compañía de software. Dado que su correlación con las ganancias es más obvia, es más probable que tenga una compensación adecuada basada en el rendimiento y una cultura corporativa general que abarque la personalidad de los desarrolladores de software. A menudo, eso se traduce en menos política de oficina, no se requieren Dockers, trayectorias profesionales obvias y menos BS. Pero si te gusta más un 9-5 estable, quizás menos desafiante, no un concierto de vanguardia que a veces el departamento de TI es una mejor oferta, no siendo cínico aquí, entiendo que a algunas personas les gusta un equilibrio trabajo / vida más típico a expensas de otras cosas. En mi experiencia, la calidad general de un desarrollador es mucho, mucho mejor en una empresa de software; opuesto a la mediocridad que a menudo impregna el cuerpo de TI. Sé que hay excepciones,

TI es parte del grupo de soporte en compañías que no son de software ... Los programadores de software desarrollaron aplicaciones que ayudarán a la compañía a obtener una productividad mucho mejor, transacciones más rápidas, soporte técnico, grabado ... Algunas compañías que no son de software (Fabricación / Grabado industrial) ofrecen capacitaciones y otros cosas para sus programadores, pero muchos no lo son, por lo que solían subcontratar programadores en otras empresas.

¿Podría alguien con experiencia en comparación / contraste trabajar en una compañía de software con trabajar en una compañía que tiene un equipo o departamento interno de desarrollo de software?

Prefiero contrastar trabajar dentro de un departamento de SI con trabajar en el brazo de desarrollo de productos de una compañía que vende software. Solo para aclarar cada lado y dar algo de cada uno, con algunas correcciones de formato:

Departamento de IS

La empresa puede fabricar hardware, software, automóviles o lo que sea, pero la clave aquí es que hay un departamento interno que es responsable de los sistemas que la empresa utiliza día tras día. Aquí puede haber marcos como ITIL que pueden intentar aportar algo de madurez a los procesos que el departamento ejecuta como parte de este departamento, son los tipos de infraestructura que mantienen las luces encendidas y la otra parte son los tipos de desarrollo y análisis que ponen mejoras , mejoras y nuevos sistemas. Aquí los proyectos pueden variar en longitud, aunque en algunos casos puede llevar años implementar completamente un sistema debido a fases en el despliegue si algún sistema grande se reemplaza como un CMS, CRM o ERP.

A veces he tenido la sensación de ser un engranaje en una máquina y en otros es bastante bueno ser parte de la columna vertebral de la empresa para los altibajos de tal posición. No presumo demasiado a las personas fuera de la empresa porque la mayor parte de mi trabajo está en sistemas internos que no están destinados a ser accesibles o vistos públicamente. Aquí puede haber tickets de soporte en los que uno tenga que tratar con proveedores de software, ya que alguien tiene un problema que no es necesariamente algo en lo que es fácil saber qué causó el error y, por lo tanto, el departamento de IS debe hacer un seguimiento con otra persona para ayudar a resolver el problema. En otros casos, es posible que se deba modificar alguna personalización debido a los requisitos cambiantes o las reglas comerciales.

Compañía de software

Aquí esto está trabajando en lo que la compañía vende directamente y, por lo tanto, hay algunas grandes diferencias de reglas. Primero, el cliente aquí no se puede encasillar tanto como el caso del departamento de IS. En el departamento de SI puede haber solo unos pocos usuarios de un sistema, de modo que la gobernanza pueda ocuparse de muchos casos extraños en los que si alguien elige mal usar una herramienta, eso no siempre se puede evitar. En la compañía de software no existe esa red de seguridad. Si alguien descarga su software y logran encontrar una manera de hacer algo bastante destructivo con él, la compañía puede obtener un gran ojo morado por ello. En este caso, puede haber algo de alarde de lo que hice, ya que puede haber alguna característica interesante para mostrarle a un amigo o familiar si quieren saber un poco más sobre lo que hago.

Algo a tener en cuenta aquí es que puede haber empresas que se incorporan como integradores de sistemas para implementar un gran software empresarial personalizable que trabaje con personas en los departamentos de IS en la implementación de cosas de un millón de dólares, así como aquellas que trabajan directamente para la empresa que realiza el Gran software en sí. También puede haber proveedores de servicios de aplicaciones a los que someteré aquí, ya que generalmente venden un servicio que se basa principalmente en software. Por ejemplo, Google puede tener un departamento de SI, así como varios desarrolladores de software, a pesar de que uno no iría a una tienda a comprar un DVD del software de Google, al menos no creo haberlo visto. Conozca muchos productos de Google en línea que se pueden utilizar con bastante facilidad. Esto puede permitir cierta especialización ya que no

Recientemente trabajé en una gran empresa estadounidense que no es de software, donde un colega escuchó al CEO decir "No me importa un comino el software que ejecuto * *". En mi experiencia, esto es normal para el curso. Casi inevitablemente habrá problemas que parezcan obvios para el equipo de software, pero la administración que no es de desarrollo se negará a pensar.