¿Por qué se le pagaría más a un administrador del sistema que a un programador?

Los desarrolladores tienen mucha más demanda que los administradores de sistemas y se les paga más en términos absolutos , especialmente ahora que todo está en la nube. No tiene que depender de la misericordia de los administradores de sistemas para configurarlo con un servidor en hardware. Puede instalar una instancia de VMWare en su computadora portátil quadcore con 8GB de RAM y hacer lo que quiera. A los desarrolladores también se les pagará más porque al principio contratan ingenieros para construir productos y luego contratan a los administradores de sistemas mucho más tarde en el proceso para que todo siga funcionando. Por lo tanto, los desarrolladores tienden a obtener más equidad.

Dada la elección, conviértete en un ingeniero de software estrella. Ganará mucho más dinero y podrá construir lo que le falta en su vida.

Dicho esto, hay cosas específicas de esta profesión que serían ajenas a los desarrolladores. Resulta que soy tanto un administrador de sistemas como un desarrollador. Creo que en estos días lo llaman devops. 🙂

Los administradores de sistemas de Windows deben mantenerse al día con la innovación de Microsoft . Esa innovación hace nuestras vidas miserables. Imagine que una parte importante de su base de conocimiento se vuelve obsoleta en cada lanzamiento importante. No es tan malo para los administradores de sistemas Linux, pero tengo que volver a entrenarme para cada lanzamiento de producto de Microsoft. No solo eso, se espera que recuerde los casos únicos mutuamente excluyentes para lanzamientos múltiples de productos.

Sé cómo soportar al menos 200 paquetes de software diferentes . No tengo idea de cuántos paquetes de software conozco, pero probablemente pueda escribir más de 200 una vez que empiece a escribirlos. Porque sé cómo diseñar software y cómo funcionan las bases de datos, incluidos Berkeley DB, JET, Firebird y varias otras especies integradas de RDBMS; Puedo “engañar” y comprender rápidamente nuevos paquetes de software cuando los encuentro. Por ejemplo, puedo monitorear llamadas a la base de datos usando procmon y entender por qué la aplicación se rompe en cuestión de segundos.

Microsoft finalmente comenzó a hacer las cosas más parecidas a Unix con Powershell a partir de Exchange 2007. Eso nos lleva al segundo punto, que es que los administradores de sistemas no siempre son desarrolladores . Se espera que los mejores administradores de sistemas puedan escribir scripts. No es un requisito estricto. No fui desarrollador durante gran parte de mi carrera como administrador de sistemas, pero seguía siendo muy bueno resolviendo problemas complejos.

Como desarrollador, puede identificar con un alto grado de certeza si el error está en su código o en algún código de terceros. Tampoco tienes tu conocimiento irrelevante cuando hay una nueva versión. Una excepción que se me ocurre es la versión PHP 4.2.0 [1].

Advertencia
Esta característica ha sido DEPRECADA a partir de PHP 5.3.0 y eliminada a partir de PHP 5.4.0.
Quizás el cambio más controvertido en PHP es cuando el valor predeterminado para la directiva PHP register_globals fue de ON a OFF en PHP »4.2.0. La confianza en esta directiva era bastante común y muchas personas ni siquiera sabían que existía y asumieron que así es como funciona PHP. Esta página explicará cómo se puede escribir código inseguro con esta directiva, pero tenga en cuenta que la directiva en sí no es insegura, sino que es el mal uso de la misma.

Imagine tener que lidiar con cosas así para cada lanzamiento de producto para múltiples productos de software. En muchos casos, admitirá en varias versiones paralelas porque a los proveedores no les gusta actualizar las instancias del servidor SQL. SQL Server, por ejemplo, comenzó a requerir una contraseña sa no en blanco en el momento de la instalación a partir de algún paquete de servicio de MSDE 2000. También ignora el conmutador / SAPWD que lo especifica si la contraseña sa ya está establecida.

Este es un ejemplo de cosas que ya no recuerdo. Hace 7 años, podría haberle dicho el paquete de servicio exacto que comenzó a requerir el interruptor / SAPWD durante la instalación. Otro ejemplo es mi conocimiento de Exchange 5.5 y, en gran medida, de Exchange 2003. Exchange 2007 y 2010 son muy diferentes. Los conceptos básicos se transfieren, pero cada herramienta es diferente y no puede estar seguro de los resultados basados ​​en la experiencia con versiones anteriores.

