Qual é a diferença entre trabalhar em uma empresa de software e uma empresa cujo foco está em outro campo? [fechadas]

Recentemente, fui abordado por uma agência de publicidade local com uma oportunidade de emprego. Eles estão trazendo todo o desenvolvimento interativo / web internamente e adicionando à sua equipe de desenvolvimento.

Estou ficando cansado do meu trabalho corporativo, mas chato, e estou intrigado com a posição.

Tendo trabalhado apenas para lojas de software onde a empresa principal produzia software, receio que elas não enfatizem práticas de software de qualidade, pois o desenvolvimento não é o foco de seus negócios.

Alguém com experiência em comparar / contrastar trabalhando em uma empresa de software com alguém que por acaso tenha uma equipe ou um departamento interno de desenvolvimento de software?

Vai depender da empresa. Mas, geralmente, se esse não for o foco principal, o software será de menor qualidade. O processo, se houver, será menos rigoroso. O teste inexistente. E o trabalho em geral menos tecnicamente desafiador.

Eles querem que funcione, e trabalhe agora, e isso será bom o suficiente.

Mas alguns lugares são descolados em relação ao desenvolvimento de software, mesmo que sejam lojas de produtos para mamãe e bebê fazendo algo completamente diferente. Depende da liderança dos negócios estar aberta a boas idéias, da liderança tecnológica o suficiente para fazer o certo e de ter pessoas que possam explicar uma boa idéia. Qual pode ser você.

Entreviste a empresa. Pergunte a eles se o conhecimento / adere ao teste de Joel. A maioria deles são bons pontos. Veja se eles entendem a dívida técnica e o mítico mês do homem. Quem é seu gerente de projetos, que processo ele usa e como é nerd?

Há uma enorme diferença. No primeiro, você faz parte de um centro de lucro. Neste último, você faz parte de um centro de custo. Adivinha qual deles recebe melhor tratamento?

Eu trabalho para uma empresa de software agora e estou muito mais feliz do que no meu último emprego, onde eram todas as demissões e terceirizações o tempo todo, e os desenvolvedores eram vistos como widgets facilmente substituíveis (em vez do coração da empresa).

Programadores ainda são programadores. Só porque o produto principal da empresa não é software, não significa que um programador não precise das mesmas comodidades.

Trabalhei no departamento de TI de grandes empresas no desenvolvimento de software para uso interno; Trabalhei em empresas desenvolvendo software para o mercado; e trabalhei em agências que desenvolviam web para clientes.

E eu não diria que houve qualquer diferença entre essas empresas em termos da importância de aumentar a produtividade.

Manter os programadores produtivos é vital, independentemente do tipo de desenvolvimento que esses programadores estão fazendo. E eu diria que manter os programadores felizes e mantê-los trabalhando para você é ainda mais importante quando eles são programadores de manutenção no departamento de TI de uma empresa que não é de software.

A diferença depende em grande parte da própria empresa; Eu trabalhei em boas empresas que não são de software e terríveis empresas de software. Em média, porém, aqui está o que eu encontrei:

Empresa que não é de software

A ênfase está em fazer as coisas rapidamente, com pouca ou nenhuma atenção à qualidade ou manutenção a longo prazo. Os desenvolvedores geralmente são tecnicamente ignorantes além do que fizeram no passado ou durante o tempo que passaram na empresa e, muitas vezes, tentam introduzir novos conceitos (ORMs, princípios SOLID, TDD etc.) serão confundidos ou dispensados ​​imediatamente. As pessoas tendem a se concentrar mais em "rebocar a linha da empresa".

Empresa de software

Ênfase em fazer as coisas sem sacrificar a qualidade. É mais provável que os colegas de trabalho se mantenham atualizados com a tecnologia (se eles podem ou não utilizá-la no trabalho) e frequentemente analisam como podem integrar novas idéias ou estruturas na rotina diária para melhorar o software. Se eles ainda não estão familiarizados e estão usando conceitos como TDD, ORMs, SOLID etc., provavelmente já ouviram falar e estão mais dispostos a avaliá-los.

