Non posso decidere quale sia meglio. Entrambi hanno i loro alti e bassi.
Questo è, se capisco le sfumature dei titoli. I vostri pensieri su ciò che significa essere un ingegnere di strumenti software possono differire dai miei. Lo stesso vale per l'ingegnere del software applicativo. Ma ad un certo punto o più nella mia carriera mi sono considerato un tuttofare o un po' di entrambi.
Come ingegnere del software applicativo stai scrivendo un'applicazione che sarà usata dagli utenti finali. Dovrai preoccuparti dell'interfaccia utente e dell'esperienza utente. Dovrete preoccuparvi del fatto che la vostra applicazione [non] funzioni e dei rapporti di crash che riceverete. Dovrete preoccuparvi delle richieste di funzionalità. Dovrete preoccuparvi di quanto sia utile la vostra applicazione. Come esempio, considero un IDE che ho [scritto/stanno scrivendo] per lo sviluppo di giochi NES come un'applicazione. Certo, non l'ho scritto come parte del mio lavoro regolare, quindi non è proprio un lavoro che ho fatto come "ingegnere del software applicativo". Ma ho fatto cose simili per il mio lavoro giornaliero. Ora, questa cosa è sicuramente un'applicazione di nicchia. Non è molto utile a nessuno se non allo sviluppatore di giochi eccentrico che odia la linea di comando e vorrebbe che ci fosse un IDE per quello che vuole fare. Ma ricevo costantemente e-mail con suggerimenti di funzionalità, o con lamentele "non costruisce per me", o "si blocca se io". Faccio del mio meglio per supportare queste persone. Se fosse un'applicazione scritta per il mio lavoro giornaliero, il supporto sarebbe richiesto. Così com'è, è open-source, quindi ci arrivo quando/se posso.
Come ingegnere di strumenti software potresti scrivere uno strumento che verrebbe usato dagli utenti finali. Potreste scrivere uno strumento che sarà invocato da un motore di compilazione automatica. Potreste scrivere uno strumento che è un motore di compilazione automatica. Gli strumenti sono vasti. Infatti, è un po' difficile distinguere tra "questa cosa è uno strumento scritto da un ingegnere di strumenti software" e "questa cosa è un'applicazione scritta da un ingegnere di software applicativo". Ho scritto strumenti che sono applicazioni stand-alone, come una GUI per creare file binari da un insieme di input XML [non chiedete], una GUI per monitorare le transazioni Ethernet e seriali, una GUI per uno strumento di manutenzione proof-of-concept, ecc. Ho scritto strumenti che sono basati sulla linea di comando e invocati solo come qualche passo profondo in qualche processo di costruzione.
Al momento non potrei scegliere uno piuttosto che l'altro perché sono entrambi così vasti. Il software applicativo [pensando a cose come Microsoft Word, ecc.] è divertente perché stai creando qualcosa di immediatamente utile. Ma allo stesso tempo è stressante perché...beh...gli utenti. Tool software [pensando a cose come WinZip, Wireshark, 'dd', ...]
Vedi dove sto andando? Anche gli strumenti sono applicazioni. Wireshark è uno strumento. No...è un'applicazione. Sì, ma è uno strumento che ti permette di vedere il traffico di rete. Giusto, ma lo considero un'applicazione perché ha una GUI.
Potrei discutere con me stesso tutto il giorno, credo. Spero che questo aiuti. Oppure no.