Qual è la differenza tra lavorare in una società di software e una società che si concentra su un altro campo? [chiuso]

Di recente sono stato contattato da un'agenzia pubblicitaria locale con un'opportunità di lavoro. Stanno portando tutto lo sviluppo web / interattivo in-house e aggiungendo al loro team di sviluppo.

Mi sto ammalando del mio lavoro aziendale comodo, ma noioso, e sono incuriosito dalla posizione.

Avendo lavorato solo per negozi di software in cui l'azienda principale produceva software, temo che non possano porre l'accento su pratiche software di qualità, poiché lo sviluppo non è al centro delle loro attività.

Qualcuno con esperienza sia nel confronto che nel contrasto potrebbe lavorare in una società di software con una società che ha appena un team o un dipartimento di sviluppo software interno?

Dipenderà dalla compagnia. Ma di solito, se non è il loro obiettivo principale, il software sarà di qualità inferiore. Il processo, se ne hanno, sarà meno rigoroso. Il test inesistente. E il lavoro nel complesso è meno tecnicamente impegnativo.

Vorranno che funzioni, e funzioni ora, e sarà abbastanza buono.

Ma alcuni posti sono alla moda nello sviluppo di software, anche se sono negozi di mamma e pop che fanno del tutto qualcos'altro. Dipende dal fatto che la leadership aziendale sia aperta a buone idee, che la leadership tecnologica ne sappia abbastanza per farlo bene e che abbia persone in grado di spiegare una buona idea. Quale potresti essere tu.

Intervista alla compagnia. Chiedi loro se conoscono / aderiscono al test Joel. Molti di questi sono buoni punti. Vedi se comprendono il debito tecnico e il mitico mese-uomo. Chi è il tuo project manager, quale processo usa e quanto è geniale?

C'è un'enorme differenza. Nel primo, fai parte di un centro di profitto. In quest'ultimo caso, fai parte di un centro di costo. Indovina quale ottiene un trattamento migliore?

Ora lavoro per una società di software e sono molto più felice di quanto fossi nel mio ultimo lavoro, dove sono stati tutti i licenziamenti e l'outsourcing per tutto il tempo e gli sviluppatori sono stati appena visti come widget facilmente sostituibili (anziché il cuore dell'azienda).

I programmatori sono ancora programmatori. Solo perché il prodotto principale dell'azienda non è il software non significa che un programmatore non abbia bisogno degli stessi servizi.

Ho lavorato nel dipartimento IT di grandi aziende sviluppando software per uso interno; Ho lavorato in aziende sviluppando software per il mercato; e ho lavorato in agenzie facendo sviluppo web per i clienti.

E non direi che ci sia stata alcuna differenza tra quelle diverse aziende in termini di importanza del miglioramento della produttività.

Mantenere i programmatori produttivi è fondamentale indipendentemente dal tipo di sviluppo che questi programmatori stanno facendo. E direi che mantenere i programmatori felici e farli lavorare per te è ancora più importante quando sono programmatori di manutenzione nel dipartimento IT di una società non software.

La differenza dipende in gran parte dalla società stessa; Ho lavorato in buone società non software e terribili società software. In media, però, ecco cosa ho trovato:

Società non software

L'enfasi è sul fare le cose velocemente, con poca o nessuna considerazione data alla qualità o alla manutenibilità a lungo termine. Gli sviluppatori sono generalmente tecnicamente ignoranti al di là di ciò che hanno fatto in passato o durante il loro tempo con l'azienda, e spesso cercano di introdurre nuovi concetti (ORM, principi SOLID, TDD, ecc.) Si incontrano con confusione o licenziamento immediato. Le persone tendono a concentrarsi maggiormente sul "rimorchio della linea aziendale".

Azienda di sviluppo software

Enfasi sul fare le cose senza sacrificare la qualità. È più probabile che i colleghi si tengano aggiornati con la tecnologia (indipendentemente dal fatto che possano utilizzarla al lavoro) e spesso guardano come possono integrare nuove idee o framework nella routine quotidiana per migliorare il software. Se non hanno già familiarità con e stanno usando concetti come TDD, ORM, SOLID, ecc. Probabilmente ne hanno sentito parlare e sono più disposti a valutarli.