Novamente, isso depende da empresa final. Trabalhei em uma empresa que não era de software, com uma equipe extremamente ágil que adotou TDD e ORMs e me ensinou muito sobre engenharia de software adequada, e trabalhei em uma pequena empresa de software que escreveu o código espaguete VBScript da pior espécie e tem mais de 50 desenvolvedores que cada um tinha que trabalhar em páginas diferentes para evitar que as coisas quebrassem e toneladas de burocracia para uma pequena mudança. No entanto, quanto menos a empresa depender externamente de software, maior será a probabilidade de o ambiente ser muito ruim para o desenvolvimento de software.

Eu trabalhei como o único desenvolvedor de software em um andar de pessoas que não são de software e acho que a independência é ainda mais importante nesse caso. Quando você não tem dezenas de pessoas usando as mesmas ferramentas, precisa tomar muito mais decisões - qual idioma você usará, qual compilador, quais servidores etc. Desenvolvedores solitários precisam de mais liberdade para instalar, avaliar e administrar software isso é um dado adquirido em uma configuração de grupo.

Uma diferença, com certeza, será menos ênfase nas despesas gerais e redirecionadas pelas quais você deve passar em uma loja de software corporativa. Você descobrirá que poderá ter um controle muito mais granular sobre todos os aspectos de seus projetos.

Um profissional é que isso pode ser refrescante ...

No entanto, ficou horrível para mim pessoalmente, mas isso pode ser porque eu escolhi mal. Um enorme engodo é que você não está mais ligado ao pão e manteiga do negócio e, em vez disso, é uma sobrecarga administrativa. Os controladores de orçamento me tratavam como se eu estivesse pessoalmente tirando dinheiro de suas próprias carteiras e passavam a "me bater como uma mula alugada", por assim dizer. Para mim, foi uma provação irritante e exaustiva, portanto, você deve procurar cuidadosamente sinais desse tipo de atitude ao entrevistar.

Já existem ótimas respostas aqui, mas eu gostaria de referenciar um link para a transcrição da segunda parte de uma palestra que Joel Spolsky deu na Universidade de Yale:

Joel Spolsky - conversa em Yale parte 2 de 3

Lá ele fala sobre a diferença entre programadores "internos" e programadores que trabalham em empresas de software / tecnologia.

Seus três pontos principais são:

• Quando você é um programador interno, nunca consegue fazer as coisas da maneira certa. Você sempre tem que fazer as coisas da maneira mais conveniente.

• Como programador interno, quando um software é "bom o suficiente", você para de trabalhar nele. Quando você desenvolve "produtos" de software, consegue torná-los bonitos.

• Quando você é programador em uma empresa de software, o trabalho que você está fazendo está diretamente relacionado à maneira como a empresa ganha dinheiro. Isso significa, por um lado, que a gerência se preocupa com você.

Pessoalmente, trabalhei em empresas de software e não-software ao longo da minha carreira e, embora sempre haja exceções a todas as regras, concordo com os pontos de Joel, pois a grande maioria das empresas parece estar de acordo com elas.

Uma grande diferença é que, trabalhando em uma loja de software, você provavelmente está ajudando a gerar empregos dentro da empresa. Trabalhando no departamento de programação. Em um tipo diferente de empresa, em geral, isso significa que você está escrevendo um software para substituir as pessoas. É uma realidade deprimente para lidar. Dito isto, uma agência de publicidade pode muito bem ser um animal completamente diferente. Mais como uma loja de desenvolvimento web dentro de outra empresa, seria o meu palpite.

Bem, de acordo com minhas observações, há pelo menos dois casos em que as fronteiras da empresa de software estão relacionadas a questões de sobrevivência profissional .