Como administrador de sistemas, tengo que depurar problemas usando solo las interfaces que el proveedor de software me proporcionó o usar hacks de terceros . En Windows, eso significa usar herramientas como procmon para monitorear el sistema de archivos y las llamadas de registro. Buena suerte entendiendo lo que todo eso significa. Ahora soy un desarrollador de nivel de sistema de Windows en virtud de la necesidad, por lo que puedo entenderlo, pero la mayoría de los administradores de sistemas se perderían.

Microsoft trató de resolver este problema con Small Business Server 2003. Una de las directivas dadas para ese maravilloso paquete de software, y de hecho fue maravilloso cuando funcionó y realmente me encanta, fue ignorar las mejores prácticas de la industria y solo usar los asistentes de SBS para administración. Si intentara configurar manualmente el servidor, los asistentes se romperían y todo el servidor sería difícil de volver al estado compatible.

Aquí hay un ejemplo práctico y extremadamente común : un paquete de software se niega a instalar y devuelve el código de error 1603. 1603 significa que un proceso secundario generado por el instalador falló. El instalador de Windows genera recursivamente otros procesos. La razón por la que falló rara vez es obvia. Estos registros, que obviamente nunca se nombran y no están en XML, desafortunadamente, son difíciles de leer y Splunk (producto) aprovechó esa oportunidad.

Aquí hay una porción de un registro del instalador de Visual Studio 2012. Tiene más de un megabyte de tamaño. Intuitivo, ¿no es así? 😉

[1F2C: 1BB0] [2012-12-19T16: 05: 26]: Paquete planificado: vs_teamExplorerCoreRes, estado: Presente, predeterminado solicitado: Presente, ba solicitado: Presente, ejecutar: Ninguno, deshacer: Ninguno, caché: No, no caché: No, dependencia: registrarse
[1F2C: 1BB0] [2012-12-19T16: 05: 26]: Paquete planificado: SSDTDBSvcExternals, estado: Ausente, predeterminado solicitado: Presente, ba solicitado: Presente, ejecutar: Instalar, revertir: Ninguno, caché: Sí, sin caché: No, dependencia: registrarse
[1F2C: 1BB0] [2012-12-19T16: 05: 26]: Paquete planificado: dpeftools_200, estado: Obsoleto, valor predeterminado solicitado: Ninguno, ba solicitado: Ninguno, ejecutar: Ninguno, deshacer: Ninguno, caché: No, no almacenar en caché: No, dependencia: ninguna
[1F2C: 1BB0] [2012-12-19T16: 05: 26]: Paquete planificado: dacframework, estado: Ausente, valor predeterminado solicitado: Presente, ba solicitado: Presente, ejecutar: Instalar, deshacer: Ninguno, caché: Sí, sin caché: No, dependencia: registrarse

Para hacer las cosas más divertidas, el proveedor de software ahora está fuera del negocio o ya no admite su lanzamiento. Ahora la administración quiere que descubras cómo hacer que se ejecute de todos modos. 🙂

Las tonterías de lucha contra incendios como esta le quitan tiempo para prevenir incendios en primer lugar. Las empresas rara vez dan a los administradores de sistemas el tiempo suficiente para realizar un trabajo estratégico. Como consultor, dejo en claro que estoy allí para implementar lo que está dentro de mi alcance de trabajo y que no dependeré de su equipo, excepto por la transferencia de conocimientos a ellos.

Los administradores de sistemas expertos automatizan todo . Reduje mi jornada laboral a tiempo completo en el sitio a 20 minutos desde casa una vez, incluida la producción de informes de gestión ligeramente aleatorios cerca del final del día. Lo hice hace muchos años y disfruté muchísimo “trabajar” en esa compañía. Viví a 10 minutos y respondí a las anomalías cuando era necesario. Por algún contexto, apoyé a más de 1500 usuarios y 70 servidores en esa compañía.

En otra compañía, automaticé completamente todo lo relacionado con Solaris y pasé la mayor parte de mi tiempo ayudando a mi contraparte de Windows y ejecutando Oracle en Solaris. Mi descripción oficial del trabajo era administrar nuestros servidores Sun. Bueno, Solaris se administra muy bien en comparación con Windows. 😉