Ancora una volta questo dipende dalla società. Ho lavorato in una società non software con un team estremamente agile che ha abbracciato TDD e ORM e mi ha insegnato molto sulla corretta ingegneria del software, e ho lavorato in una piccola società di software che ha scritto il codice spaghetti VBScript del peggior tipo e ha oltre 50 sviluppatori che ognuno ha dovuto lavorare su pagine diverse per evitare che le cose si rompessero e tonnellate di burocrazia anche per un piccolo cambiamento. Tuttavia, meno l'azienda si affida esternamente al software, più è probabile che l'ambiente sia molto scarso per lo sviluppo del software.

Ho lavorato come unico sviluppatore di software su un piano di persone non software e penso che l'indipendenza sia ancora più importante in quel caso. Quando non hai dozzine di persone che usano gli stessi strumenti, devi prendere molte più decisioni: quale lingua userai, quale compilatore, quali server, ecc. Gli sviluppatori solitari hanno bisogno di più libertà per installare, valutare e amministrare il software questo è dato per scontato in un ambiente di gruppo.

Una differenza per certo sarà meno enfasi sull'overhead e redtape che devi passare in un negozio di software aziendale. Scoprirai che sarai in grado di avere un controllo molto più granulare su tutti gli aspetti dei tuoi progetti.

Un pro è che questo può essere rinfrescante ...

Personalmente, però, si è rivelato orribile per me, ma potrebbe essere solo perché ho scelto male. Uno svantaggio enorme è che non sei più legato al pane e al burro dell'azienda e invece sei un overhead amministrativo. I controllori del budget mi hanno trattato come se stessi prendendo personalmente denaro dai loro portafogli e hanno continuato a "picchiarmi come un mulo noleggiato" per così dire. Per me è stato un calvario esasperante ed estenuante, quindi dovresti cercare attentamente i segni di questo tipo di atteggiamento quando intervisti.

Ci sono già delle ottime risposte qui, ma vorrei solo fare riferimento a un link alla trascrizione della seconda parte di un discorso che Joel Spolsky tenne alla Yale University:

Joel Spolsky - Talk At Yale Parte 2 di 3

Qui parla della differenza tra programmatori "interni" e programmatori che lavorano in società di software / tecnologia.

I suoi tre punti principali sono:

• Quando sei un programmatore interno, non puoi mai fare le cose nel modo giusto. Devi sempre fare le cose nel modo opportuno.

• Come programmatore interno, una volta che un software è "abbastanza buono", smetti di lavorarci. Quando sviluppi "prodotti" software, li rendi bellissimi.

• Quando sei un programmatore presso una società di software, il lavoro che fai è direttamente correlato al modo in cui l'azienda guadagna. Ciò significa, per prima cosa, che la gestione si prende cura di te.

Personalmente, ho lavorato in entrambe le società di software e non software per tutta la mia carriera, e sebbene ci siano sempre delle eccezioni ad ogni regola, sono d'accordo con i punti di Joel in quanto la stragrande maggioranza delle aziende sembra essere in accordo con loro.

Una delle principali differenze è che lavorando in un negozio di software probabilmente stai aiutando a generare posti di lavoro all'interno dell'azienda. Lavorare nel reparto di programmazione. in un diverso tipo di azienda, in generale, significa che stai scrivendo software per sostituire le persone. È una realtà deprimente da affrontare. Detto questo, un'agenzia pubblicitaria potrebbe benissimo essere una bestia completamente diversa. Più come un negozio di sviluppo web all'interno di un'altra società, sarebbe la mia ipotesi.

Bene, secondo le mie osservazioni, ci sono almeno due casi in cui i confini della società di software si attengono alle questioni della sopravvivenza professionale .

Il primo caso è se si è totalmente in codice - dammi 80 ... 90 ... 100% di tempo per codificare o muoio . Nei negozi di software, questo è quasi scontato, come se tutti sapessero come arrivarci perché, beh, perché tutti lo stanno facendo. Ma fuori c'è un rischio molto alto di non riuscire ad arrivarci. Uno potrebbe arrivare al 50, 40, 30% (il mio carico di codifica personale una volta sceso al 20% - niente scherzi, l'ho misurato in JIRA !) Non è perché "loro" non vogliono che tu codifichi - no loro vogliono ma , ma ... potrebbero non sapere come.