O primeiro caso é se alguém está totalmente em codificação - me dê 80 ... 90 ... 100% de tempo para codificar ou eu morro . Nas lojas de software, isso é quase garantido, como se todo mundo soubesse chegar lá porque, bem, porque todo mundo está fazendo exatamente isso. Mas lá fora , existe um risco muito alto de não chegar lá. Pode-se chegar a 50, 40, 30% (minha carga pessoal de codificação caiu para 20% - não é brincadeira, eu medi no JIRA !) Não é porque "eles" não querem que você codifique - não, eles querem, mas , mas ... eles podem simplesmente não saber como.

O segundo "risco mortal" é se alguém tem sérios problemas na comunicação. Isso pode ser problemático, mesmo em lojas de software, certo, mas pelo menos há boas chances de sobreviver e viver uma boa vida produtiva sem interações perturbadoras. :) Porém, em empresas que não são de software, essas chances são muito menores - pelo contrário, é quase inevitável que, eventualmente, tenhamos que se esforçar muito para educar alguém de fora nos conceitos básicos de TI, apenas porque, caso contrário, será impossível fazer o trabalho.

Bem, exceto nos dois casos mencionados acima, não conheço outro motivo forte para me restringir estritamente às empresas de software. Agora, de que lado preferir? Até onde eu sei, isso é mais uma questão de gosto, de que tipo de diversão clica mais em você.

Ambos os lados oferecem formas próprias e distintas de diversão. Não é fácil descrever.

Eu diria que as empresas de software são mais divertidas para quem busca "notas altas", enquanto as externas dão uma emoção para aqueles que buscam "grande diferença". Penso assim (os números de nota abaixo são inventados apenas para simplificar o argumento) ...

• Na empresa de software, é possível oferecer 100 recursos por ano - uma marca mais alta que ninguém ainda alcançou. Vai ser difícil, vai ser difícil, vai ser o melhor - fazendo uma melhoria legal de 50% sobre a média de 70 recursos por ano. Grande desafio, realmente.
• Ao mesmo tempo, em empresas externas , é possível oferecer 50 recursos por ano - um aumento mais alto que ninguém jamais conseguiu. Vai ser difícil, vai ser difícil, vai ser grande - fazendo um enorme aumento de 500% sobre a média de 10 recursos por ano. Grande desafio, confie em mim.

Observe que as chances de obter um aumento de 500% na empresa de software são insignificantemente pequenas em comparação - e, respectivamente, as chances de obter 100 recursos são insignificantes no exterior .

As melhores marcas de um lado expandem nossa compreensão dos limites profissionais, melhorando nosso conhecimento de como fazer as coisas melhor. A grande diferença, por outro lado, causa um profundo impacto na cultura da empresa, melhorando o conhecimento externo sobre como fazê-lo corretamente.

Agora, se você tem uma clara preferência por um ou outro, sabe qual lado tomar. Ou, se você for indeciso, sinta-se à vontade para balançar entre eles conforme desejar. :)

Elogios à resposta do custo versus centro de lucro.

Eu estive em ambos e preferiria muito mais uma empresa de software. Como a sua correlação com os lucros é mais óbvia, é mais provável que você tenha uma remuneração adequada com base no desempenho e uma cultura corporativa geral que abraça a personalidade de um desenvolvedor de software. Muitas vezes, isso se traduz em menos política para o escritório, Dockers não são necessários, planos de carreira óbvios e menos BS. Mas se você está mais interessado em um show do tipo 9-5, talvez menos desafiador, e não de ponta, do que às vezes a TI corporativa é um negócio melhor - não sendo cínico aqui, entendo algumas pessoas como um equilíbrio mais típico entre trabalho e vida à custa de outras coisas. Na minha experiência, a qualidade geral de um desenvolvedor é muito, muito melhor em uma empresa de software; oposta à mediocridade que freqüentemente permeia a TI corporativa. Eu sei que existem exceções,

A TI faz parte do grupo Suporte em empresas que não são de software. Os programadores de software desenvolveram aplicativos que ajudarão a empresa a obter uma produtividade muito melhor, transações mais rápidas, suporte técnico ... Algumas empresas que não são de software (Manufatura / Indústria industrial) oferecem treinamentos e outros coisas para seus programadores, mas muitos não são, então eles costumavam terceirizar programadores em outras empresas.