A partir de 2013, Windows mismo ha alcanzado a Unix desde la perspectiva de la administración gracias a Powershell. El problema con la gestión de versiones de software sigue siendo tan grave como siempre.

Al mismo tiempo, siempre somos vistos como un centro de costos para la empresa. No producimos nada. Somos los fontaneros de infraestructura invisible. Es difícil relacionarse con nuestros requisitos de presupuesto porque cuando las cosas funcionan nadie sabe que existimos .

El problema profesional de los administradores de sistemas expertos es que contratar a un administrador de sistemas promedio se considera lo suficientemente bueno para muchas empresas . Las empresas más pequeñas no pueden contratar buenos administradores de sistemas porque ¿qué demonios haríamos allí? Automatizaría todo en dos semanas y me aburriría. Por lo tanto, contratan administradores de sistemas que no pueden conseguir trabajo en empresas donde importan y pagan un salario anual a alguien que no tiene ningún incentivo para volverse irrelevante. Al final, cojean en lugar de usar TI como una ventaja competitiva.

Es un gran problema y he estado involucrado en este campo desde 1994. Estoy construyendo silenciosamente una buena solución a este problema. 🙂

[1] Uso de Register Globals
[2] Cómo especificar una contraseña segura de SA cuando instala SQL Server 2000 Desktop Engine (MSDE 2000)

Otros han cubierto esto en gran medida. Pero aquí están mis 2cents:

Los SysAdmins (DevOps, Ops, OpsEng, SRE, etc.) pueden o no hacer más que un Programador (Ingeniero de software, Ingeniero, Desarrollador, Codificador, etc.). Depende de muchos factores: tiempo, ubicación, empresa, habilidades personales, experiencia, oportunidad, etc.

Pero yendo con la cadencia de la pregunta, es decir. lo que justifica que a un SysAdmin se le pague más por un ingeniero de software, suponiendo años de experiencia similares, etc.

Tiempo de actividad

Los administradores de sistemas, desde el primer momento en que uno asume ese papel hasta su último aliento, se trata de tiempo de actividad. Vivimos y respiramos el tiempo de actividad. Valoramos la estabilidad. Para SysAdmins, asegurarse de que la “producción” se mantenga y funcione bien, es el trabajo número uno. Todo lo que pueda afectar esto es algo que necesita ser gestionado, modificado, examinado, probado y filtrado antes de que llegue a producción.

Esto significa soporte on-call 24/7 de una plataforma. Esto significa monitoreo y un nivel de atención casi paranoico prestado a una configuración que podría ser tan pequeña como unas pocas docenas de cajas hasta literalmente decenas de miles de cajas.

Estabilidad

Esto afecta directamente el tiempo de actividad. Y así, la estabilidad de la plataforma, la pila completa de aplicaciones, es algo que le importa a SysAdmin. En una empresa pequeña, SysAdmin es su administrador de correo electrónico, administrador de red, administrador de servidor, administrador de aprovisionamiento, administrador de seguridad, etc. Por lo tanto, SysAdmin necesita saber todo lo posible sobre la pila. En muchos casos, esto significa que el SysAdmin realmente aprende el código que se está implementando para que puedan depurarlo y presentar un informe a los desarrolladores para corregir el error en cuestión.

Y cuando ese error no se puede solucionar … o se le da prioridad, recae en el SysAdmin para crear soluciones alternativas para garantizar que la plataforma, si es inestable, permanezca activa.

En llamada

DIOS MIO. En llamada. Solía ​​reír cuando veía dramas de televisión sobre doctores a los que llamaban: en medio de la noche, mientras cenábamos, en una película, en medio de un momento amoroso … todo eso se pone de lado cuando ese localizador comienza a alertar o tu el teléfono explota con mensajes de texto … para ser seguido unos minutos más tarde con llamadas de su gerente o director. No es alguien que necesita cirugía cardíaca … no, es el negocio perder dinero por minutos.

On Call significa que SIEMPRE tiene su computadora portátil con usted. Siempre tienes tu teléfono / buscapersonas / segundo teléfono contigo. Significa que durante el tiempo que está de guardia, su vida no es suya.