Il secondo "rischio mortale" è se qualcuno ha seri problemi nella comunicazione. Questo può essere problematico anche nei negozi di software, giusto, ma almeno ci sono buone possibilità di sopravvivere e vivere una bella vita produttiva senza disturbare le interazioni. :) Nelle aziende non software, tuttavia, tali possibilità sono molto più basse - al contrario, è quasi inevitabile che alla fine si debba spendere molto per educare alcuni estranei alle basi dell'IT solo perché altrimenti sarebbe impossibile fare il lavoro.

Bene, tranne per due casi menzionati sopra, non conosco altri motivi validi per bloccare rigorosamente le società di software. Ora, quale parte preferire? per quanto ne so, questa è più una questione di gusti, di che tipo di divertimento fa più clic su di te.

Entrambe le parti offrono le proprie forme distinte per divertirsi. Non è facile da descrivere.

Direi che le aziende produttrici di software sono più divertenti per coloro che mirano a "voti alti" mentre quelle esterne danno un brivido a coloro che cercano "grande differenza". Ci penso in questo modo (i numeri delle note sottostanti sono inventati solo per semplificare il punto) ...

• Presso la società di software, si ha la possibilità di offrire 100 funzionalità all'anno - un punteggio massimo mai raggiunto da nessuno. Sarà difficile, sarà difficile, sarà il massimo - facendo un bel miglioramento del 50% rispetto alla media di 70 funzioni all'anno. Grande sfida, davvero.
• Allo stesso tempo, in un'azienda esterna si ha la possibilità di fornire 50 funzioni all'anno - una spinta massima mai raggiunta da nessuno. Sarà difficile, sarà dura, sarà grande - facendo un enorme aumento del 500% rispetto alla media di 10 funzionalità all'anno. Grande sfida, fidati di me.

Si noti che le possibilità di ottenere un aumento del 500% presso la società di software sono relativamente piccole in confronto - e, rispettivamente, le possibilità di ottenere 100 funzionalità sono trascurabilmente piccole all'esterno .

I voti migliori da un lato ampliano la nostra comprensione dei limiti professionali, migliorando la nostra conoscenza di come fare meglio le cose. La grande differenza dall'altra parte ha un profondo impatto sulla cultura aziendale, migliorando le conoscenze degli estranei su come farlo nel modo giusto.

Ora, se hai una chiara preferenza per l'uno o l'altro, sai da che parte stare. Oppure, se sei indeciso, sentiti libero di oscillare tra di loro come desideri. :)

Complimenti per il costo rispetto alla risposta del centro di profitto.

Sono stato in entrambi e preferirei di gran lunga una società di software. Poiché la tua correlazione con i profitti è più ovvia, è più probabile che tu abbia una compensazione basata sulle prestazioni e una cultura generale del corp che abbraccia la personalità degli sviluppatori di software. Spesso ciò si traduce in meno politiche d'ufficio, Dockers non richiesti, percorsi di carriera ovvi e meno BS. Ma se sei più interessato a un concerto stabile 9-5, forse meno impegnativo, non all'avanguardia rispetto a volte corp IT è un affare migliore - non essendo cinico qui, capisco alcune persone come un equilibrio lavoro / vita più tipico a spese di altre cose. Nella mia esperienza, la qualità generale di uno sviluppatore è molto, molto meglio in una società di software; al contrario della mediocrità che spesso permea l'ente corp. So che ci sono eccezioni,

L'IT fa parte del gruppo di supporto nelle società non software. I programmatori di software hanno sviluppato applicazioni che aiuteranno l'azienda a migliorare la produttività, le transazioni più veloci, il supporto tecnico ... Alcune società non software (produzione / attacco industriale) offrono corsi di formazione e altri cose per i loro programmatori, ma molti non lo sono, quindi hanno usato in outsourcing i programmatori in altre società.