Alguém com experiência em comparar / contrastar trabalhando em uma empresa de software com alguém que por acaso tenha uma equipe ou um departamento interno de desenvolvimento de software?

Prefiro comparar o trabalho dentro de um departamento de SI ao trabalho no ramo de desenvolvimento de produtos de uma empresa que vende software. Apenas para esclarecer cada lado e fornecer alguns de cada um, com algumas correções de formatação:

Departamento de SI

A empresa pode fabricar hardware, software, carros ou qualquer outra coisa, mas a chave aqui é que existe um departamento interno responsável pelos sistemas que a empresa usa dia após dia. Aqui, pode haver estruturas como o ITIL, que podem tentar trazer alguma maturidade aos processos que o departamento executa como parte desse departamento. São os profissionais de infraestrutura que mantêm as luzes acesas e a outra parte são os profissionais de análise e desenvolvimento que aprimoram , aprimoramentos e novos sistemas. Aqui, os projetos podem variar em comprimento, embora, em alguns casos, possa levar anos para que um sistema seja totalmente implementado devido a fases na implantação, se algum sistema grande estiver sendo substituído como um CMS, CRM ou ERP.

Às vezes, tive a sensação de ser uma engrenagem em uma máquina e, em outras, é muito bom fazer parte da espinha dorsal da empresa pelos pontos baixos e altos de tal posição. Não me gabo demais das pessoas de fora da empresa porque a maior parte do meu trabalho é em sistemas internos que não pretendem ser acessíveis ou visualizados publicamente. Aqui pode haver tíquetes de suporte nos quais é necessário lidar com fornecedores de software, pois alguém tem um problema que não é necessariamente algo em que é fácil saber o que causou o erro e, portanto, o departamento de SI deve acompanhar outra pessoa. para ajudar a resolver o problema. Em outros casos, pode ser que alguma customização tenha que ser alterada devido a alterações nos requisitos ou nas regras de negócios.

Empresa de software

Aqui, isso está trabalhando no que a empresa vende diretamente e, portanto, existem algumas grandes diferenças de regras. Primeiro, o cliente aqui não pode ser encaixotado tanto quanto o caso do departamento de SI. No departamento de SI, pode haver apenas alguns usuários de um sistema, para que a governança possa cuidar de muitos casos estranhos em que, se alguém intencionalmente optar por usar indevidamente uma ferramenta, isso nem sempre poderá ser evitado. Na empresa de software não existe essa rede de segurança. Se alguém fizer o download do seu software e conseguir encontrar uma maneira de fazer algo bastante destrutivo, a empresa poderá obter um grande olho roxo por ele. Nesse caso, pode haver alguma exibição do que eu fiz, pois pode haver algum recurso interessante para mostrar a um amigo ou parente, se eles quiserem saber um pouco mais sobre o que eu faço.

Algo a ser observado aqui é que pode haver empresas que são integradas como integradores de sistemas para instalar grandes softwares corporativos personalizáveis ​​que trabalham com pessoas de departamentos de SI na implementação de um milhão de dólares de coisas, além daquelas que trabalham diretamente para a empresa grande software em si. Também pode haver provedores de serviços de aplicativos que eu colocaria aqui, pois eles estão vendendo um serviço que geralmente é construído principalmente de software. Por exemplo, o Google pode ter um departamento de SI, além de vários desenvolvedores de software, mesmo que um não vá a uma loja para comprar um DVD do software do Google, pelo menos não acho que tenha visto isso. conheça muitos produtos do Google on-line que podem ser usados ​​com bastante facilidade. Isso pode permitir alguma especialização, pois não é '

Recentemente, trabalhei em uma grande empresa americana de software, na qual um colega ouviu o CEO dizer "Não dou a mínima para o software que corro * *". Na minha experiência, isso é par para o curso. Quase inevitavelmente haverá questões que parecem óbvias para a equipe de software, mas o gerenciamento não-desenvolvedor se recusará a pensar.