En bastantes compañías, mientras que SysAdmins estaban de guardia, los desarrolladores que escribieron el código no. Entonces, los administradores de sistemas se convierten en los primeros en responder, los coordinadores de incidentes, los que tienen a alguien respirando desde atrás preguntándose cuánto tiempo más antes de que se apague el fuego.

He trabajado días completos, solo para estar en la oficina durante otras 8-10 horas porque algo estaba en llamas.

Lo que OnCall significa es que el equilibrio de su vida laboral se ve muy afectado. ¿Tienes que ir a la graduación de tu hijo? Mejor traiga su equipo de punto de acceso inalámbrico. ¿Ir al cine? Mantenga su equipo con usted y su teléfono / buscapersonas en silencio. ¿Vas a hacer un largo viaje por carretera? Es mejor programarlo cuando no esté de guardia, porque es posible que … solo deba ir al centro de datos para arreglar algo que falló y necesita un intercambio.

Visibilidad generalmente negativa

Por lo tanto, los SysAdmins trabajan duro para asegurarse de que todo funcione correctamente, se mantenga despierto y sacrifique el tiempo de sueño / personal para asegurarse de que todo funcione las 24 horas, todos los días. Pero, en general, el equipo de Operaciones / Soporte de producción / SysAdmin obtiene una muy mala reputación / rap:

• Los administradores de sistemas se quejan de que algo es un mal diseño … ¿por qué no hablaron antes? (No importa si no se dieron a conocer o se les invitó a las reuniones de diseño y los problemas de diseño se descubrieron durante la reunión de revisión de aprobación de producción final … etc.)
• Debido a lo anterior, los SysAdmins están “bloqueando” la productividad y lo que “The Business” quiere.
• ¿Por qué el equipo de operaciones no puede “simplemente” darnos lo que pedimos? (O algo que requiere abrir el acceso, instalar muchos paquetes de última generación, o un diseño con múltiples puntos únicos de falla …)
• ¿Por qué se cayó el sitio de producción? ¡¿Pensamos que se suponía que Ops debía atrapar esto ?! (Después de que las personas que querían la implementación obtuvieron una excepción al escalar por encima de la administración del equipo de Ops y expulsaron el código no deseado a la producción).
• ¿Por qué tarda tanto la restauración? (Después de que alguien decidió ejecutar un SQL manual en la base de datos de producción, ya sea sin aprobación, o lo tipeó sin tomar precauciones antes de tiempo … o porque cuando surgió la idea de la replicación de la base de datos / repuesto en caliente, fue derribada por el costo de tener otro servidor que no está haciendo nada útil … etc. etc.)
• ¡El equipo de Ops / SysAdmin es muy grosero! (Ok, hay muchos equipos rudos por ahí. Pero para ser justos, tome los otros puntos negativos anteriores y aplíquelos a un individuo / equipo durante unos años, y se desarrolla una cierta brusquedad. Buen soporte de gestión de protocolos entre equipos y realmente tener equipos trabajando juntos es una excelente manera de resolver esto).
• Lo investigamos nosotros mismos en nuestras máquinas virtuales, ¿por qué Ops no solo puede enrutar el tráfico a nuestra instancia de VM y comenzar a monitorearlo? (Muy, muy mal … y, sin embargo, sucede con demasiada frecuencia … Otra buena variación de esto es la caja de producción debajo del escritorio de alguien … * facepalms *)

Ops tiene mala reputación / reputación porque los administradores de sistemas de un equipo de operaciones terminan siendo los que dicen: “No, no puedes hacer eso”. O “No, la restauración aún no se ha completado, tendrá que esperar”.

Entonces … ¿Por qué se les paga más a veces?

Una buena persona / equipo de SysAdmin / Ops / DevOps / SRE, etc. es tan importante como un buen ingeniero de software Sr./Lead/Architect. Para que un entorno funcione sin problemas, se implemente rápidamente y se mantenga estable, necesita un buen código sólido y probado y una buena plataforma sólida y probada.