Qualcuno con esperienza sia nel confronto che nel contrasto potrebbe lavorare in una società di software con una società che ha appena un team o un dipartimento di sviluppo software interno?

Preferirei contrastare il lavoro all'interno di un dipartimento IS con il lavoro nello sviluppo del prodotto di un'azienda che vende software. Giusto per chiarire ogni lato e dare alcuni di ciascuno, con alcune correzioni di formattazione:

Dipartimento IS

La società può produrre hardware, software, automobili o altro, ma la chiave qui è che esiste un dipartimento interno che è responsabile dei sistemi che la società utilizza giorno dopo giorno. Qui ci possono essere framework come ITIL che possono provare a portare un po 'di maturità nei processi che il dipartimento gestisce come parte di questo dipartimento sono i ragazzi dell'infrastruttura che tengono le luci accese e l'altra parte è i ragazzi dello sviluppo e dell'analisi che migliorano , miglioramenti e nuovi sistemi. Qui i progetti possono variare di lunghezza, anche se in alcuni casi possono essere necessari anni per ottenere un sistema completamente implementato a causa delle fasi di lancio se un sistema di grandi dimensioni viene sostituito come un CMS, CRM o ERP.

A volte ho avuto la sensazione di essere un ingranaggio in una macchina e in altri è piuttosto bello far parte della spina dorsale dell'azienda per i minimi e gli alti di una tale posizione. Non posso vantarmi troppo di persone al di fuori dell'azienda perché la maggior parte del mio lavoro riguarda sistemi interni che non sono destinati ad essere accessibili al pubblico o visualizzati. Qui ci possono essere biglietti di supporto in cui si potrebbe dover trattare con i fornitori di software poiché qualcuno ha un problema che non è necessariamente qualcosa in cui è facile sapere cosa ha causato l'errore e quindi il dipartimento IS deve dare seguito a qualcun altro per aiutare a risolvere il problema. In altri casi, è possibile che alcune personalizzazioni debbano essere modificate a causa del cambiamento dei requisiti o delle regole aziendali.

Azienda di sviluppo software

Qui sta lavorando su ciò che l'azienda vende direttamente e quindi ci sono alcune grandi differenze tra le regole. In primo luogo, il cliente qui non può essere inscatolato tanto quanto il caso del dipartimento IS. Nel dipartimento IS potrebbero esserci solo pochi utenti di un sistema in modo che la governance possa occuparsi di molti casi strani in cui se qualcuno sceglie intenzionalmente di utilizzare impropriamente uno strumento, ciò non può sempre essere prevenuto. Nella società di software non esiste quella rete di sicurezza. Se qualcuno scarica il tuo software e riesce a trovare un modo per fare qualcosa di piuttosto distruttivo, la società potrebbe avere un grande occhio nero per questo. In questo caso può esserci un po 'di ostentazione di ciò che ho fatto in quanto potrebbe esserci qualche funzione interessante da mostrare a un amico o un parente se vogliono sapere qualcosa in più su ciò che faccio.

Qualcosa da notare qui è che ci possono essere aziende che vengono introdotte come integratori di sistema per mettere in grandi software aziendali personalizzabili che lavorano con le persone nei dipartimenti IS sull'implementazione di milioni di dollari di cose così come quelle che lavorano direttamente per l'azienda che realizza il grande software stesso. Potrebbero esserci anche fornitori di servizi applicativi che inserisco qui in quanto vendono un servizio che è costruito principalmente da software di solito. Ad esempio, Google potrebbe avere un dipartimento IS e un certo numero di sviluppatori software anche se uno non andrebbe in un negozio per acquistare un DVD del software di Google, almeno non penso di averlo visto, anche se conoscere molti prodotti Google online che possono essere utilizzati piuttosto facilmente. Ciò può consentire una certa specializzazione in quanto non è

Di recente ho lavorato in una grande azienda americana non software in cui un collega ha sentito l'amministratore delegato dire "Non do una cazzata sul software che gestisco un * *". Nella mia esperienza, questo è alla portata del corso. Ci saranno quasi inevitabilmente problemi che sembrano ovvi al team del software, ma il management non dev rifiuterà persino di pensarci.