En mi opinión, ambos son igualmente importantes y deben compensarse bien por el arduo trabajo que realizan. He tenido la increíble fortuna de haber conocido, trabajado y observado que los ingenieros de software superiores manejan los problemas cotidianos que afectan el lado del desarrollo de software de la empresa. Mantener los repositorios sanos / limpios / limpios. Asegurarse de que las personas no se escabullen en bibliotecas deshonestas, cosas de vanguardia, escribir código horrible que rompa las cosas. (Esto también se aplica a los SysAdmins … nada como un fragmento de código con guiones para arruinar el día de todos … especialmente si se expulsa a varios cientos / miles de cajas).

Un buen ingeniero de software experimentado y sólido, al igual que un buen SysAdmin sólido se hace cargo y se responsabiliza de su trabajo / entorno. Incluso si alguien más lo arruina, se asegurarán de que sea bueno como nuevo y harán cambios en la política / protocolo / acceso para asegurarse de que lo que se rompió no lo vuelva a romper. Al menos, no de la misma manera. Cuando ambos están de guardia, ambos se vuelven más conscientes del dolor causado por las cosas que se rompen y las cosas se arreglan.

Al final del día, la pregunta no debería ser realmente, “¿por qué se le pagaría más a un administrador del sistema que a un programador”, porque esa es una pregunta que arroja una luz muy negativa y supone que uno tiene más valor que el otro. Ambos son críticamente importantes para un entorno de trabajo.

La pregunta que debe hacerse es: “¿Qué hacen los ingenieros que reciben un alto salario y se diferencian del ingeniero promedio?” Cuando digo “Ingeniero”, me refiero tanto a los ingenieros de software como a los ingenieros de sistemas.

• El ingeniero altamente pagado es MUY proactivo. Están buscando activamente mejorar su comprensión del sistema en el que están apoyando / trabajando. Señalan activamente y buscan soluciones a los problemas que descubren.
• El ingeniero altamente pagado está EN LLAMADA. Se apropian de los cambios que realizan en la producción. Ya sea una inserción de código, actualización de paquete, parche de sistema operativo, actualización de sistema operativo o cualquier tipo de implementación. Intentan cubrir tantas bases como pueden y se aseguran de que se minimice cualquier impacto. Estar en llamada asegura que se mantengan informados sobre el impacto de su trabajo.
• El ingeniero altamente pagado es colaborativo entre equipos. Trabajarás con diferentes equipos en diferentes niveles. Ser capaz de comunicarse y trabajar de manera efectiva independientemente de la plataforma / lenguaje de programación / conjunto de herramientas / etc. es muy importante. Comprender lo que otro equipo necesita / quiere y poder comunicar lo que su equipo necesita y quiere asegura que no haya mensajes mixtos.
• El ingeniero altamente remunerado apoya el crecimiento del equipo. Intercambias conocimientos y experiencias con los miembros de tu equipo. Se apoyan mutuamente y trabajan para evitar el agotamiento de otro miembro. Si hay una deficiencia en alguna parte, trabajas para mejorarla. Y en el mismo sentido, si encuentra que hay un elemento disruptivo dentro del equipo, trabaja para resolver esas interrupciones.
• El ingeniero altamente remunerado cuenta con el apoyo de un gerente fuerte y efectivo. Porque no importa qué tan buen ingeniero seas, si tienes un administrador malo, tu futuro es limitado. Con un buen gerente, sus esfuerzos deben ser recompensados ​​y tanto usted como su gerente pueden trabajar para dar forma al crecimiento del equipo.

Hay más elementos, pero la lista continúa.

Al comienzo de mi carrera, me encontré estresando sobre por qué los “desarrolladores” siempre están tirando cosas por la pared a la producción. No fue hasta que trabajé incrustado con ingenieros de software que me di cuenta de que hay un terreno común, pero es solo que un equipo tiene prioridades diferentes frente a otro equipo. Y la mejor manera de garantizar que un entorno maneje bien los cambios, las liberaciones de código, etc. es que todos los equipos se comuniquen bien para que todos los involucrados comprendan la solicitud, la justificación, los riesgos y las expectativas de apoyo.

Y a las personas que pueden trabajar bien de esa manera generalmente se les paga bien, independientemente de si son “SysAdmins” o “Programadores”.

Generalmente hay dos razones por las cuales un trabajo se paga bien:

1. No hay muchas personas que puedan hacerlo o
2. No hay muchas personas que quieran hacerlo

Creo que a la mayoría de las personas les resulta mucho más divertido escribir software que la administración del sistema, por lo que a un administrador de sistemas a menudo se le paga más.

Primero, considere que hay diferencias en el costo de vida de una ciudad a otra, área a área, que definen cuáles son las líneas de base. Los puestos de profesionales en San Jose CA pagarán más que el mismo puesto en Chicago, por ejemplo.

Pero … mucho más importante a considerar es el hecho de que los administradores de sistemas DEBERÍAN pagarse más que los programadores en muchos casos. Su percepción de que un desarrollador debería / recibirá un pago más que un administrador de sistemas es simplemente falsa.

Muchos de los mejores administradores de sistemas también son programadores, que muy posiblemente podrían programar círculos a su alrededor, pero eligen hacer un trabajo más duro y mejor remunerado.

Ser un buen administrador de sistemas es un trabajo DURO, mucho más difícil que programar . Una organización confía a sus administradores de sistemas el cuidado de sus sistemas de producción, los sistemas que le hacen ganar dinero. Esa misma organización no confía en sus programadores: somete su trabajo a innumerables revisiones, pruebas, pases de control de calidad, versiones beta, etc. antes de permitir que su trabajo entre en producción.

En la mayoría de los casos, se considera correcto si un programador introduce accidentalmente un error en lo que construye. Eso es normal para el curso. En casi TODOS los casos, NO se considera correcto si un administrador del sistema inadvertidamente desactiva un servidor de producción al cometer un error similar.

Yo “codifico” líneas simples a través de unas pocas docenas de líneas rápidas sobre la marcha, y obtengo código ad-hoc para necesidades particulares de forma regular, y lo hago de manera segura porque tengo décadas de experiencia. Debemos ser extremadamente cuidadosos, aplicar siempre las mejores prácticas y estar siempre en la cima de nuestro juego.

Recuerde … a menudo es un administrador de sistemas que encuentra y descubre cuáles son sus errores : los que no vio y los que el equipo de control de calidad no vio.

Es por eso que se les pagará más que un programador.

Creo que esta pregunta parte de una suposición errónea. En realidad, no tengo los números reales para decir que uno gana más $$ que el otro, pero creo que eso depende principalmente de (1) habilidades / experiencia y (2) ubicación, como país, ciudad, empresa, función, etc.

Mi sugerencia sería que comiences a hacer lo que más amas y el dinero vendrá con excelencia. Si eres bueno en eso, puedes cambiar fácilmente de sysadmin a programador y viceversa solo por el gusto de probar algo nuevo y ver si quieres. Si lo hace, manténgalo por un tiempo y aprenda algunas habilidades nuevas. Más conocimiento creará más oportunidades para usted (lo que también puede resultar en un mejor pago). Solo recuerda, no pongas dinero como tu primer objetivo profesional.

Como desarrollador / programador, generalmente eres responsable de una parte de la aplicación. Esta aplicación es probablemente solo una parte de un proceso que utiliza un departamento. Toda la organización tiene múltiples departamentos, utilizando múltiples sistemas y aplicaciones, para hacer muchas cosas. El administrador del sistema lo une todo.

Los administradores de sistemas generalmente son responsables de más, y en el mundo corporativo, con la responsabilidad viene el dinero.

Dicho esto, personalmente no creo que esos 2 trabajos sean comparables de ninguna manera. La administración del sistema está más abajo en la cadena de “un producto de TI”.

Hace algún tiempo, el mundo del software cambió de:

• creando software y distribuyéndolo en discos compactos para clientes que luego lo instalarían en su escritorio para trabajar (o pedirle a un administrador del sistema que lo haga por ellos)

A:

• Crear software que esté disponible a través de Internet utilizando navegadores estándar o clientes móviles delgados.

El resultado de ese cambio es que muchas empresas se encuentran ahora ejecutando el software que escribieron anteriormente, en una flota de servidores para proporcionar el servicio a sus clientes. Esta es la actividad que ahora genera ingresos.

La mayoría de estas compañías han descubierto que los desarrolladores no son muy buenos para ejecutar software, se han optimizado durante bastante tiempo en la escritura de software. Sin embargo, ejecutar este software ahora es de repente la habilidad que les hace ganar dinero. Si realmente tienen éxito con el software que produjeron, la compañía tiene que ejecutarlo en muchos sistemas para hacer frente a la demanda.

Los administradores de sistemas se han especializado en la ejecución de software para empresas y clientes de una empresa. El resultado del cambio anterior en la forma en que operan la mayoría de las compañías productoras de software hoy en día ha creado mucha más demanda para estas habilidades.

Como han notado los encuestados anteriores, hay una falta de educación formal y visibilidad para el trabajo de administración del sistema, es complejo y el grupo de talentos es pequeño.

Espero que el salario de los desarrolladores frente a los administradores de sistemas sea mucho más equilibrado en los próximos años.

Por un lado, respondiste tu propia pregunta: el trabajo está en los Estados Unidos y tú no. Para hacer una comparación precisa, tendría que ver qué rango de salario está haciendo un desarrollador con su conjunto de habilidades en esa misma empresa (o al menos en la misma ciudad). Eso te da una línea de base para la comparación.

Como con cualquier cosa, los salarios son una función de la oferta y la demanda. La administración del sistema requiere una gran cantidad de conocimiento especializado tanto en el sistema operativo como en la aplicación, gran parte de la cual solo se puede aprender a través de la experiencia. Encontrar un SA experimentado con el conjunto adecuado de habilidades puede ser un desafío, particularmente si se requiere alguna combinación inusual.

Determinar el monto de la compensación realmente depende de la compañía que esté dispuesta a pagar el precio. Cuando vio que una compañía que desea contratar a un administrador de sistemas ofrecía un pago más alto de lo que obtiene, en realidad no significa que la compañía estaba pagando al sysad más alto que su programador. Pero la compañía podría estar pagando a su sysad mejor de lo que su compañía le paga a usted como programador.

A las personas en algunas empresas se les paga menos que a otras, incluso si producen la misma cantidad de tiempo, talento y esfuerzo para su trabajo. Algunas compañías son simplemente más generosas que otras.

Es posible que desee saber sobre el salario del programador y administrador de la base de datos en Australia. En este caso, puede ir a greythorn.com.au

La mayoría de las personas de TI son bastante idiotas y sabias. Conocí a creadores de desarrolladores que no sabían mucho fuera de su idioma de especialidad, MCSE que no podían formatear un disco duro, pero eran excelentes con SQL, o administradores de sistemas que nunca habían configurado un enrutador, etc.

Sin embargo, al igual que por cada diez de esos desarrolladores de un solo truco, hay un virtuoso de la programación que conoce todos los lenguajes de computadora bajo el sol; también están aquellos administradores de sistemas superdotados que son prodigios absolutos: expertos multiplataforma (* nix, Windows, etc.) que conocen diferentes bases de datos, sistemas de implementación, conceptos de nube, tienen una sólida experiencia en redes y una comprensión fundamental de los diferentes tipos de código .

Para aquellos tipos de administradores de sistemas que trabajan para una empresa que paga bien en general y donde pueden hacer uso de todos esos talentos, hay una buena posibilidad de que puedan ganar más dinero que un desarrollador de un solo truco. Había un chico joven cuando trabajaba en (un gran minorista en línea) alrededor de 2003–2004. Apenas acababa de terminar la escuela secundaria y tenía un conocimiento más profundo de Linux, HP-UX, AIX, PERL, Cisco IOS y casi todas las bases de datos bajo el sol que la mayoría de los estudiantes de informática que conocía con 5–10 años de experiencia en la industria. . Era tan inteligente acerca de su trabajo, que a veces era casi intimidante sentarse en una sesión de resolución de problemas con él, ya sea intencionalmente o no; era muy bueno para hacer que incluso las personas inteligentes parecieran estúpidas.

Una mujer que fue brevemente mi gerente en mi primer trabajo es muy parecida. Dale una hora y acceso de administrador a casi cualquier caja con luces parpadeantes y ella podría escribir un libro al respecto. Ella pasó a hacer un trabajo de ingeniería de DB bastante intenso para una gran empresa de redes sociales y la última vez que escuché fue al vicepresidente de operaciones de algunas puntocom.

Estoy seguro de que el talento natural desempeña un papel en algún nivel, pero al final, tiene mucho que ver con la diferencia entre las personas que están “haciendo un trabajo” y las que realmente se apasionan por su trabajo. Aman lo que hacen y se esfuerzan por ser los mejores en eso.